Certificates have an important role in the Exchange messaging system. They validate the server to which users connect when accessing email (Client Access role). They are part of the encryption process that protects access to the email server and also (optionally) the sending and receiving of messages between servers on the Internet (Hub Transport role).
Although other options are possible (self-signed certificates, use of a local certificate authority), the best practice consists in obtaining a certificate from an external third party certificate authority. Unlike self-signed or locally issued certificates, these certificates will be trusted by all clients, domain members or not.
If we have selected this option (third party certificate), we probably already have such a certificate on the Exchange 2007 server (or servers). But migration from Exchange 2007 to Exchange 2010 usually requires the purchase of an new certificate that will replace this existing certificate.
Why? Because at some point, we will redirect both mail flow and client access operations to the Exchange 2010 server instead of the 2007 server (to "keep it simple", I will assume, for the moment, that there are only two servers). This involves changing DNS records and Client Access URLs.
In my case, I use the following name:
mail.mitserv.net
At this time, the associated DNS record points to the Exchange 2007 server.
What will happen when we point that record to the Exchange 2010 server? How will clients find the Exchange 2007 server then?
I should clarify that unless the migration can take place quickly (overnight or over the weekend), there will be a period of "coexistence" during which users will access either the 2007 or 2010 server. This all depends on one factor: has their mailbox been migrated yet, or not?
We also need to remember that if the mailbox is on an Exchange 2007 mailbox server, there must be an Exchange 2007 client access server in the same site, and likewise for a mailbox on an Exchange 2010 server. In other words, an Exchange 2007 CAS cannot provide client access to a mailbox on an Exchange 2010 mailbox server and vice versa.
Consequently, we must have a mechanism allowing the Exchange 2010 server to redirect clients with a mailbox on an Exchange 2007 server to an Exchange 2007 CAS (which may be the same server as the mailbox server, of course).
This is accomplished by changing the appropriate URLs on the Exchange 2007 server to:
legacy.mitserv.net
instead of...
mail.mitserv.net
Of course, the domain name will vary from organization to organization. Moreover, the use of the word "legacy" is a convention - we could use another term. At any rate, we must change the DNS records as well so they reflect the new locations.
But what does this have to do with certificates?
The name "legacy.mitsev.net" must be added to the subject alternative names of the certificate used to validate the identity of the Client Access server. Since the Exchange 2010 server needs a certificate regardless, the preferred method is to obtain a brand new certificate from the external third party authority, import and enable the certificate on the Exchange 2010 server, then export the certificate and import and enable it on the Exchange 2007 server. Yes, we want the same certificate on both servers and then on any other Exchange 2010 servers that may be added later.
Create New Certificate Request
First, we create a certificate request on the Exchange 2010 server. We have the option of using either the GUI or Powershell. This is an improvement from Exchange 2007 where there was only the Powershell option. I'll simply use the familiar (for me at least) Powershell option.
Here is the command:
[PS] C:\>$Data = New-ExchangeCertificate -GenerateRequest:$True -subjectName "c=CountryCode, s=My State, l=MyCity, o=My Organization, CN=mail.mitserv.net" -DomainName mail.mitserv.net, autodiscover.mitserv.net, legacy.mitserv.net -Keysize 2048 -privatekeyExportable:$true
[PS] C:\>Set-Content -path "C:\Certs\mitserv.csr" -value $data
I wrote "familiar" but, in fact, the New-ExchangeCertificate cmdlet used with Exchange 2010 is different. The -path parameter no longer exists and we have to use the Set-Content parameter to create the request file.
--------------------------------------------------------------
Instead of the Set-Content cmdlet, we could use the following:
[PS] C:\>$data | Out-File C:\Certs\mitserv.csr
---------------------------------------------------------------
For comparison, this is what the command looked like in Exchange 2007:
New-ExchangeCertificate -GenerateRequest:$True -subjectName "c=CountryCode, s=My State, l=MyCity, o=My Organization, CN=mail.mitserv.net" -DomainName mail.mitserv.net, autodiscover.mitserv.net, legacy.mitserv.net -Keysize 2048 -privatekeyExportable:$true -path "C:\Certs\mitserv.csr"
This produces a text file at the location indicated in the -path parameter.
Note: the file extension for the request file can be .csr or .req or .txt
Note: if you want to use the certificate on multiple servers, make sure the value of the -privatekeyExportable parameter is "true". If not, the certificate cannot be exported (with its private key) and used elsewhere.
Submit the Request to the Certificate Authority
Although the exact interface will differ between certificate authorities, the general procedure is the same.
We open the .csr file, in Notepad for example, highlight the content and copy.
Note: the content will look like this (truncated):
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEMDCCAxgCAQAwZDEZMBcGA1UEAwwQbWFpbC5taXRzZXJ2Lm5ldDEWMBQGA1UE
CgwNRGF2aWQgTWFjaHVsYTEPMA0GA1UEBwwGQWxiYW55MREwDwYDVQQIDAhOZXcg
[...]
KmkHv/J3wJBIPMFzYA958ix3e09jnzTGmCSwMOPSDDTWj0Z7nGQOICva8+9HEy6m
bjYs/lpEXWpY3C2q/bYrbFTXO60=
-----END NEW CERTIFICATE REQUEST-----
Note: include the Begin and End header/footer in the copy and paste operation.
We would then paste the content in the text box provided by the certificate authority on their website. Usually, we logon to the site in question, access some sort of management console, paste the text in the proper location and click "submit". The certificate authority will attempt to verify that we own the domain names that will appear on the certificate. This usually involves responding to an email. Once approved, we receive an email with a link to the certificate. We click on the link (we will probably have to logon to the website again), and download the certificate.
In fact, we will probably download a file (in my case a .zip file) containing the certificate requested and an intermediate certificate. I extracted these files and placed them in an easily accessible location (at the root of the C: drive for example). The next step is to install these files, first the intermediate certificate (if there is one) and then the certificate that we requested for our organization.
Install the intermediate certificate (if applicable)
First, we create a custom MMC (Microsoft Management Console) and add the "Certificates" snap-in (File | Add or Remove Snap-ins | Certificates (Local Computer)).
Note: the snap-in should manage certificates for "Computer Account".
Next, we open the Certificates (Local Computer) snap-in, navigate to "Intermediate Certification Authorities", Certificates, right-click, select "All Tasks" and then "Import".
At this point, it is essentially a matter of following the prompts, navigating to the location of the certificate and installing it in the Local Computer certificate store. In fact, once the operation is completed, we should see something like the screenshot above. In my case, the two Starfield certificates have been added.
Now we can install (or "import") the certficate requested for our organization.
Import and Enable the Exchange Certificate
This is the cmdlet that imports the Exchange certificate:
[PS] C:\>Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -path "C:\Certs\458c16fd3f3\458c16fd3f3.crt" -Encoding byte -ReadCount 0))
Note: some may notice that this cmdlet is different from the cmdlet used with Exchange 2007. That is indeed the case. The Exchange 2007 cmdlet does not work with Exchange 2010 (an error message will display).
Next, we have to enable the certificate. Since several certificates may be present, in particular the Exchange self-signed certificate, we need to identify the certificate that we recently downloaded. Although we can use the domain name for this, I prefer to use the thumbprint (which is unique. Another certificate - a previous certificate - may have the same domain name).
[PS] C:\>Get-ExchangeCertificate
Thumbprint Services Subject
---------- -------- -------
BAE508AE4F24D9312A64C-----4B3 ...... CN=mail.mitserv.net, OU=Domain Control Validated
372D7D27CD203E7FF514159-----856 IP.WS. CN=EX13-1
In this case, we have two choices. The correct certificate here is the one ending in 4B3 (yes, I have abbreviated the thumprint). So we copy the thumbprint and paste it in the following command:
[PS] C:\>Get-ExchangeCertificate BAE508AE4F24D9312A64CE-----4B | Enable-ExchangeCertificate -Services IIS,SMTP,POP,IMAP
We will be prompted to confirm the operation and replace whatever certificate is being used. We can type Y and enter, or simply press "Enter" (the default).
Now the Exchange 2010 server is ready to provide access to clients using OWA, Outlook Anywhere, and ActiveSync. It is also ready to provide encrypted TLS connections with other mail servers, preferred or required as the case may be (Hub Transport role).
Note: POP and IMAP do not have to be included if we have no intention of using either. IIS is for client (web) access and SMTP is for mail transfer between (SMTP) servers.
Export the Certificate for Use on other Servers
If we want to use the certificate on another server, on the Exchange 2007 server (which we do), on a second Exchange 2010 server, or perhaps on a server with ISA/TMG, we cannot simply copy the downloaded .crt file to those computers and import it as we did above. If we try, an error message will display, indicating, in summary, that the private key is missing.
Instead, we have to export the certificate using the cmdlet I will present in a moment and then import the certificate on those other servers. We would also want to import the intermediate certificate provided by the external third-party authority (we can use this certificate directly - there is no need to export it first).
There is one prerequisite: when we created the certificate request at the very start (see above), we should have added this line:
-privatekeyExportable:$true
The value must be "true".
Now we export the certificate so we can use it on the Exchange 2007 server or another Exchange 2010 server. Here is the cmdlet that exports the certificate:
[PS] C:\>$file = Get-ExchangeCertificate BAE508AE4F24D9312A64CEDFACA3DBBF0342A4B3 | Export-ExchangeCertificate -BinaryEncoded:$true -Password (Get-Credential).Password
We will be prompted to enter a username and password. In fact, the username is a formality (it will not be verified for the subsequent import) but we must enter a password.
Import the Certificate on the Exchange 2007 server
Now we can copy the certificate to the Exchange 2007 server (remember, we want to use the certificate that includes the legacy.mitserv.net subject alternative name).
We execute this cmdlet to import the certificate...
[PS] C:\>Import-ExchangeCertificate -path "c:\scripts\mitserv.pfx" -Password:(Get-Credential).Password
We enter the password when prompted...
And then enable the certificate for use with IIS (client access) and SMTP (hub transport operations) - and optionally POP and IMAP:
[PS] C:\>Get-ExchangeCertificate -thumbprint BAE508AE4F24D9312A64CE-----4B | Enable-ExchangeCertificate -Services IIS,SMTP,POP,IMAP
Now, at least as far as certificates go, both servers are ready for the migration operations that will take place later.
***
Note: if we want to import the certificate on another Exchange 2010 server, we would use the command below (different from the command used for Exchange 2007 above):
[PS] C:\>Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -path "c:\certs\mitserv.pfx" -Encoding Byte -ReadCount 0)) -Password:(Get-Credential).Password
Thank you for reading the article about Exchange 2010 (SP3) - Migration - Part 2 - Certificates 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.