Installing a third-party certificate on Exchange (2007 - SP3)
In messaging systems, such as Exchange, certificates validate a mail server's identity and constitute a foundation for the encryption of communications between the mail server, other mail servers, and clients.
The subject is both vast and complex so before a very brief introduction below, I will refer those unfamiliar with certificates to these articles:
Introduction to Digital Certificates (Verisign Australia)
Introduction to Digital Certificates (Comodo)
Since links can change, the reader might do as well to use the terms above in an online search using Bing or Google or another search engine.
***
Certificates exist in several forms and can come from many sources.
Some certificates are "self-signed". This means that the server hosting the application in question, Exchange in our case, signs them. This provides basic functionality when setting up an Exchange server but is very limited because other entities (other mail servers, clients accessing mail via a web browser) have no reason to trust a unknown certificate from an unknown server that has just been installed.
We can obtain a certificate from our organization's certificate server, if we have one of course. This is what we could call "a step in the right direction". In the Microsoft Active Directory domain, domain member client machines will trust certificates issued by a "certificate authority" that is part of the domain. On the other hand, other companies would have no reason to trust these certificates, nor would computers that are not members of a domain, such as laptops or tablets being used to access email from home.
The best option is to obtain a certificate from a "third-party" certificate authority, that is, a company like Verisign, Comodo, Digicert, GoDaddy or Thawte. Such certificates are trusted by practically all web browsers.
In this blog post, I will present a step-by-step process for obtaining a certificate from a third-party provider and installing the certificate on the Exchange server.
I'll organize the process in 4 steps:
Step 1 : Create a certificate request at the Exchange server.
Step 2 : Submit the content of the resulting file to the Certification Authority
Step 3 : Download the certificate
Step 4 : Import and Enable the certificate for Exchange services.
***
Create a certificate request at the Exchange server.
We can create the certificate request in the Exchange Management Shell (EMS) using the Powershell "New-CertificateRequest" cmdlet. This is the only option in Exchange 2007. In Exchange 2010 and 2015, we can use a graphical interface as well.
There are a number of possible variations but the cmdlet and parameters shown below work with the third-party certificate authority to which I will submit the request in a later step.
New-ExchangeCertificate -GenerateRequest:$True -subjectName "c=us, s=MyState, l=MyCity, o=My Name, CN=mail.mitserv.net" -DomainName mail.mitserv.net, autodiscover.mitserv.net -Keysize 2048 -privatekeyExportable:$true -path "C:\Scripts\mitserv.csr"
Let's dissect this rather long command...
- New-ExchangeCertificate: this is the cmdlet itself. Without the parameters and values that follow, however, it would not produce any results.
- GenerateRequest: the value of this parameter must be set to "true" for the creation of an actual request.
- subjectName: here, we must enter, from left to right, the code of our country, our state (or province), our location (we can name our city), our organization (or name, if we are an individual) and the name of our domain. I use the name of a fictitious organization that I use for tests, just as Microsoft has a number of fictitious organization names such as Constoso and Trey Research. Note: instead of "mitserv.net", I used the name that would be used most often - "mail.mitserv.net" -, which was recommended at one point, for some reason, by someone, from the certificate authority. In any case, if you want to use a name with any Exchange service (POP, IMAP, IIS, SMTP), and if that service may need to be validated, the name should be on the certificate.
- DomainName: one of the roles of the certificate is to validate our website (or webmail, Outlook Web Access in the case of Exchange). Therefore, the domain name of our website must be indicated on the certificate. With Exchange, we may have several other names, such as those indicated above, for webmail, for autodiscover and perhaps the name of the mail server itself (or themselves if we have several). What names should be on the certificate? This is a subject in itself, but the most common recommendation is to add the name used for webmail and the name used for autodiscover.
- Keysize: validation is one role of the certificate and encryption is another (even though the certificate does not encrypt anything by itself). The size (or length) of the encryption keys is one element that determines the strength of the encryption. At this time (2015), the minimum recommended key size is 2048 bits.
- privatekeyExportable: if we ever want to export the private key, and then import it on a second mail server or a security appliance like ISA or TMG, we should set the value of this parameter to "true".
- path: this is simply where we want to create the certificate request file and where we can find it when we want to upload it to the website of the certificate authority for ordering.
I realize that this information may not be entirely clear to some readers. Private key? As opposed to... public key? I prefer not to provide a more detailed explanation for a number of reasons. First, encryption is not the subject of this post. I would recommend that those interested in more details refer to the multitude of resources online. Second, what I have provided above is a simple example. The general configuration of the cmdlet is valid for all certificate requests but details may vary with different certificate authorities. Some may accept a smaller keysize or, by the time you read this, require a larger keysize. Another example: the file extension of the request is .csr above but can also be .req.
If the command line option seems too obscure, despite my attempt to explain the process, the reader may use a web-based assistant, such as the tool provided by Digicert, one of the best known certificate authorities:
It is still necessary to copy and paste the resulting command in the EMS to produce the request but the wizard will help you construct it.
Submit the content of the request file to the Certificate Authority
The New-ExchangeCertificate cmdlet creates what is in fact a text file. If we open it, we will see something like this (abbreviated for concision):
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEATCCAukCAQAwZDEZMBcGA1UEAwwQbWFpbC5taXRzZXJ2Lm5ldDEWMBQGA1UE
[snip]
Sfy4Dsp/FjZxLlKojFSZLtU1xbJyVi6Y4vdiP1DOziW9aJTYOSo/TYaOMpU3GlS5
ZfM6vaOs22SQnk/etKryTiHHl+hD
-----END NEW CERTIFICATE REQUEST-----
We must copy and paste this content (including the header and footer - the BEGIN NEW CERTIFICATE REQUEST and END NEW CERTIFICATE REQUEST) into a text box of the certificate authority's website.
I will use the website of "Certificates for Exchange" in this example. Of course, the process outlined by the certificate authority you select may be different.
Note: some CAs apparently allow the requestor to uphold the entire file, no copy and paste required.
Note: some CAs apparently allow the requestor to uphold the entire file, no copy and paste required.
***
I will not include step-by-step instructions for creating an account, logging on and purchasing (the rights to) a certificate. Each certificate (or certification) authority is different. If these steps prove challenging, there is usually a contact number for technical assistance.
So we logon and arrive at the "My Account" page:
We expand SSL Certificates and arrive here:
Further to the right, on the same page, there is a "Launch" button:
Click on the "Launch" button. We should then have a screen like this:
Copy and paste the content of the .csr file (you can open it with Notepad, for example), into the text block. Be sure to include "BEGIN NEW CERTIFICATE REQUEST-- and --END CERTIFICATE REQUEST----"
In the area below, enter your subject alternate names (SAN - not to be confused with a storage area network):
The selection of these names is a subject in itself (we already saw them in the creation of the certificate request file), but it is most common to use something like mail.contoso.com or webmail.contoso.com for OWA (Outlook Web Access) and then autodiscover.contoso.com for the autodiscover functionality.
Click on "Next" (off the screenshot, to the right).
I was instructed to enter all the names I wanted on the certificate, even though it appears that the domain name is "mail.mitserv.net".
I click on "Next" once more and a message displays stating that my certificate will be ready shortly.
If I continue, I should arrive at the following page, where I can see that the request status is "Pending":
There should be some sort of confirmation process, usually an email sent by the certificate authority to validate the request. So check your email. In my case, the message body was like this (excerpt):
"Dear Secure Certificate Customer,
We have received a Certificate Signing Request for the following mail.mitserv.net domain(s) :
autodiscover.mitserv.net
mail.mitserv.net
mitserv.net
Our query of the Whois database returned your name as the administrator for the domain in the certificate request.
In order to verify the validity of this request and that it was submitted by the entity to which the domain in the request is registered, please signify your final approval or disapproval of the certificate request by clicking the link below [...]."
So I click on the link and confirm the validity of the request:
Download the certificate
When I return to the web interface and "Launch" the certificate management tool, the page that displays reflects the fact that the certificate has been approved. This is a screenshot of a portion of that page where, among other options, I can download the certificate. Note that in the screenshot above, the download option was not enabled.
I download the certificate. In fact, I download a zip file from which I extract the certificate for my domain and an intermediate certificate. The website alerts us about this:
So we have a zip file named with the serial number of the certificate (not the thumbprint - which is something else we will see later):
We extract the two files from the zip file by right-clicking on it and selecting the "Extract" option (at least on current Windows operating systems). We then have these files that must be imported into the Exchange server's local certificate store:
Import and Enable the certificate(s) for Exchange services.
So we have two certificates to import: the intermediate certificate first and the certificate for our domain second.
And how do we proceed?
I've followed the directions provided by the certificate authority, using the "Certificates (Local Computer)" MMC for the intermediate certificate and the EMS to import my organization's certificate.
I've already created a custom MMC (Microsoft Management Console) for the intermediate certificate import. I'll assume that the reader either knows how to create such a console or at least knows how to perform an online search for directions. I will point out that the "Certificates" snap-in should target the local computer rather than the user.
1. Open the console, go to "Intermediate Certification Authority", right-click on this folder, select "All Tasks, "Import".
1. Open the console, go to "Intermediate Certification Authority", right-click on this folder, select "All Tasks, "Import".
3. Browse to the location of the downloaded files.
As shown below, it will be necessary to change the file extension type to "PKCS #7" so the intermediate certificate, with a .p7b extension, is visible:
4. We should have something like this:
5. Make sure the certificate is imported into the "Intermediate Certification Authority" folder.
6. We click on "Next" or "Finish". If all goes well, we should see this:
7. The certificate should now be visible in the certificate store, perhaps above a previous certificate.
Note: I asked the vendor if previous (expired) certificates should be removed. The technical support representative stated that this was not necessary.
***
At this point, we can import the certificate requested for our organization with the EMS. It's just as matter of entering the cmdlets (with various parameters and values) as shown below.
1. Open the EMS and browse to the location of the certificate. Import the certificate with this cmdlet:
[PS] C:\>Import-ExchangeCertificate -path C:\mitserv.net-2015\2b515b90\2b515b90.crt
Thumbprint Services Subject
---------- -------- -------
EC523--ABC9 ..... CN=mail.mitserv.net, OU=Domain Control Validated
Note: of course, your serial number and thumbprint (abbreviated here) will be different.
2. Enable the certificate (you can copy and paste the thumbprint from above):
C:\>Enable-ExchangeCertificate -Thumbprint EC523--ABC -Services "IMAP, IIS, POP, SMTP"
Note: after the "services" parameter, we must enter the services that will be used: POP, IMAP, IIS, SMTP and UC are the options.
We will be asked if we want to overwrite the previous certificate (if we have one):
Confirm
Overwrite existing default SMTP certificate '605033---D774B' (expires 12/13/2015 8:24:04 PM)
with certificate 'EC523F----------ABC9BDC' (expires 3/8/2015 10:32:06 PM)?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): A
I enter "A"... and press enter.
We can use the Get-ExchangeCertificate cmdlet to see the properties of the certificate (the thumbprint can be used to concentrate on the certificate in question). Use the cmdlet with no parameters to see all certificates - and their thumbprints - first. Then re-enter the cmdlet with the thumbprint.
***
Now users should no longer be confronted with a warning everytime they attempt to connect to Outlook Web Access (OWA) or be prompted for a password when they open Outlook (although password prompts in Outlook can have other causes as well).
Thank you for reading the article about Exchange 2007 (SP3) - Certificates - 3rd party - management on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.