Autodiscover in Exchange part III

Autodiscover is a standard feature in Exchange Server 2007 and higher that’s being used by Outlook 2007 and higher. Looking at the number of questions I get regarding autodiscover I’ve written a number of blogposts that will look into Autodiscover in depth:

Autodiscover Part I – Introduction Autodiscover and Outlook on a domain joined client
Autodiscover Part II – Outlook on a non-domain client
Autodiscover Part III – 3^rd party certificates and your own PKI solution (this post)
Autodiscover Part IV – Using different SMTP domain names

In Part I I’ve explained how domain joined clients work with autodiscover information that’s stored in Active Directory. In Part II I’ve explained how the same (domain joined) client behaves on an external network like the Internet.

Both posts work with the self-signed certificate, but it’s much better (and recommended!) to use a 3^rd party certificate or a certificate of an internal PKI environment.

3^rd party SSL certificates

Microsoft does not recommend using the self-signed certificate in Exchange Server 2007/2010 but instead use a 3^rd party certificate. These are mentioned in Microsoft knowledge base article KB929395 (http://support.microsoft.com/kb/929395):

Entrust – http://www.entrust.net/microsoft/
Comodo – http://www.comodo.com/msexchange
DigiCert – http://www.digicert.com/unified-communications-ssl-tls.htm
GlobalSign – http://www.globalsign.com/ssl/buy-ssl-certificates/unified-communications-ssl/
WISeKey – http://www.wisekey.com/en/Products/digital-identities/Pages/ssl-solutions.aspx
GeoTrust – http://www.geotrust.com/ssl/ssl-certificates-san-uc/
Thawte – http://www.thawte.com/ssl/san-uc-ssl-certificates/index.html
VeriSign – http://www.verisign.com/ssl/buy-ssl-certificates/specialized-ssl-certificates/san-ssl-certificates/index.html

Or course there are more vendors that offer certificates, but there are tested by Microsoft for UC solutions. Personally I have good experiences with Digicert and Entrust certificates but I also know customers that are very satisfied with GoDaddy certificates for example.

The advantage of using 3^rd party certificates is that their root and intermediate certificates are ‘native’ in the trusted root store of most clients. Not only on Windows clients, but also on non-Windows clients and mobile devices. This way the trusts issues as mentioned in my first post on autodiscover are prevented.

In the previous two posts we had configured the following environment:

The self-signed certificate is not really usefull if we want to use the FQDNs webmail.contoso.com and autodiscover.contoso.com since only the NetBIOS name and the local FQDN ams-exch01.contoso.com are in this certificate. The SSL certificate should at least contain the names webmail.contoso.com and autodiscover.contoso.com where webmail.contoso.com is the Common Name of the certificate.

A common question is if the internal FQDN of the Exchange Server needs to be on the certificate. In the current scenario the answer is yes. Externally the Outlook client will connect to webmail.contosoc.om, but internally the Outlook client will connect to ams-exch01.contoso.com. Therefore the internal FQDN needs to be on the SSL certificate (in this scenario).

In short we need the following names in the SSL certificate:

Webmail.contoso.com
Autodiscover.contoso.com
Ams-exch01.contoso.com

To retrieve a UC certificate in Exchange 2010 there’s a wizard available that will guide you through the various options. In Exchange 2007 a certificate can only be requested using the Exchange Management Shell.

Open the Exchange Management Console and click on the Server Configuration in the navigation pane (on the left-hand side). Select the Client Access Server and click on New Exchange Certificate in the Actions Pane (on the right-hand side):

Just follow the wizard and enter the appropriate data where needed. Make sure that if you request a 3^rd party certificate you enter the fields like Organizations etc. like they are recorded in the WHOIS database on the Internet. If you fail to do so the Certificate Authority cannot issue the certificate since you didn’t prove to be the owner of the domain.

And the end of the wizard an overview is shown, this should be something like this:

Save the request file on the local hard disk. Then logon to the 3^rd party certificate vendor (Digicert in this example) and use the data stored in the request file to request the certificate at the Certificate Authority.

If all goes well (and you’ve paid) the certificate can be issued within 15 minutes. If you use your own PKI environment (see another post on this: http://www.jaapwesselius.com/2011/03/29/exchange-2010-and-your-own-pki-infrastructure/) you have to logon to the CERTSRV virtual directory of the Certificate Authority and select Request a Certificate:

In the wizard select the option “Submit a renewal request by using a base 64-encoded PKCS#7 file” and continue with the wizard. Upload the request file that was create earlier. The internal CA will process the request immediately and the issued certificate can be downloaded in a second. Save the certificate on the local disk of the Client Access Server.

This process is not very different that requesting a certificate with a 3^rd party vendor, except that the latter most likely will return the certificate via E-mail. Once received store this certificate on the local hard disk of the Client Access Server.

Now return to the Exchange Management Console, select the certificate we’re currently requesting and click on Complete Pending Request. Continue with the wizard, import the certificate that was received (the CER file) and the certificate is ready.

The final step is to assign the various services (IIS, POP, IMAP or SMTP) to the certificate. If you do this properly a warning message is shown stating that the old certificate will be overwritten:

When the wizard is finished the Client Access Server is now using a real Unified Communications (UC) certificate. This is easy to check to open an OWA session using your browser and check the certificate:

The 3rd party certificate will work instantly on 99% of all clients. If you’re using a UC certificate issued by an internal CA domain joined clients will automatically accept the certificate. Workgroup members on the other hand will not accept this certificate simply because the root certificate of the CA is not in the trusted root store.

To add the root certificate to the local trusted root store of a workgroup machine logon via a browser to the CA and select “download a CA Certificate, certificate chain or CRL”. Download this file and save it on the local harddisk, for example c:\temp\certnew.p7b. Now add this root certificate in the local trusted root store via the Certificates MMC snap-in (select ‘computer account’ and not ‘my user account’ to prevent erratic behavior):

Outlook Web Access, Outlook 2007/2010 and Outlook Anywhere will not work as expected, including all web based services and without annoying certificate error messages.

Summary

Instead of using the default self-signed certificate of the Client Access Server it is recommended to use a (normal) Unified Communications Certificate. This can be a certificate issues by a 3^rd party CA or by an internal CA.

The advantage is that 99% of all clients will automatically trust the 3^rd party certificate, whether it is a Windows client, a Linux Client, an Apple client or a mobile device. The disadvantage is that you have to pay for these certificates, although pricing is not really sky rocketing.

An internal certificate is of course ‘free’ but the hidden cost is in additional configuring of the non-domain clients and mobile devices.

In the past 3 blog posts I have discussed the configuration where the scenario is relatively simple and where the internal domain name is equal to the SMTP domain, i.e. contoso.com. In the next blog I’ll explain what happens when that’s no longer the case.