How To Create A New Certificate For Exchange 2007

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:

1. On Exchange 2007 create a Certificate generation request.
2. Submit the request to the public/private Certification Authority.
3. 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
-GenerateRequest
-Path c:\setup\cert_request.csr
-SubjectName "c=MT, o=ExchangeInbox, ou=IT, cn=owa.exchangeinbox.com"
-DomainName: owa.exchangeinbox.com, autodiscover.exchangeinbox.com, exchsrv, exchsrv.exchinbox.local
-KeySize 1024
-PrivateKeyExportable: $true

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:

'The request contains no Certificate template information. 0x80094801 (-2146875391) Denied by Policy Module 0x80094801, the request does not contain a Certificate template extension or the Certificate Template request attribute.'

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.

References

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

Certificate Use in Exchange Server 2007

How To Create A New Certificate For Exchange 2007

Source: http://www.exchangeinbox.com/article.aspx?i=127

Posted by: robertsonbeirch1984.blogspot.com

Share this post