As I developed the documentation for the Microsoft Exchange Server 2007 Domain Security feature set, I used the self-signed certificates that are generated by the New-ExchangeCertificate cmdlet. For the import function, I used existing PFX (PKCS#12) certs that I had on my computer. So I was excited last week when we heard from the folks at Entrust that they had just finished putting their Exchange 2007 certificate package together; they call this supported package the "Unified Communications certificate". The Unified Communication certificate support is specifically for Exchange 2007 and can be used to generate certificates for the various Exchange 2007 services and applications that use certificate authentication and encryption. I could finally get a third-party certificate and install it on my home network to get a "real" Domain Security experience. Throughout the certificate request, generation, and import/enable phases, I learned a few things that I'd like to share here.
Common Names Matter
As mentioned, when I was running through the prerelease functionality of Domain Security, I used the self-signed certificates created by Microsoft Exchange. If you've played around with these, you'll find that things just work in the lab when you use these certificates to test the functionality. I'd put together a long Help topic on generating certificates requests, a large part of which explains how to construct the Subject and Subject Alternative Name fields appropriately by using the DomainName parameter in the New-ExchangeCertificate cmdlet.
The first lesson I learned when I went to create a certificate in the real-world is that when you build up a certificate, you must mind the organizational (O) name. After all, this is part of the identification of the certificates that binds it to your entity. I have an Exchange organization at home that is part of my domain, johndogfood.com. Because I was testing the system for Microsoft, I just specified "Microsoft" as my organization. So my initial CN looked like this: C=US, O=Microsoft, CN=johndogfood.com. Because I am the registered owner of johndogfood.com, and not Microsoft, Entrust could not issue me a certificate with that organization. Indeed, Entrust is specific about this requirement on their Microsoft Exchange Server 2007 Support page:
The company listed in the organizationName (o=) must own the domain name that appears in commonName (cn=) of your Web server.
So I ended up creating a certificate with a common name of C=US, O=John Speare, CN=johndogfood.com. It all makes sense now, but the point here is that you have to have your ducks in a row when you create your certificate request. Make sure that the whois registrant on your domain returns the right contact, as this person will have to verify ownership rights.
Subject Alternative Names
There are a couple of interesting things to note about Subject Alternative Names (SAN). The SAN field on a certificate is intended to provide a bucket for different names that are acceptable as subject names. Not all certificate authorities (CAs) will support certificates with multiple FQDNs in the SAN field. Not all applications will recognize the existence of multiple FQDNs in the SAN field. As you'll see in the next section, putting multiple names in the SAN is pretty handy and should streamline the request and especially, the management overhead associated with Exchange and certificates.
For example, if your Exchange server is handling Domain Secure connections for multiple namespaces, the certificate that is used must have all of those namespaces in the SAN field of the certificate. IIS can handle multiple certificates for multiple namespaces for HTTPS. However, Exchange Transport picks the certificate for Transport Layer Security (TLS) when the SMTP connection initiates, which is before the Domain Secure namespace is determined. Therefore, all Domain Secure namespaces must be in the TLS certificate that is picked up initially by Exchange Transport.
Entrust allows you to specify up to ten SAN in each "Unified Communications" certificate request.
This is where the "Unified Communications" certificate solution makes more sense. Entrust has put together a supported certificate solution for the Microsoft platform around Unified Communications. So Exchange server roles and services that use certificates (OWA, POP, IMAP, Domain Security, direct trust, Unified Messaging) and Office Communications Server can use the "Unified Communications" certificate. And all applications will recognize the SAN.
Getting the Right Domains in the Certificate
I have two computers running Exchange server roles at my house: the first is an Exchange server running the default setup: Mailbox, Client Access, Hub Transport (mbx.johndogfood.com). The second is on the other side of the firewall running the Edge Transport server role (edge.johndogfood.com). I wanted to test a single certificate that would meet the following criteria:
- Run on the mbx.johndogfood.com and serve as my Microsoft Office Outlook Web Access HTTP Secure Sockets Layer (SSL) certificate and for SMTP TLS
- Run on edge.johndogfood.com and serve as my SMTP TLS for Domain Security and direct trust with mbx.johndogfood.com
- Run on other Domain Secure namespaces in johndogfood.com in the future -- for example if I wanted to host domain security for communitycycling.org.
I covered my bases here by specifying the following FQDNs in the DomainName parameter of the New-ExchangeCertificate cmdlet like this:
mbx.johndogfood.com, edge.johndogfood.com, communitycycling.org
Using the same certificate for two different computers is for testing only. Most CA's, including Entrust, only license a single certificate for a single server.
As I noted earlier, I put this CN in for the Subject parameter:
C=US, O=John Speare, CN=johndogfood.com
In the end, the command for generating my certificate request looked like this:
New-ExchangeCertificate -DomainName mbx.johndogfood.com, edge.johndogfood.com, communitycycling.org -FriendlyName JohndogfoodCert -GenerateRequest:$True -Keysize 1024 -path c:\johndogfood.req -privatekeyExportable:$true -subjectName "c=us, o=John Speare, CN=johndogfood.com"
Truth be told, I also used the Force parameter to overwrite the first certificate with an incorrect CN. That's a handy parameter for folks like me that take a few tries to get the certificate request right. The Force parameter overwrites existing certificate requests saved to the same path.
You Get a .Cer file Back
Here's where the real duh moment was for me. When Entrust notified me that my certificate was ready, I was expecting to get a PFX file with a certificate and the associated key pair. What I got back was a glob of base64 goo that was actually a .cer file -- and it didn't include a key pair. I went to my Edge Transport server, and ran the Import-ExchangeCertificate cmdlet. No problem there. So I figured I could enable the certificate for TLS (Enable-ExchangeCertificate <thumbprint> -Services SMTP) and be off and running. But when I ran the Enable-ExchangeCertificate cmdlet, I got a Watson error that complained that no private keys were associated with the certificate. I opened the Certificate Manager in Microsoft Management Console (MMC), and sure enough, the certificate was there, but no keys were associated with it. I thought I had found a bug in the Entrust system. But nope -- I was the bug in the system. When I created the request, I was running New-ExchangeCertificate on mbx.johndogfood.com. When I went to import the certificate, I was on the Edge Transport server.
When you create the certificate request, the New-ExchangeCertificate cmdlet creates the private key pair and stuffs them in the Certificate Request store on the computer where you run the cmdlet. Therefore, you must run the Import-ExchangeCertificate cmdlet on the same computer to bind the private keys to the certificate. That was my duh moment, which was really about an hour of head-scratching, fussing, and finally talking to Trevor Freeman, who is the PM for Domain Security. As in the CN case, it makes a lot of sense when you think it through for half a minute.
As a test, I ran the Import-ExchangeCertificate cmdlet and then the Enable-ExchangeCertificate cmdlet on mbx.johndogfood.com, enabling the certificate for Internet Information Services (IIS). IIS, which I had been using a self-signed certificate for, picked up the change immediately and my browser warnings went away in OWA.
Moving the Certificate Around
Rereading some of the content I'd written around importing and exporting the certificate made me realize that it's a bit confusing. I'll update that soon, but for now, here's the deal.
When you have the certificate, with the associated key pair, on a server, make sure you make a PFX file for backup. Use the Certificate Manager in MMC for this. Right-click the certificate, click Export, and follow the wizard. You want to create a PFX file, with the keys (which you'll have to provide a password for). Do not enable strong key protection.
The result of the wizard is a PFX file that you can store in a secure location as a backup. If your Edge Transport server catches on fire or is otherwise destroyed, you can import the certificate back using the following command:
Import-ExchangeCertificate -Path c:\johndogfood.pfx –Password:(Get-Credential).password
The Get-Credential cmdlet embedded in this command pops up a standard username\password dialog box. This is kind of kludgy, because you don't need a username to get to the keys -- just put whatever you want for the username, but input the password that you used when you ran the Export certificate wizard the Certificate Manager snap-in in MMC.
You can then enable the certificate. Enable it for SMTP, then resubscribe the Edge Transport server and cycle the Microsoft Exchange ADAM service. Everything will just work: mail flow, direct trust. It all works.
If I run into more interesting lessons when I actually set up a Domain Secure connection in the wild, I'll write them up here too.