Master Exchange 2007

powershell, automation & more…

Create UC SAN Private CA issued certificate to replace self signed certificate Exchange 2007

Posted by shauncroucher on September 20, 2009


This guide is intended to help you setup your own Certification Authority, and issue a UC certificate for Exchange 2007 testing purposes \ lab environments.

It also uses powershell cmdlets wherever possible, rather than using the Windows 2008 or Exchange 2007 GUI interfaces.

When and why you shouldn’t use this guide

The reason I say this should be used for lab environments is because you really should use a commercial and trusted third party supplier of SSL certificates with Exchange 2007, it will save you a lot of time and aggravation over using a ‘Private CA’ certificate process. The problem with self signed certificates and Private CA issued certificates is that they are NOT TRUSTED by client devices, and so for the devices to use SSL successfully you have to import the SSL certificate or add the CA to the list of ‘trusted root certificates’. This can be achieved using a GPO for domain joined PC’s (this is outside the scope of this document) or you have to manually install the certificate on non-domain devices – PC’s and mobile devices alike.

Prerequisites:

Windows 2008 Standard

Exchange 2007 (tested to work this SP1 and SP2)

Step 1 – Install the root certification authority role:

You will need to install the server role called ‘Active Directory Certificate Services’.

Go to ‘Server Manager’ –> ‘Add Roles’ wizard –> Choose ‘Active Directory Certificate Services’ –> Next –> Choose ‘Certification Authority’ only (don’t need the other role services) –> Enterprise –> Next –> Root CA –> Next –> Create a new private key –> Keep all defaults here (2048 length / RSA Sha1 key) –> Keep Common Name as default –> Next –> Valid for 5 years should be fine as this is just for testing, change if you wish –> Next, Finish

You should now have a Certification Authority from which you can process certificate requests. Next is on to creating the certificate request for exchange 2007.

Step 2 – Create the UC \ SAN certificate request

