With Exchange Server 2007 come some challenges related to SSL certificates.  Specifically, Exchange Server 2007 requires the use of a Unified Communications Certificate (UCC) that supports what are called subject alternate names.  This is sometimes called a SAN or multidomain certificate.  Many SSL vendors today sell these kinds of certificates.  They are more expensive than standard SSL certificates, but because of the way they would, you need only to manage a single certificate instead of installing a separate certificate for each individual service on your Exchange certificate.  Although some organizations would opt to use a wildcard certificate which can protect any number of servers in a single domain, this is not a perfect solution for Exchange 2007.  Why?  For one, Windows Mobile devices that connect to an Exchange server don’t like wildcard certificates on the server side of the equation.

I’m running a single Exchange server, so my situation is simpler than many.  However, this past week, our UC certificate expired, leaving Windows Mobile devices unable to download any mail and OWA users left with certificate errors.  Although traffic was still SSL-protected, some users were concerned with the somewhat scary certificate error messages that greeted them.

We’ve been using Comodo for most of our certificates and have been using a Comodo UCC as well.  However, the Comodo solution required an additional step to be taken for Windows Mobile devices–the manual installation of an intermediate certificate on the Windows Mobile device.  When this certificate expired, it presented an opporunity to install a certificate that doesn’t require this intermediate step on mobile devices.

As such, I decided to buy a UC certificate from Go Daddy, but also looked at DigiCert.  The price difference between the two is substantial.  In short, Go Daddy is really cheap.  However, not all was smooth.  We have a total of three domains: westminster-mo.edu, wcmo.edu and churchillmemorial.org.  Westminster College is the home of the Winston Churchill Museum and Library, so some of our staff need that domain name.

When I ordered the new UC certificate, I was asked for the domains that I wanted to secure.  I listed the three domains above.  The certificate companies wanted me to verify that I had control of the domains.  This was easy for the two Westminster domains, but not so easy for the churchillmemorial.org domain.  Unfortunately, no one kept records regarding that domain registration, so I had to start from scratch, determining that Network Solutions is the registrar.  They need three days after receiving paperwork in order to reset the password for a domain account, and I couldn’t wait that long.  I need the password in order to change the admin contact email address for the domain since the existing address is no longer valid.  The temporary solution: I purchased a one-year UC certificate from Go Daddy omitting the churchillmemorial.org domain for now.  Next week, I’ll send the necessary information to Network Solutions, transfer the domain to the registrar that holds some of our other domains, and then reinstall a new certificate that includes that domain.  This is a low impact problem.  The memorial staff also have westminster-mo.edu email addresses that they use as their primary accounts.

When I initially installed the UCC last year, it was a relatively painful process, but I think a lot of that had to do with the fact that I was also deploying Exchange 2007, and this was just one step in that process and it was new enough that not all SSL vendors had it nailed down.  This time, it wasn’t too bad.

I followed these steps to accomplish my task:

  1. Generate the CSR using PowerShell:  New-ExchangeCertificate -GenerateRequest -Path c:\mail1.csr -KeySize 1024 -SubjectName “c=US, s=Missouri, l=Fulton, o=Westminster College, ou=Information Technology, cn=mail1.westminster-mo.edu” -DomainName mail1, wcmo.edu, autodiscover, autodiscover.westminster-mo.edu, westminster-mo.edu -PrivateKeyExportable $True
  2. Used this CSR to order the new certificate.
  3. Imported the new certificate using PowerShell: Import-ExchangeCertificate -Path <path to new certificate>
  4. Located the certificate thumbprint for the new certificate using Get-ExchangeCertificate | fl (so I could see the full thumbprint)
  5. Enabled the new certificate: Enable-ExchangeCertificate <thumbprint from step 4>
  6. Restarted IIS.

After that, Treos magically started working again and OWA users were no longer greeted with a flashing red screen!