Exchange 2007 makes ample use of Certificates for securing connections from clients and across servers. To start-off Exchange makes use of an automatically generated self-signed Certificate. This is valid for 1 year and can be renewed as discussed in Expired Exchange 2007 Certificate.

Chances are that you will later need to replace this with a Certificate issued by a public or private Certification Authority CA. In this two part article series we discuss the issues involved in doing this. Today we discuss the choice between public and private CAs. We look at Certificate naming and discuss the usefulness of Subject Alternative Names SAN extension. Finally we walk through the installation of Certificates Services on Windows 2008. In the second part we conclude the discussion walking through the steps to install a new Certificate on Exchange 2007.

About Private and Public Certification Authorities

Self-signed Certificates are not always the right choice. Indeed these are most appropriate for internal use such as for communication between internal servers and internal client access. As soon as Exchange is opened for external access, crossing the organization perimeter, Certificates issued by a CA become more appropriate.

A CA can be private or public. A private CA is typically one that is deployed within the organization to issue Certificates for itself. Public CAs such as VerSign, Thawte, Entrust and DigiCert allow you to purchase Certificates without having to manage your own private CA. Public CAs provide Certificates against payment. Certificates cost something between a few hundreds to over a thousand bucks. In addition these have to be renewed at an additional cost after one or more years.

Deploying an internal Pubic Key Infrastructure PKI is the first step to start running a private CA. Windows 2003 and 2008 provide the Certificate Services for this purpose. Running Certificate Services on a test network is a good learning experience and I recommend doing this even to those who intend using the services of a public CA.

Public CA Certificates do offer some important advantages over those generated by a private CA otherwise there wouldn't be so much business going on. For one, public CAs relieves you from maintaining a live PKI. Here I underline the word maintaining because as already said running Certificate Services on a test network is a worthwhile exercise in any case. However a live PKI amongst others also requires running the Certificate Revocation Service and possibly making it available online for external consumption. Certificate Revocation allows terminating a Certificate. If Certificates are to be validated from outside the organization then the revocation service also has to be accessible from outside.

The most obvious advantage of using public CAs is probably the ease of Certificate deployment. Various operating systems, including Windows, out-of-the-box ship the root Certificates of public CAs. Trusting these pre-installed Certificate Roots readies the machine to verify Certificates issued by these CAs. On the other hand a private CA requires the updating of the Trusted Root Certificate store on each machine and device where Certificates are to be verified. Even if all machines/devices controlled by the organization are updated, users are still likely to connect from some external machine where the Root Certificate is not trusted such as an Internet Cafe.

Building on the previous point, let's consider the case when a user is accessing OWA from an Internet Cafe. In return he gets a Certificate error that he can choose to ignore and access the mailbox anyway. In doing so, users get into the bad habit of ignoring Certificate errors. In this case, if at some point a hacker manages to redirect traffic to some other host, the Certificate error alerting the user most likely ends up ignored.

Certificate Subject, Alternative Names and Wildcards

I will not get into any detailed discussion of how Certificates are made up. For our purpose let just say a Certificate includes a number of named fields each carrying some information. The Subject field identifies the Certificate user. A web server Certificate used for securing HTTPS connections will typically have its DNS name at the Certificate Subject. Likewise an email sender using Certificates for signing will have his email address at the Subject.

Another field we will also discuss here is the Subject Alternative Name SAN extension. Here we can list additional identities for the Certificate user. As RFC5280 explains these identities may be included in addition to or in place of the identity in the subject field of the Certificate.

Let's say we want a Certificate to secure external OWA access. Clients would connect using a URL of the type:
https://owa.exchangeinbox.com/owa/user@exchangeinbox.com

In this case the Certificate subject (common name part) would be set as owa.exchangeinbox.com.

If the internal server distinguished name DN is exchsrv.exchinbox.local and we want internal users to also access OWA we get other valid URLs:
https://exchsrv.exchinbox.local/owa/user@exchangeinbox.com
https://exchsrv/owa/user@exchangeinbox.com