I would highly recommend navigating to the Digicert website and making use of their ‘free to use’ tool for creating a Exchange 2007 UCC cmdlet.  (at time of writing this could be found at https://www.digicert.com/easy-csr/exchange2007.htm)

All in all you will need to include the ‘fully qualified domain name’ as specified for external access. The server NetBIOS name and distinguished name for internal access PLUS the autodiscover reference (autodiscover is a tool used for automating the configuration of Outlook 2007 clients and providing the URLs necessary for the availability service etc, this is outside the scope of this document).

So, if you wish your external users to access the service using mail.domain.com and your internal domain name is domain.local with a server name of ‘server’ then you would want the following as SAN names:

mail.domain.com

autodiscover.domain.com

server.domain.local

server

Note: Make sure you include the common name of the certificate as a ‘Subject Alternative Name’ as well. In the example this is mail.domain.com

Alternatively you can use the New-ExchangeCertificate cmdlet as below:

New-ExchangeCertificate -GenerateRequest -Path c:\domain.csr -KeySize 2048 -SubjectName “c=GB, s=TheState, l=TheCity, o=TheOrgName, ou=TheDeptName, cn=mail.domain.com” -DomainName mail.domain.com, server.domain.local, server, autodiscover.domain.com -PrivateKeyExportable $True

Note that we are using the -GenerateRequest here which basically tells exchange to create a ‘request’ for a CA to process rather than creating a self-signed certificate. This is an important distinction.

Then we use the ‘certreq’ command to import the request file and generate us a certificate. (Note that you could try this by using the ‘Certification Authority’ directly but will be prompted with an error, because standalone CA’s do not use certificate templates – see http://support.microsoft.com/kb/910249. For this reason, we can bypass the problem by using either the web enrollment OR the certreq.exe command as below.

certreq.exe -submit -attrib “CertificateTemplate:WebServer” c:\domain.csr.

This will generate a .cer file for us to import into Exchange.

Step 3 – Process the certificate request file

Using the generated .cer, go into Certificate Authority MMC (Start –> Search –> type ‘Certification Authority’) –> Go to issued –> Go to certificate -> Open –> Details –> Copy to file –> Cryptographic message syntax standard -PKCS #7 Include all certificates in the path –> Export –> Export as C:\domain.p7b.

Now with the .p7b you can use this with the Import-ExchangeCertificate and Enable-ExchangeCertificate commands.

Step 4 – Importing the certificate and attaching the relevant services

Open up Exchange management shell and type:

Get-ExchangeCertificate

This will show you all the certificates on the system with their associated thumbprint. The thumbprint of the certificate uniquely identifies it. Each certificate will have a unique thumbprint even if all other details are the same.

Type:

Import-ExchangeCertificate -Path C:\domain.p7b

Once the certificate has been imported, you can attach the certificate to the relevant services.

The services are as follows:

IMAP – For secure IMAP services

POP – For secure POP services

UM – For Unified messaging

IIS – For autodiscover \ owa \ oab and other web related services

SMTP – For TLS communication

None – To set a certificate to have no associated services.

Use Get-Exchangecertificate command and record the thumbprint for the new certificate. you can right click shell window –> Mark –> Highlight thumbprint –> Hit Enter to place the thumbprint in the clipboard.

Enable-ExchangeCertificate -Thumbprint <your thumbprint> -services IIS, POP, IMAP, SMTP,UM

That is all that is required on the server side. You should now be able to run Get-Exchangecertificate and see all services attached.

Step 5 – Importing the ‘certificate authority’ to client devices

There are a number of ways to install the certificate to devices. The method describes below works for me and should work for you.

On the server –> Go to IE –> Internet Options –> Content –> Certificates –> Go to Trusted Root Certificate Authority –> Export –>

Cryptograpyhic Message Syntax Standard (.P7B) + Include all certificates in the path –> Export.

Then on the computers you need to TRUST the ‘certificate authority’ certificate, simply IMPORT this certificate into Trusted Root Certification

Authority using Internet Explorer Import command (make sure it is imported into Trusted Root Certification Authority when prompted by Import routine).

For mobile devices, copy the file to the Windows Mobile device, and then using the phone, select the certificate file and allow this to import.

Conclusion

After this you should be able to go to the URL for OWA https://mail.domain.com/owa and not get ANY certificate warnings.

You should be able to use Outlook Anywhere without any certificate warnings, and Activesync with SSL should work fine too.

As long as you have created the autodiscover.domain.com public DNS record, autodiscover will work too when it returns the https:// URL’s.

Feedback always welcome. Hope you found the article useful.

Based on information found in the following articles:

http://technet.microsoft.com/en-us/library/cc772393(WS.10).aspx – Active Directory Certificate Services Step-by-Step Guide

http://technet.microsoft.com/en-us/library/bb851554.aspx – Understanding the Self-Signed Certificate in Exchange 2007

http://www.exchangeinbox.com/article.aspx?i=127 – Replacing the Exchange 2007 Self-Signed Certificate

http://support.microsoft.com/kb/910249 – You may receive a “The request contains no certificate template information” error message when you submit a CSR to an enterprise CA”

http://technet.microsoft.com/en-us/library/aa997231.aspx– Enable-ExchangeCertificate

Advertisements

6 Responses to “Create UC SAN Private CA issued certificate to replace self signed certificate Exchange 2007”

  1. JRV said

    Very useful article! Thanks for gathering it all in one place. I’d hate to have to go through all the trial-and-error that probably went into it!

    Tip: If your Exchange 2007 server is published through ISA, and you’re using Forms-Based Authentication on ISA for OWA in Bridge mode, this will save you having to buy an extra copy of your 3rd party cert for the Exchange server. You can use a private SAN cert from an Enterprise CA on Exchange, provided that ISA and all your internal clients are domain members, because they will automatically trust your Enterprise CAs. If ISA or internal clients are workgroup members, however, you’d have to manually install the CA cert in Trusted Root Certification Authorities, as described in the article above.

  2. Brian Wing said

    Shaun,
    This is a nice little summary, I’m wondering if you have had any experience with an issue I’ve been having, pretty much since we migrated to exch2007 from 2003 2 years ago.

    Here’s the scenario: We purchased a SAN cert with a 2 public names and the cas server internal names. We ran into some issue (can’t recall exactly what) but the clients threw an error when the primary name on our cert was exchange.domain.com, so we ended up setting the common name for the cert to be foo.domain.com and exchange.domain.com as a SAN, in addition to the cas1.domain.local and cas2.domain.local.
    Now, because of all of that mess we have some strange Autodiscover behavior. Thanks to one of your other posts I reviewed our external URLs for OWA, etc (no UM) and they are all exchange.domain.com and I’m wondering if they shouldn’t be foo.domain.com since that’s the primary name on the CERT.

    Anyhow, just wondering if you have any thoughts on this. Sorry for blathering on and hopefully what I said makes some sense.

    Thanks
    Brian

  3. Doug said

    Great article. Thanks.

  4. Doug said

    Also, has this been tested with Exchange 2010 SP1?

  5. Greatest !!! Finally i found this solution.
    Thanks a lot for the article.

    -Irawan-

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: