Certificates and Exchange, Part 2

When you install Exchange 2007, the product automatically generates a brand-new certificate intended for use only with Exchange. This certificate is a full 128-bit SSL-capable certificate, but it's self-signed, so it won't be on the trust list of your browser, your mobile device, or computers joined to your domain, and you'll get a certificate-trust warning when you try to use the certificate with Microsoft Outlook Web Access (OWA).

The installed certificate will automatically be assigned for use with HTTP, SMTP, IMAP, and POP. This instant assignment is handy because it means communications that use those protocols are protected from the time you complete the installation. For example, Exchange will respond to SMTP Transport Layer Security (TLS) requests by using both the Internet-standard STARTTLS verb and the Exchange 2007–specific X-ANONYMOUSTLS extension. Likewise, OWA is immediately protected because the self-signed certificate for the Client Access server role is assigned to the Exchange virtual directory at installation time.

You can manipulate Exchange 2007 certificates in several ways. First, the Microsoft PowerShell cmdlet Get-ExchangeCertificate lets you see the certificate properties, including which roles or protocols the certificate is assigned to. By default, when you run Get-ExchangeCertificate on a newly installed server, you'll see a single certificate with its services field set to "all." You'll also see that the certificate is assigned to several Microsoft IIS virtual directories, including OWA and Exchange ActiveSync.

Having so much automatic protection is a good starting point, but what if you want to introduce other certificates? The answer is "it depends." For services offered through IIS, you'll need to use the standard Internet Services Manager (ISM) interface to request and manage certificates. Fortunately, ISM makes moving your existing certificates to a new Exchange 2007 Client Access server easy, provided that you have an exportable private key in the certificate. (If not, your Certificate Authority—CA—might let you rekey the certificate, but policies vary, so don't count on this capability.)

If you want separate certificates for other Exchange services, such as Autodiscover, you'll need to become acquainted with two additional cmdlets: New-ExchangeCertificate and Import-ExchangeCertificate. The former lets you generate new self-signed certificates or certificate requests (which you can then send on to your preferred CA). Once you get the certificate back from the CA, you'll use Import-ExchangeCertificate (which expects a Public-Key Cryptography Standards #12 file as input) to link the CA-issued certificate with the Exchange services you want to use.

You need to keep some subtleties in mind as you plan your certificate deployment. For one thing, remember that you might have multiple services on a single Client Access server. Microsoft currently recommends adding an extra subject name to the certificate so that the certificate is issued to, say, autodiscover.robichaux.net and mail.robichaux.net, but not every third-party CA allows this additional name. Second, bear in mind that it's perfectly OK to use self-signed certificates for your internal operations, but you might want to use externally issued certificates for public-facing services such as TLS-protected SMTP, OWA, and Exchange ActiveSync. In particular, some Windows Mobile 5.0 devices can't be easily loaded with new certificate roots, and that limitation might influence your choice of CA.

End of Article