A fourth one could be that used by the Outlook auto-discover functionality:
https://autodiscover.exchangeinbox.com/autodiscover/autodiscover.xml

We now have enough names to get to the point i.e. the same server may be identified using different names. In our example:
owa.exchangeinbox.com
autodiscover.exchangeinbox.com
exchsrv
exchsrv.exchinbox.local

To cater for all possible names we either use multiple Certificates or one that includes all names. This is possible using wildcards and/or Subject Alternative Names. Using wildcards we could cater for both owa.exchangeinbox.com and autodiscover.exchangeinbox.com using:
*.exchangeinbox.com

This is very powerful as it also covers any other names we may need in the future for the same domain. However we still have exchsrv.exchinbox.local and exchsrv. To include these as well we need to use the SAN extension field.

Everything sounds great except for the fact that not everyone supports wildcards and SANs. If ordering Certificates from a public CA, start by checking whether creating such Certificates is allowed. If they do, check for any additional charges. Wildcards may appear at the Subject or SAN extension, however ultimately this depends on the support provided by the CA.

Next you will also need to check the support for wildcards and SANs by the software and devices in use to connect to Exchange. Software vendors are catching up in this area, as an example ISA 2006 only started supporting SAN as from Service Pack 1. Windows Mobile 5 does not support Certificate wildcards. I also came across complaints concerning Symbian OS smart phones having problems with SANs. If you still needed an excuse for installing Certificates Services on your test network now you have it!

Installing Certificate Services

For practical reasons, on my test network I installed Certificate Services and Exchange 2007 SP1 all on one Windows 2008 machine.

In Windows 2003 we start the installation from:
Control Panel | Add or Remove Programs | Add/Remove Windows Components | Certificate Services

In Windows 2008 we go to:
Server Manager | Add Roles

Here I will walk through the installation on Windows 2008. However the wizard for both Windows 2003 and 2008 are very similar.

Starting the Wizard we proceed to the Role Services selection. Here we find four services that together are useful in running a complete live PKI. In my case I will only install the Certification Authority that allows me to issue and manage Certificates.

Normally you will certainly want to also have the Web Enrolment service to submit Certificate requests through a web interface. The Online Responder provides online access to the Certificate Revocation List and the Network Device Enrolment service allows issuing of Certificates to devices that don't have a network account.

In the steps that follow I choose Enterprise to use Active Directory, Root CA to create an independent PKI and 'Create a new private key'.

Next we specify how the private key is to be created. The defaults are fine, apart for the fact that the details here are beyond the scope.

Next we name the Certification Authority. Here we are constructing an X.500 DN. In my case I just keep everything as is. If going live with this Certification Authority we would want to change the settings.

The goal would be to uniquely and unambiguously identify our Certification Authority. If you want to see how others name their CA just go to Internet Explorer Tools | Internet Options | Content | Certificates | Trusted Root Certification Authorities. Open one of the Certificates and from the Details page check the Subject field value.

Finally we have the steps for setting the validity period and the databases path for this CA.

This completes the installation enabling us to start issuing Certificates.

Final Tips

The reliance of Exchange 2007 on Certificates requires Exchange administrators to consider their options. The choice is between working with the initial self-signed Certificate or moving to a Certificate issued by a private or public CA. Moving to a new Certificate becomes most necessary as soon as Exchange 2007 is opened to external access that requires SSL.

Exchange 2007 recommends the use of Certificates supporting the SAN extension allowing the packaging of different DNS names into one. This does not come for free and some will be tempted to deploy their own PKI. Indeed both public and private CA options come at a price one in terms of Certificate purchase price and the other in terms of administrative cost.

In the second part we complete the discussion walking through the steps necessary for creating and installing a new Certificate.

References

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Certificate Use in Exchange Server 2007