How to fix Entourage 2008 SSL errors

It seems that Entourage 2008 SP1 is broken in regards to how it checks an Exchange server’s SSL certificates. I would go one step further and argue that Entourage is broken in its thought process about how to connect to Exchange as a whole.

We have a hosted Exchange email service with mail2web, and in their setup instructions (let’s assume we use domain.com as our own domain), they ask you to configure the Exchange server address to https://ex7.mail2web.com/exchange/username@domain.com. On your DNS server you must then configure an MX record to point to mail2web’s IP addresses, and also add a CNAME for autodiscover.domain.com that points to the same IP – this last one is used by Outlook 2007′s automatic configuration feature.

As soon as I started using Entourage, the error messages showed up, but they refered to a problem with the SSL certificate of domain.com, not mail2web.com. Confused, I fired up tcpdump, and found that Entourage, during it’s connection process to Exchange, attempts to connect to all these addresses:

ex7.mail2web.com (https/443)
autodiscover.domain.com (https/443)
domain.com (https/443)
www.domain.com (http/80)

I have no clue where Entourage gets the idea that to access the Exchange server at ex7.mail2web.com it has to connect to www.domain.com – it could be a number of places, for example, if it assumes the last part of the Exchange configuration string is the actual domain it needs to connect to, or maybe there is a setting in Exchange that tells Entourage where to go (unlikely, but I’m not an Exchange expert so I cannot say for sure).

Having established that until Microsoft fixes the bug, the only way to cure the problem is to give Entourage a valid certificate for autodiscover.domain.com, www.domain.com AND domain.com. You may think that all these are covered by a single SSL certificate, but that’s not how they work. You can get a certificate for domain.com, but then autodiscover.domain.com is a different common name, and thus not valid. The opposite is also true.

Come to the rescue Subject Alternative Names

This is a not well know feature of x509v3, and not many SSL certificate providers allow it, but it’s the perfect fix for this problem. A Subject Alternative Name (SAN) is an additional record inside the certificate which includes alternative domain common names, so a wildcard certificate which includes domain.com as a SAN would be valid for all possible domains on the server. I went ahead and requested such a certificate from DigiCert, installed it on the Apache box, and Entourage stopped complaining.

The procedure to generate a CSR with a SAN is not point-and-click, but only involves a little edditing of openssl.cnf. First, create a copy of openssl.cnf (usually found in /etc/ssl), and in the copy, add the following in the respective sections:

[req]
req_extensions = v3_req
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = domain.com

Once you have this done, create your CSR as usual, but specify -config yourconfigcopy.cnf to force openssl to use the edited configuration file. Check your CSR and you should see this:

Attributes:
Requested Extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Subject Alternative Name:
DNS:domain.com

Once you have the CSR, submit it to your CA as normal and install the new certificate on your server. You could alternatively create your own certificate and add it as trusted on OS X’s keychain, but that’s a different story.

Microsoft, the ball is on your side now!