Exchange 2007 lessons learned – generating a certificate with a 3rd party CA




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.

From here, go on and configure Domain Security as outlined in the Microsoft Exchange Server 2007 documentation. Also, check out my Domain Security White Paper in the TechNet Library.

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.

John Speare

Comments (17)
  1. John, thanks for this very useful article! Only one questions left: Why didn’t you include the "-IncludeAutodiscover" Parameter when creating the certificate request? If you want to use Autodiscover from the "outside" it makes things easier…

    Christian

  2. John Speare says:

    Hi Christian,

    I didn’t include autodiscover because I’m testing this cert for Domain Security. Even though I did test it out for OWA by enabling it for IIS on my mbx server. As noted in the article, the license for this cert is only for one server — so I’ll be using it only on my Edge box.  But now that you mention it, I wish I would’ve thought of that to test it too. Dang it.

  3. Anonymous says:

    Exchange 2007 Discontinued Features The 10 most common Exchange Server issues and how to avoid them Exchange

  4. Vlad Mott says:

    Thanks for the very helpful article.  One question– to the more popular CA’s like Verisign and Thawte support SAN yet?

  5. Bas van dne Dikkenberg says:

    Hi,

    I added the new certificate this works fine but,

    When i try to access owa from the internet and whil send to page in our case amsterdam.giskit.local but the internet dns name kantoor.giskit.nl the certificate is in this commenname to.

    Can any body help me?

  6. John Speare says:

    Vlad,

    We’re signing up more providers. See KB, "Description of the Exchange-specific Web sites that are provided by X.509 certification authorities" (http://support.microsoft.com/?id=929395) for the most up-to-date list.

  7. Andrew Codrington says:

    Hey Vlad,

    "More popular CA’s"?
    Do you buy your certs based on what parties the CA gets invited to, or whether they can do the job at hand? :-)

    You can check out for yourself which CA was more popular for the official Exchange2007 demo site:
    https://mail.exchange2007demo.com/

    Cheers,
    Andrew (http://www.entrust.net employee with tongue firmly in cheek! )

  8. Thomas K.H. Bittner says:

    Hi Vlad,

    I’ve got this all running, but what about the ISA 2006 end? I applied the certificate with private key to the ISA 2006, but it has a strange behavior and even won’t provide OWA anymore. Any different path to go?

    Regards,

    Thomas

  9. Morten says:

    Hi

    I have created a certificate for multiple domain names, but when I access the page from a browser I get a message saying "The security certificate presented by this website was issued for a different website’s address.".

    Should it be possible to have two or more domains on a single IP on a single IIS site?

    Morten

  10. Steven Hope says:

    ISA 2006 doesn’t support SAN’s on the certificate. So all this gets even more complex when using ISA now.

    Why has MMSFT made this SO MUCH more complex than it needs to be? I long for the simplicity of Exchange 2003 again where silly things like this don’t happen: http://www.sembee.co.uk/archive/2007/01/21/34.aspx

    Steven

  11. Jochen Erhard says:

    Thanks for this excelent "HowTo"!!

    We fixed our external Sync promblems in a few minutes!

    Jochen

  12. Oguz Mazlum says:

    John,

    What about publishing OWA with ISA 2006 on split DNS structure. Can I import the UC X.509 certificate to ISA 2006. Normally must we install the same certificate on ISA and on exhchange 2007.

    Oguz

  13. Richard says:

    Hi,

    We made a setup of multi-role E2K7 Server (MBX/CAS/HUB, named e2k7domain.int

    on our internal network), now we want to achieve greater security and

    enhancements for our external/mobile clients using OWA, EAS and OAW with ISA

    Server 2006 and Edge Transport Server.

    Since we are going to replace the now in use external firewall (Cisco) with

    ISA Server 2006 to fully protect our WAN/LAN/DMZ network, we are going to

    put the ISA on the internet with a public ip-adress and then the Edge

    Transport server behind it (on a DMZ).

    We have red through the Ms article

    http://www.microsoft.com/technet/isa/2006/deployment/exchange.mspx for the

    publishing of the websites etc. Not much info here about coexistence with

    Edge Transport and different solutions scenarios. We are also unsure if we

    can stick with our CA certificate with multiple SANs since we have red that

    this isn’t supported yet on ISA Server 2006. And since we also are running

    in an environment with different internal domain (domain.int) and external

    domain (domain.com) we also have questions how to successfully use our

    requested certificate on our internal CAs server on the multiple websites

    (CAS/ISA etc). We are using the guide

    http://technet.microsoft.com/en-us/library/aa995942.aspx and this works all

    fine now (externally/internally) when we only so far are running the

    multi-role E2K7 (MBX/CAS/HUB), but as mentioned abowe we are seeing coming

    problem with the certificate beeing activated correctly on the ISA server.

    We are in need of hints and recommendations when it comes to publishing the

    certificate and also for guides, white papers etc when it comes to Edge

    Transport and ISA Server 2006 coexistence and common scenarios.

    All types of responds when it comes to this are highly appreciated!

    Thanks in advance,

    Richard

  14. Dennis says:

    Great stuff!!! – You just clearly explained in 500 words or less something I have been trying to figure out for a few days.

    You are my hero.

    Thank You – Dennis

  15. Anonymous says:

    &lt;P&gt;Exchange 2007 presents new challenges on the front of SSL certificates – we know now that we need to include multiple names into our certificates to make all the features …

Comments are closed.