Tuesday, May 18, 2010

Problems in Exchange 2010 and OWA and signed SharePoint email

In Exchange 2010 the redirection of signed emails from SharePoint causes the email to be subtly changed invalidating the signature.

Additionally it appears that there may be an issue with the SMIME controls when it comes to validating signed emails from SharePoint for OWA in both 2003 and 2010 (we were unable to test this in 2007).

Also, SharePoint integration with outlook fails when the SharePoint email is signed.

To begin, our client has an overly complicated PKI and email system. I mention this only to preface why we developed the system that we did and why our tests are limited. We act as the SharePoint infrastructure design and maintenance team and have little to no access to the actual network infrastructure.

Our problem was this: SharePoint emails are viewed as external to our client and therefore must go through a third party email server. The third party email server reviews all emails and blocks html links by adding the word "Blocked" to the beginning of them causing the email client or browser not to use them. Our clients wanted to be able to use the links in the emails and the best solution was to get SharePoint to digitally sign all outgoing emails. A feature of a digitally signed email is that if the email content is changed in any way the signature will be invalidated. Our solution to accomplish this was to procure an appliance from Cisco called an IronPort. IronPort provides many security features, mostly mail related. The ability to sign outgoing emails is one of them.

Another problem was the differences across the enterprise in email configuration. All users initially receive external mail at the third party server that does an initial security scan. Some users check their mail on there, most have the mail redirected to their local exchange server (2003). A rare few are testing an Exchange 2010 deployment and a few within that group have their mail forwarded to their local Exchange servers. We tested with a few from each of these groups of people.

We set up a user in their PKI that basically consisted of just the outgoing email address that we are using for SharePoint and installed the signing certificate on the IronPort. First we performed some initial tests sending plain text emails through using telnet. They went through fine and were validated by all the clients we tested on. Next, we tested sending an HTML mail with hyperlinks through (formatted using outlook express). This also went through without an issue and the signatures were all validated. Finally, we sent mail through SharePoint. This is where the issues started.

The people checking their mail on the third party client had no issues, it looked just like any other signed email.

The people redirecting their mail to the local exchange had no issues...provided they checked their mail in outlook. If they looked at it in outlook web access, they got a warning that the signature couldn't be validated (this didn't happen with the first 2 test emails).

The people in the final group, the ones using exchange 2010 had more interesting results. When checked through outlook the mail was displayed fine and the signature was validated. When viewed through outlook web access the mail displayed an error that the sender didn't send a digital ID to validate the signature with. When the mail was redirected to 2003, outlook threw an error that the signature was no longer valid because the content had been changed (When sent from any other source the signatures had no error).

We looked at the content of each of the emails by looking at the .msg files in notepad. It appeared that the email redirected from Exchange 2010 contained a line break at the bottom of the final content section before the signature hash. Exchange 2010 kept a copy of the redirected mail, so we looked at that one (the same as the one that was invalidated) and before the redirection it had no line break at the end.

The only place in our client's email infrastructure where an email would possibly be changed is at the third party mail server, which it was definitely not changed at. Based on our investigation it would appear that this happened at the Exchange 2010 redirect...But it only happened with the emails from SharePoint. We also resent the SharePoint email from IronPort (so that it looked as though it never came from a SharePoint server) and received the same experience. It appears there is a problem with the format of the emails coming from SharePoint and how they interact with outlook web access and Exchange 2010 (we were unable to redirect these emails outside of the organization, it's possible signed SharePoint emails may have problems with other clients as well).

Comparing SharePoint's emails and the standard plain text and HTML emails where there was no problem revealed that SharePoint's emails have only one content part with a content-type of "text/html". Other emails that are formed by a client have at least 2 parts, one plain text where it contains all the content of the email in plain text and a second with the HTML formatting. I'm not sure why this would be an issue, but it appears to be creating some hiccups.

Finally, a typical SharePoint list alert email received by outlook 2007 will have a button that allows you to go directly to the list or list item that was changed. Outlook 2007 will not display that button if the email is signed. The signed email still contains the x-headers that outlook uses to create this button, but for some reason it will not display it.


*A couple notes on our client's PKI set up. Every user that has a certificate receives 3 certificates: one for authentication, one for email digital signatures and one for email encryption/decryption. The email address is in the certificate as a Subject Alternative Name attribute, not as the Subject. Also, IronPort can only accept one Certificate per email address. Despite all this emails from SharePoint were the only ones adversely affected.

2 comments:

  1. were you able to nut this issue out because you mentioned Ironport, at the moment I am facing a similar issue. When bringing up the web address for Outlook Web App, an untrusted site windows pops up or is displayed before the login page asking to proceed, seems like invalidated certificate. Another issue is that no one can insert a signature, the box greys out when clicked. Only workaround is to set the user's Outlook Web App to light version mode and they are able to use signatures. Anyway your issue sounds similiar, I think it could be in Ironport not accepting the https signature. Maybe I should turn off Ironport and try it out, what do you think?

    ReplyDelete
  2. I know this is ages old but:

    We eventually gave up. It turned out the particular test case that was holding us up affected such a small user base that it may have been limited to a single user. Ironport for us was acting as an SMTP router that only signed outgoing mail.

    For a certificate to be happily accepted by a client, it has to be non-expired, it has to match the name of the server you are accessing, and finally, it has to have been created by a trusted certificate authority. Make sure that all of that is true.

    Also, the untrusted content usually refers to when a site is only partially SSL, i.e. you go to https://mywebsite.com/secure and it has an iframe or src that is being pulled from a non-SSL site. If you're going through a proxy server or OWA is misconfigured something may have been inserted there that you didn't expect.

    Finally, OWA non-lite edition uses activex plugins while lite does not. There's a chance that those plug-ins are being blocked either on your computer or somewhere along the way.

    ReplyDelete