Now that we understand more about certificates in Exchange 2010, it’s time to start using them. During the install of Exchange 2010, a self-signed certificate is generated so that Exchange can use the SSL/TLS versions of the various protocols. This self-signed certificate is suitable for all the protocols that will need a certificate. It has the Exchange server’s name listed in the CN=, it has the server’s public key, and the valid dates. It has everything it needs for a client to obtain the public key of the server, encrypt a session key, and securely send the session key back to the server for use during the session. There’s only one problem with the certificate.
The client won’t trust it. Self-signed certificates are not going to be trusted by default by any client, and are really only useful for a very limited set of applications where certificate validation is not necessary. Specifically, when one Hub Transport or Edge Transport Exchange server in an organization wishes to send a message to another using SMTPTLS, that self-signed certificate will work out just fine, since certificate validation is not required. The servers either share an organizational relationship or an edge subscription, so they only need to exchange a session key; they already trust one another.
For clients, we need to install a certificate that they will trust. If you are going to use Windows computers joined to your domain and are willing to manually install your Enterprise Certificate Authority’s root certificate on mobile devices and non-domain joined computers, you can use Active Directory Certificate Services to create your own CA and issue your own certificates. But be warned that manually installing certificates on non-domain joined machines is not scalable and many mobile devices do not give you a way in their current versions (as of this publication date) to do this anyway, so you will be severely limiting your choice of mobile devices. Far better to obtain a certificate from your commercial CA of choice, so that you have the ubiquity you desire and don’t have to worry about the client side of things. We assume you are using your commercial CA for purposes of this article. So here is how you obtain and install a certificate in Exchange 2010.
Generate the Certificate Signing Request (CSR)
We’re going to assume a few things in this process. First, you are going to run the Client Access and Hub Transport roles on this server. It will be Internet facing. You want to enable all protocols and services that will use a certificate and you do not want to use a wildcard certificate. We’ll talk about wildcard certificates in a future post. Finally, that you use a split DNS and have the same domain name internally and externally for client facing services. Log onto your Exchange server and launch the Exchange Management Console. Then follow these steps:
- Click on Server Configuration.
- Select the Exchange Server you wish to configure.
- In the Action Pane, click New Exchange Certificate.
- Enter a friendly name that will help you (the admin) quickly identify the purpose for this certificate.
- Make sure that the option to Enable wildcard certificate is not selected, and then click next.
- On the Exchange Configuration page, select the following options:
- Select Outlook Web App is on the Intranet, and enter the FQDN you are using for web mail.
- Select Outlook Web App is on the Internet, and enter the FQDN you are using for web mail. (This is somewhat redundant since we are using split DNS, but get in the habit of this should you ever decide to use one name internally and another externally.)
- Select Exchange Active Sync is enabled and enter the FQDN you want to use for EAS connections.
- Select Web Services, Outlook Anywhere, and Autodiscover and specify the FQDN you want to use. Then select Autodiscover is used on the Internet, select Long URL, and enter the FQDN you want to use for Autodiscover.
- Select Use mutual TLS to help secure Internet Mail and specify the FQDN of your server.
- Then click Next.
- Check the domains listed and make sure all that you need are present. If you are using more than one SMTP suffix and want to make sure Autodiscover works as seamlessly as possible, add the additional Autodiscover domains. Once you are satisfied with your certificate’s properties, click Next.
- Enter the relevant information in the Organization and Location page, based on your corporate standards and the information you used when you were vetted by your CA. Then click Next.
- Click New to generate the Certificate Signing Request.
Obtaining the Certificate
Each CA has their own process for submitting a certificate, so we cannot provide those specifics here. Follow your vendor’s instructions, making sure you are picking a server certificate. If you plan on using this certificate on multiple servers, make sure you obtain the proper number of licenses, based on your needs and your CA’s requirements. Once you have the certificate from your CA, you are ready to install it.
Installing the Certificate
Log back on to the Exchange server, launch the Exchange Management Console, and then follow these steps:
- Browse down to Server Configuration.
- In the Action Pane, click Import Exchange Certificate to launch the wizard.
- Browse to the certificate file your CA issued you and select it. Click Next.
- Select the server and then click next.
- Click Import to install the certificate.
- In the EMC while still on Server Configuration, click Assign Services to Certificate.
- Select your server and click Next.
- Confirm that each check the box next to each service you want to run on your server is selected.
- Click Assign.
Confirming the certificate
Open an Exchange Management Shell and run the command
get-exchangecertificate | fl [enter]
You will see a listing of all services and the assigned certificate. Make sure your certificate shows the services listed that you selected. You can see the Subject to be sure you have the correct certificate.
In our next post we will discuss the pros and cons of using wildcard certificates with Exchange 2010.