Exchange 2010 SSL Certificates

After recently going through the process of upgrading my home Exchange environment from 2003 to 2010, I started noticing lots of Experts Exchange questions related to certificates and Exchange 2010.

I'm probably shooting myself in the foot a bit—at least from the perspective of earning points—by writing this up, but it's pretty obvious it still needs to be done.

First off, if you're not going to implement Outlook Anywhere and/or ActiveSync, you can pretty much ignore all this. Between Windows and Exchange, self-signed certificates will be available automatically, and internal-only use will happen almost automatically.

But if you want to take advantage of any newer features of Exchange 2010—after all, why go to the trouble to set it up if you weren't going to—you need to obey the rules for certificates.

First off, the Client Access role is the one you're interested in. Yes, Hub Transport matters if you're doing SMTP over TLS, but otherwise, it's all about client connectivity.

The CAS role-holders will have at least three names you'll have to account for:

1.

public FQDN

2.

inside name

3.

autodiscover
All three of these names must be supported by the one SSL certificate being used by the host. If you're careful how you architect it, you can get away with using the same name for both the public FQDN and the inside name; you can also use other work-arounds to handle the autodiscover name. But for the sake of ease in setting up the environment, you need all three.

That moves into the realm of the certificate. There are three broad flavors of computer certificates, with an additional variant (of all three) that can be thrown into the mix. The additional variant is the "extended validation" bit, and all it adds is that the signing authority did more to verify your identity (the signing requester) than a standard validation cert.

The first type is your basic certificate. It has a single "Common Name", and is the one and only host that it functions with. If you trust the signing authority and use the common name, your client will get a no-errors SSL connection.

The second type is the "domain wildcard" certificate. This certificate has an asterisk for the FQDN instead of a hostname followed by the domain. There are some special steps you need to follow to get a wildcard cert to work correctly with Exchange, but it has the advantage of being very versatile across any number of machines.

The final class is a multi-name certificate. This certificate has a single hostname for the Common Name, but an extended property field called the "Subject Alternative Name" (SAN) can have a list of any number of hostnames; the number you can have is more dependent on the certificate authority than any technical limits. I've seen as few as one SAN entry permitted, and as many as ten. Some CAs sell these as "Unified Communication (UCC) Certs," others market them as "multi-host" or "multi-domain".

The last one is the ideal certificate to have--as long as it provides two SANs in addition to the Common Name. It has an actual host name for the Common Name, which is important for the Name Service Provider Interface (NSPI); you can get around that by adjusting settings for the CAS, but the Common Name is used by default. It has the ability to publish autodiscover.mydomain.com, which is the second of a series of URLs that can be used to learn configuration information.  It also publishes an internal and external name so that you don't need to use the same naming convention (or even DNS hierarchy) for the CAS.

Ultimately, I also like to handle all my certificate handling from the IIS console, whether it be initial CSRs, renewals or import/export. The UI is more mature--Microsoft has been supporting SSL on IIS since its inception--and the first place you tend to test it is by pointing your browser at IIS.

And by all means: if this isn't enough to get your certificate questions, please post them!