Disclaimer:

All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

One of the tasks you will have to complete after installing Exchange Server 2013 is configuring certificates. Most Exchange-related traffic (including client traffic) is handled via HTTPS and thus they require some additional configuration to work properly.

Out of the box, Exchange Server 2013 will be using self-signed certificates. While these certificates (and the associated error messages) might be acceptable in a test-lab, they won’t be in production.

Although there is already a lot of guidance on this topic for Exchange Server 2010, I still regularly come across issues because of wrongly configured certificates. Hence, I decided to create this article to somewhat clarify the subject.

What certificates can I use?

As in Exchange Server 2010, Exchange Server 2013 can use both SAN certificates (recommended) or wildcard certificates.

What namespaces should I use?

The change in the client access model in Exchange 2013 (RPC over TCP to RPC over HTTP) has a positive impact on the design of your namespaces: ultimately, you need less namespaces then before.

Amongst the namespaces that you (potentially) need are:

• Client Access Array (Array of Load Balanced CAS servers)
• Autodiscover
• OWA Failback URL*
  * Whether or not you need the Failback URL, depends entirely on the setup of your environment. I will discuss the design and setup of an highly available Exchange Server 2013 environment in another article soon.

Configuring Certificates using EAC

If you aren’t re-using a certificate that you exported from another server earlier, you will have to create a new certificate request first. This request will provide you a DSR which you can use to generate the actual certificate.

1. Open the EAC and navigate to Servers > Certificatesand click the “+”-sign (New Certificate Wizard):
2. Click create a request for a certificate from a certification authority and click Next:
   
   
3. Type in a name for the certificate and click Next. Although you could enter just anything, it’s always interesting to make this name as descriptive as possible:
4. If you want to use a wildcard certificate, click the checkbox and enter your root domain. Then click Next.
   If you are notusing a wildcard certificate, you will be presented with the following screens first. On the first page, you can define what namespaces you are going to use for the different Exchange-services:

   After having clicked Next, you can manually add or remove namespaces to be included on the certificate. Once ready, click Next.
   

5. Select on which server to store the certificate and click Next:
6. Enter your organization details and click Next.
7. Enter the location where you want to save the certificate. The location should be entered as a UNC path. Then click Finish:

Before continuing, verify that the certificate request file has correctly been created. The file will contains a DSR which you can use to request your certificate from your CA. This CA can be a private of public one.

Your DSR will look something like this:

—–BEGIN NEW CERTIFICATE REQUEST—–
MIID5TCC5s0C5Q5w5j5SMB5G51U55wwJZXhibG9nLmJlMQ8wDQYDVQQLD5ZF5GJs
b2cxCz5JBgNVB5oM5klUMQ8wDQYDVQQHD5ZW5WNodGUxGD5WBgNVB5gMD1dlc3Qt
VmxhYW5kZXJlbj5LM5kG51U5BhMCQkUwgg5iM50GCSqGSIb3DQ5B5QU554IBDw5w
gg5K5oIB5QDcTxGgG8NTjxR5boNJii76SOXwz1Zs75ZwFKj3bSn8mhd55+u4uwn5
R1zrMvV55+35ccdn8OPxbmPJISK9q58O750nOU+tM5kRxmHR571d5lRvL6MtqYsS
337hshIFMOFNOo9Ln/U05WrGJcxCnC52tFlzhBbRLzBWwFQCHnCjS13o4j2PdF0d
gxgQ0s/N5wmWW53L1Vh85+Ri58zlC2+tskocRymVorldM3yDYlm9ZgCxX750/5QT
…..

—–END NEW CERTIFICATE REQUEST—–

Once you have received the certificate from your CA, we can now continue to configure the certificate.

1. From the certificate overview window, click Completein the actions-pane:
2. Enter the location where you stored the certificate. The location should be entered in UNC format. Then, click OK:
3. The certificate request should now be completed successfully. Verify that the certificate shows up in the certificate list and that it’s status is valid:

Although the certificate has been installed on the server, it has not been activated yet. Before a certificate is used, you need to assign services to it.

1. From the certificate overview, select the newly added certificate and click Edit:
2. On the properties page, select Services and select the appropriate service (e.g. IIS). Afterwards click Save:
3. Verify that the certificate is installed and configured correctly by browsing to Outlook Web App. This should not throw a certificate warning. If there is a certificate warning, either something went wrong or your certificate does not contain all the namespaces you’re using.

