Exchange 2007 & 2010 SSL Certificates

Having just installed Exchange 2007, Exchange 2010, SBS 2008 or SBS 2011, you are now probably at the stage of getting Exchange to work properly (Activesync, OWA, Outlook Anywhere and Autodiscover) and are debating whether or not to use the self-issued SSL certificate installed with the version of Exchange you have, or buying a 3rd party SSL certificate.

Well, for me – it is a no-brainer. I ALWAYS buy a 3rd party SSL certificate from www.exchange-certificates.com because I can buy one, request the certificate, approve the certificate, import it onto the server, enable it for SMTP, POP3, IMAP and IIS and then forget about it for at least 3 years (I always buy one for 3 years minimum) until it is time to renew the certificate.

Once the SSL certificate has been imported and enabled, ALL aspects of Exchange will work (Activesync, OWA, Outlook Anywhere and Autodiscover) and there won’t be any annoying popups in Outlook complaining about certificate issues.

With Exchange 2007 / 2010, the following names should be included in your SSL certificate:

mail.externaldomain.com (or whatever you prefer to use)
autodiscover.externaldomain.com
internalservername.internaldomain.local
internalservername

With SBS 2008 / SBS 2011 you should include the following names:

mail.externaldomain.com (or whatever you prefer to use)
autodiscover.externaldomain.com
internalservername.internaldomain.local
internalservername
sites

You will also need to setup a new A record in your Domains DNS records (external via your Domains Control Panel, not in your internal DNS records) called Autodiscover and this needs to point to the IP Address of your Exchange / SBS server.  If you can’t do this (and sometimes this is not possible), the alternative it so setup an SRV record and the following MS guide advises you how to achieve this:

http://support.microsoft.com/kb/940881

With Exchange 2003, a simple single name certificate was all that was required and these were much cheaper than the SAN (Subject Alternative Name) / UCC (Unified Communications Certificate) certificates, but sadly, these sort of certificates won’t work properly with Exchange 2007 or 2010.

Whilst some parts of Exchange 2007 and 2010 can be made to work without a 3rd party SSL certificate by tweaking the settings in Exchange, my personal recommendation is to save yourself the pain of doing so by spending the small amount of money it takes ($60 / £40 per year) and save yourself the hassle of trying to tweak Exchange and get all the settings correct. This can be time consuming (how much is your time worth to your company) and fiddly to say the least and the time spent / cost of fixing Exchange to make it work with the self-issued SSL certificate vs the small cost of buying and installing a SAN / UCC certificate is money well spent in my humble opinion.

Extract from Understanding the Self-Signed Certificate in Exchange 2007 :

Limitations of the Self-Signed Certificate

The following list describes some limitations of the self-signed certificate.

  • Expiration Date: The self-signed certificate is valid for one year from the date of creation in versions of Exchange 2007 that are earlier than Exchange 2007 Service Pack 2 (SP2). Self-signed certificates are valid for five years from the date of creation in Exchange 2007 SP2 or in later versions. When the certificate expires, a new self-signed certificate must be manually generated by using the New-ExchangeCertificate cmdlet.
  • Outlook Anywhere: The self-signed certificate cannot be used with Outlook Anywhere. We recommend that you obtain a certificate from a Windows PKI or a trusted commercial third party if you will be using Outlook Anywhere.
  • Exchange ActiveSync: The self-signed certificate cannot be used to encrypt communications between Microsoft Exchange ActiveSync devices and the Exchange server. We recommend that you obtain a certificate from a Windows PKI or a trusted commercial third party for use with Exchange ActiveSync.
  • Outlook Web Access: Microsoft Outlook Web Access users will receive a prompt informing them that the certificate being used to help secure Outlook Web Access is not trusted. This error occurs because the certificate is not signed by an authority that the client trusts. Users will be able to ignore the prompt and use the self-signed certificate for Outlook Web Access. However, we recommend that you obtain a certificate from a Windows PKI or a trusted commercial third party.

Self-Signed Certificates
When you install Exchange 2010, a self-signed certificate is automatically configured. A self-signed certificate is signed by the application that created it. The subject and the name of the certificate match. The issuer and the subject are defined on the certificate. A self-signed certificate will allow some client protocols to use SSL for their communications. Exchange ActiveSync and Outlook Web App can establish an SSL connection by using a self-signed certificate. Outlook Anywhere won’t work with a self-signed certificate. Self-signed certificates must be manually copied to the trusted root certificate store on the client computer or mobile device. When a client connects to a server over SSL and the server presents a self-signed certificate, the client will be prompted to verify that the certificate was issued by a trusted authority. The client must explicitly trust the issuing authority. If the client confirms the trust, then, SSL communications can continue.

