Certificates are an important part of Exchange. They are needed for Exchange client connections and TLS encryption to be properly secured. By default Exchange installs a self-signed certificate in an attempt to secure the server from the start. However, this certificate should be treated as a temporary certificate to be replaced before the server is placed in production. The process of requesting and installing a certificate in Exchange is fairly simple, but there are some things you should be aware of.
There are several types of certificates that can be purchased:
- A standard certificate that includes only one name.
- A SAN certificate that allows you to include multiple names in the certificate. (This is the recommended certificate to use)
- A wildcard certificate that allows you to include all names under the root domain.
You also need to make sure that you have designed your Exchange namespace
appropriately. The namespace that I will be using in my lab is as follows:
- autodiscover.leenu.net – used for autodiscover DNS records
- mail.leenu.net – used for HTTPS and SMTP
To start, log in to the EAC and browse to servers and select certificates. You will notice that there are already several certificates listed. These are the default self-signed certificates that are installed by default. From this page we can to create a new certificate request. To do this, select the + icon to open the new Exchange certificate wizard. We want to create a request for a certificate from a certification authority.
Enter a name for the certificate. Make sure you choose something unique that will help you identify the certificate. This is the name that will show up in the EAC list.
In my case, I do not want to create a wildcard certificate.
Choose the server you want to store the request on. This is also the server you will need to use to complete the request after it’s been signed by the CA.
Now we need to configure the names that will be included in the certificate. The wizard has already started to populate the names it thinks you’ll want to use. You can fill in the names used by the services here, or you can wait and use the next step of the wizard.
I find this step a little easier to use to make sure the correct names are included in the certificate. Ensure that the name you planned for your namespace are included here.
We need to specify some additional information about our organization in the certificate.
Enter a UNC path to save the request to. I am saving the request to the desktop of the Exchange server EX16-1.
Now if we select the newly created request, we can see its status is “Pending request”. This means we are waiting for the request to be signed by a CA. We can now submit the created .req file to a CA to be signed. I will be using my internal CA since this is just a lab environment, but a public CA will work the same. Once the request has been signed, we need to complete the request. Select the pending request and choose to complete the request in the right pane. This will open the complete pending request wizard. Enter the UNC path name to the .cer file that was provided by the CA to complete the certificate.
Now we can see that the certificate is listed as valid. However, it hasn’t been assigned to any services.
To assign services to the new certificate, we need to edit the certificate and select services. In this case we will only be using SMTP and IIS. SMTP is used for TLS encryption of mail flow and IIS is used for all client connectivity (OWA, ActiveSync, Outlook Anywhere).
The final step is to export the certificate and then import the certificate to any additional Exchange servers in your environment. After you import the certificate you will need to specify the services to be assigned to the certificate on each additional server. To verify that the new certificate is being used, browse to the EAC or OWA url and ensure the certificate now shows valid.