If you have multiple servers, you can either repeat the process above for each server or if you will be using a single certificate for all servers (e.g. when using a wildcard certificate), you should import this newly added certificate on other servers.

1. From the certificate overview, select the certificate and click the three dots (…). From there, select Export Exchange Certificate:
2. Enter a path where the certificate should be saved and type in a password to protect the certificate. The path should be entered in UNC format. Afterwards click OK:
3. Verify that the certificate was exported successfully:

Next, you will have to import the certificate on each server that will be using the certificate.

1. From the certificate overview, select the certificate and click the three dots (…). From there, select Import Exchange Certificate:
2. Enter the UNC where you previously exported the certificate to and provide the password you chose earlier. Click Next:
   
   
3. Select the server(s) to which you want to import the certificate to. Then click Finish:

   

4. Verify that the certificate has successfully been imported to the different servers by selecting the server from the drop-down list on the certificate overview page. The imported certificate should be in the list and it’s status should be valid:

All that’s left to do now, is to assign services to these certificate on each server. The process is identical as described before.

Configuring certificates using PowerShell

The more servers you have, the longer it might take to perform the actions using EAC. Alternatively, you can also use PowerShell to request, import and export exchange certificates:

1. Open the Exchange Management Shell and type in the following command. This will create the certificate request “DSR” which you can use to request a certificate from your CA:

   $newcert = New-ExchangeCertificate –GenerateRequest –SubjectName “c=BE,o=EXBLOG,cn=webmail.exblog.be” –DomainName “autodiscover.exblog.be” –PrivateKeyExportable $true
   $newcert | out-file c:\certreq.txt

   

   c= is used to denote the country by it’s international code. e.g. “BE = Belgium”
   o= is used to denote the organization e.g. “Exblog”
   cn= represents the common name of the certificate.
   DomainName represents the (Subject Alternative) Names to be included on the certificate.
   

2. Once you’ve received the certificate from your CA, it’s time to import/install it onto the server (= completing the request):

   Import-ExchangeCertificate –FileData ([byte []]$(Get-Content –Path “c:\CertificateFromCA.cer” –Encoding Byte –ReadCount 0))

   

3. Next, we need to assign services to this certificate:

   Get-ExchangeCertificate –ThumbPrint <thumbprint> | Enable-ExchangeCertificate –Services IIS,SMTP

   

   Note   While enabling the certificate you will get a warning that this will actually overwrite the existing certificate. You can safely overwrite the default self-signed certificate.
   

4. Now that the certificate has been installed on the first server, we need to export it and import it on our other servers:

   $certexport = Get-ExchangeCertificate –DomainName “webmail.exblog.be” | Export-ExchangeCertificate –BinaryEncoded:$true –Password (Get-Credential).password
   Set-Content –Path c:\cert_export.pfx –Value $certexport.FileDate –Encoding Byte

   

   Note   when running the first command, you will be prompted for a username and password. You can type whatever you want for the username, as this value will be ignored. However, remember the password as you will be using it later to import the certificate into another server.

   To import the certificate into another server, use the following command:

   Import-ExchangeCertificate –FileData ([byte[]](Get-Content –Path <path_to_exported_certificate> –Encoding Byte –ReadCount 0)) –Password (Get-Credential).password –Server <servername>

   

   Note   you will be prompted for a username and password. You can type any value for the username, but the password should match the one you selected earlier while exporting the certificate.

   If you have multiple servers to which you want to import the certificate to, you could script the execution of the command above like this:

   $servers = Get-ClientAccessServer | Select Name
   foreach($server in $servers){
   Import-ExchangeCertificate –FileData ([byte[]](Get-Content –Path <path_to_exported_certificate> –Encoding Byte –ReadCount 0)) –Password (Get-Credential).password –Server $server.name
   }

5. Enable the newly imported certificates by assigning services to it. Do this for each server to which you imported the certificate:

   Get-ExchangeCertificate –DomainName “webmail.exblog.be” | Enable-ExchangeCertificate –Services IIS,SMTP

Clearly, PowerShell is thé choice once you have multiple servers in your organization: in just a few steps you created, exported and imported a certificate on multiple servers