Frequently, small organizations decide not to use a third-party certificate or not to install their own PKI to issue their own certificates. They might make this decision because those solutions are too expensive, because their administrators lack the experience and knowledge to create their own certificate hierarchy, or for both reasons. The cost is minimal and the setup is simple when you use self-signed certificates. However, it’s much more difficult to establish an infrastructure for certificate life-cycle management, renewal, trust management, and revocation when you use self-signed certificates.

Summary:
So – there you have it. If you want to have Exchange working happily and trouble-free, my best advice is to buy a 3rd party SSL certificate and www.exchange-certificates.com is about the cheapest place around that you can buy an SSL certificate for Exchange from (even cheaper than GoDaddy and they are pretty cheap already!).

Advertisements

10 Responses

  1. Thank you, very informative but still a little confused on the difference between a UUC and a Subdomain cert. For a small/medium sized business with a single domain do you typically get the Multiple Domains UUC or the Single Domain with Unlimited Sub Domains? Will the Multiple Domains UUC allow for all the names you suggest adding to the cert?
    mail.externaldomain.com (or whatever you prefer to use)
    autodiscover.externaldomain.com
    internalservername.internaldomain.local
    internalservername

    Thanks again,
    Jason

    • Hi Jason,

      Sorry that you are still confused. The cert to buy is a Multiple Domains UCC certificate (2nd Radio Button in the list).

      On the http://www.exchange-certificates.com site – it should cost $60 for 1 year ($59.99). If it doesn’t, you are looking at the wrong certificate. If you buy a 5-domain Name certificate that should be all you need.

      Hope that clears it up for you.

      Regards
      Alan

  2. Great article Allen. Just one question. In our particular case we have an existing sbs2011 server that we want to add a cert to. Are there any “Gotcha’s” involved in adding a cert to a production server in use for 4-5 months with 40 users or so? will our activesync (iphones, android) clients break (they were manually setup). what about internal (lan) based services?

    • Hi Erlis,

      To be honest, I’ve never added a cert months after installation – I always install a 3rd party cert during installation, so have never tried.

      It shouldn’t cause you a problem, but not knowing your environment, I can’t say for sure. If you are using the same Fully Qualified Domain Name in your new certificate as it is currently, then all should be fine, but I would somehow imagine they won’t be the same.

      Activesync will probably need to be reconfigured on the devices.

      Have you got Autodiscover configured or are you going to configure Autodiscover?

      Alan

      • The idea was to use autodiscover from here forward but hopefully not have to touch existing devices.

        currently our domain consists of domain.local and all our remote services fall into the vpn.domain.com address all pointing to a single sbs server.

        I am assuming that generating the ca request from the exchange console using the wizard and then again to import the ca will net us the best results?

      • I personally use the Exchange Console Wizard under Server Configuration to generate the request as it gets everything working in my experience.

        Once requested, approved and downloaded, I usually install using the Exchange Shell:

        Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\SSL_Certificate_Name.p7b -Encoding byte -ReadCount 0)) | Enable-ExchangeCertificate -Services IIS,POP,IMAP,SMTP

        Modify the “c:\SSL_Certificate_Name.p7b” part to reflect the location and certificate name you are trying to install and it should import and enable the certificate in the one command 🙂

        Once installed – SBS 2011 should be 100% happy.

  3. Does the self signed cert actually get disabled when the new cert is created? it seems like it could remain active. when you look at the active certs in the exchange management console it shows multiples some active some not.

  4. Very helpful, EXCEPT for one little detail. My client bought a 5 year UCC cert from exchange-certificates yesterday (can’t beat their pricing). I went to configure it last night and discovered that with the rules going into effect in 2015, only FQDNs will be accepted, so I couldn’t add anything to my cert with *.domain.local or even just the servername (Exchange 2010 running in VM on Server 2008 R2).

    OWA and ActiveSync are working fine, but now he’s telling me the internal Outlook desktop users are getting a security warning about the name on the cert not matching. All I have on the cert is mail.domain.org and autodiscover.domain.org. How do I work around this?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: