Replacing the Exchange 2007 Self-Signed Certificate (Part 2)

Alexander Zammit has been developing server applications for over 15 years. Most of his works involve Exchange integrated applications, including a FAX server, a mail security product and anti-spam products.

Installing a new Certificate involves, creating a Certificate request on Exchange 2007, submitting the request to a Certification Authority and installing the returned Certificate on Exchange. Here is how we went about completing these steps.

In Replacing the Exchange 2007 Self-Signed Certificate (Part 1) we looked at the choice between public and private Certification Authorities CAs. For the latter, we walked through the installation of Certificates Services on Windows 2008. We also discussed the Certificate Subject, Subject Alternative Names SAN and wildcards. In this discussion we identified the need for a Certificate covering the names:
owa.exchangeinbox.com
autodiscover.exchangeinbox.com
exchsrv
exchsrv.exchinbox.local

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

Replacing Certificate on Exchange 2007

Installing a new Certificate in general involves these three steps:

On Exchange 2007 create a Certificate generation request.

Submit the request to the public/private Certification Authority.

Install the returned Certificate on Exchange 2007.

Managing Certificates on Exchange is done through the shell using the ExchangeCertificate cmdlets. For example running Get-ExchangeCertificate on my test machine I got three Certificates listed:

Normally we would only get the last Certificate, here having a thumbprint starting with C52A. The other two Certificates were created on installing the Certification Authority and are not in use by any Exchange services. We take a closer look at this Certificate identifying it using the thumbprint.

Note: This article uses Certificate thumbprints a number of times. In your case you have to replace these with the thumbprints taken from your own Exchange installation.

Generating a request involves running the New-ExchangeCertificate cmdlet. This is the part requiring most planning. Here we have to get the names right as discussed in the first part of the article. In my case I used the following cmdlet:

New-ExchangeCertificate is fed with the GenerateRequest parameter showing that here we are not truly creating a new Certificate but just a request. The resulting request will be saved to disk at the specified path base64 encoded. The SubjectName and DomainName are the parameters identifying the Certificate Subject and Subject Alternative Name extension respectively.

The SubjectName is an X.500 Distinguished Name DN identifying the Certificate user (owa.exchangeinbox.com). A public CA will check this value carefully before issuing a Certificate. It is their job to make sure you are who you claim to be. If using a private CA, you would still want to choose a DN that is representative of your organization and the entity using the Certificate.

At the DomainName we just list all names discussed earlier. If using wildcards we could have instead used:
-DomainName: *.exchangeinbox.com, exchsrv, exchsrv.exchinbox.local

Running New-ExchangeCertificate successfully creates a new entry in the Exchange Certificate list. Of course we also get the request itself saved at the specified path.

We now hand the request to the Certification Authority. If using a public CA we submit this through their web interface. A private CA using Certificates Services provides a number of options. The Certificates Services web enrolment interface requires us to paste the content of the request file. In this case we would paste everything including the Begin/End header areas.

For a walk through the procedure for submitting the request to Certificates Services, check the section that follows. For the moment let's just assume we got the Certificate back ready to be installed.

We should now have one or more files covering the Certificate chain. At this point it is most convenient to work with the PKCS #7 Certificate file having an extension of *.p7b that bundles the Certificate chain in one file. With this we go back to the Exchange shell and run the cmdlet that follows. Here certchain.p7b is the file returned by our CA:
Import-ExchangeCertificate -Path C:\setup\certchain.p7b

Exchange will now install the new Certificate. In the Certificates list returned by Get-ExchangeCertificate, this will replace the entry that was created on running New-ExchangeCertificate to generate the request.

Next using the cmdlet that follows, we assign the new Certificate all the services for this Exchange server:
Enable-ExchangeCertificate
-Thumbprint 98A5897324FE8952D72FB17CE0C46365DB132A42
-services IIS, POP, IMAP, SMTP

Calling Get-ExchangeCertificate we see how the new Certificate has taken over these services.

We may finally delete the old self-signed Certificate using the command:
Remove-ExchangeCertificate
-Thumbprint C52A264821E83E92173D5E44DC3DDEE0F8CBEB2F

Submitting Request to Certificates Service

To begin, I first tried to submit the request through the Certificates Services CA MMC interface to expose a well known issue.

Selecting the 'Submit new request' task prompts you to select the Certificate request file. However on doing so we get back the error:

To avoid this problem we could use the Web Enrolment service or the certreq.exe command line application. I did the latter, using the command line that follows. Note how the attrib parameter specifies a template that was the root cause of the previous error.
certreq.exe -submit -attrib "CertificateTemplate:WebServer" c:\setup\cert_request.csr

This will prompt us to select the CA to which the request is to be submitted and finally creates the Certificate for us. We can now retrieve the newly created Certificate from the Certification Authority MMC.

Opening the Certificate we can look at its properties. The General page shows how the owa.exchangeinbox.com Certificate was issued by our newly created private CA. The Certification Path page shows the hierarchical relationship between the Certificate and the CA. This chain could in practice be composed of additional sub-authorities that form part of this chain.

The Details page shows us the various Certificate fields. Have a look at the Subject and Subject Alternative Names. See how all four DNS names are listed.

The Details page also provides the 'Copy to File' button that launches the Certificate Export Wizard. Click this and proceed to the Export File Format Page.

Here we select the PKCS #7 Certificate and also set the checkbox for including all Certificates in the certification path. Following that, proceed to the file path selection step. Specify where the p7b file is to be saved and complete the wizard.

We should now have our p7b file ready for importing into Exchange 2007 as discussed in the previous section.

Final Tips

This concludes our walk through the installation of a new Certificate. Today we saw how using the Exchange 2007 shell we generated a Certificate request, imported the new Certificate and transferred the services from the self-signed Certificate. We also looked at how a Certificate request may be submitted to the Certificates Services CA that was installed in the first part of this article.

User Comments - Page 1 of 1

Hi Alex,Thank for your great instructions! I am stuck on a paragraph that you mentioned (After generated "Cert_request.csr" file. :

"We now hand the request to the Certification Authority. If using a public CA we submit this through their web interface. A private CA using Certificates Services provides a number of options. The Certificates Services web enrolment interface requires us to paste the content of the request file. In this case we would paste everything including the Begin/End header areas."

I don't know where to copy and paste for the "Certificates Services Web Enrolment Interface"? Could you advise?

Alexander, we've never met and probably never will, but if the stars ever do align to bring us together, I shall buy you all the beer you can drink. I have spent three days trying to figure this out, but thanks to your clear and concise instruction, I have finally resolved my issue. Thank you, thank you, and once more; thank you!

Rupesh
3 Sep 2011 12:31

Thanks a lot!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!You are genius, Keep up the good work. After spending many days on certificate i was not able to generate ca cert. This article did that in few min.Thanks once again!

Anand
30 Dec 2010 11:43

Great stuff, thanks.

Grant
21 Dec 2010 08:08

It took me a few hours to stumble upon article after article with bits and pieces for making this work. This article contained the most important part (for me) regarding converting my certificate request into the actual certificate using the certreq.exe command.

Derek
11 Jun 2010 09:42

I followed this example (with my own domain information) and after I finished, OWA no longer gave me the cert error and I was able to install the certificate on a mobile device and got it working. I am using a seperate mailbox server and a CAS server. The next time I opened outlook on my computer it started giving me an error saying that the certificate is trusted and the date is valid but the name doesn't match. Is this because when I told it to apply to all the services and it took away from the one needed for outlook to communicate with the mailbox server? If so, can you please tell me how to fix this in a multiserver environment? Thanks!

Alexander Zammit
8 Feb 2010 00:01

@Rob

That's because your certificate is not Self-Signed as per the definition given here:http://technet.microsoft.com/en-us/library/bb851505(EXCHG.80).aspx

Rob
6 Feb 2010 10:02

My only issue is that after requesting, issuing and installing a new exchange certificate, I noticed that IsSelfSigned attribute set to FALSE. Not sure what I'm doing wrong or if this is a problem.

Mike
5 Feb 2010 12:08

I love you.

I was about to eat my own head trying to get these certs in order-

Thanks!

Electro
23 Oct 2009 16:05

Fantastic! Thank you so much!

Ernesto
23 Jul 2009 10:46

Worked like a charm! Thanks!

Chris in Boston
26 Jun 2009 22:01

Wow! Thanks this worked perfectly. I suffered through trying to get this working and gave up. Your article allowed me to get it working and get activesync working with an iPhone. I appreciate your effort on this!

Tim from Philly
25 Jun 2009 08:27

This was great! I was unsure about some things and these instructions really helped. Thanks!

guruleenyc
12 Jun 2009 18:08

Awesome clear, concise and complete document! Thanks

softrocker
24 Mar 2009 04:21

Thanks a million. I have been trawling the net looking for this information. As we speak Mail for exchange, and all my windows mobile are receiving mails. Thanks alot.

whec65
13 Mar 2009 10:33

Great job! Details everything I need. Thanks.

ipas
4 Mar 2009 12:04

This is one kickass explaination. thanks!

Atramhasis
9 Feb 2009 02:32

Thanks, everything works now as expected!

Alexander Zammit
6 Feb 2009 09:04

1. There was a problem in Ex07 SP1 that was fixed in Update Rollup 4 concerning wildcard support. Details here:http://support.microsoft.com/kb/948896

2. Yes you should include the Certificate subject in the SAN list. I tested this and remember that I had problems if this was not done. Unfortunately I don't remember the details. However here is some in confirmation of this:http://www.digicert.com/subject-alternative-name-compatibility.htm

Atramhasis
6 Feb 2009 08:16

Thank you for this great Step-By-Step guide, on SBS08 it is so easy to handle certificates, but I had to do it now on a Server 2008 with Exchange 2007 and your article was very helpful. I have two questions though: 1. The wildcard domain did not work for me, I got an error. Are you sure you can just replace the subdomain by an asterisk? And 2. Is it necessary to put the main domain also in the SAN list?