Understanding and Using Certificates in Exchange 2010 – Part Five

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:


  1. Click on Server Configuration.
  2. Select the Exchange Server you wish to configure.
  3. In the Action Pane, click New Exchange Certificate.
  4. Enter a friendly name that will help you (the admin) quickly identify the purpose for this certificate.
  5. Make sure that the option to Enable wildcard certificate is not selected, and then click next.
  6. On the Exchange Configuration page, select the following options:
    1. Select Outlook Web App is on the Intranet, and enter the FQDN you are using for web mail.
    2. 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.)
    3. Select Exchange Active Sync is enabled and enter the FQDN you want to use for EAS connections.
    4. 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.
    5. Select Use mutual TLS to help secure Internet Mail and specify the FQDN of your server.
    6. Then click Next.
  7. 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.
  8. 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.
  9. 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:


  1. Browse down to Server Configuration.
  2. In the Action Pane, click Import Exchange Certificate to launch the wizard.
  3. Browse to the certificate file your CA issued you and select it. Click Next.
  4. Select the server and then click next.
  5. Click Import to install the certificate.
  6. In the EMC while still on Server Configuration, click Assign Services to Certificate.
  7. Select your server and click Next.
  8. Confirm that each check the box next to each service you want to run on your server is selected.
  9. 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.



Written by Casper Manes

I currently work as a Senior Messaging Consultant for one of the premier consulting firms in the world, I cut my teeth on Exchange 5.0, and have worked with every version of Microsoft’s awesome email package since then, as well as MHS, Sendmail, and MailEnable systems. I've written dozens of articles on behalf of my past employers, their partners, and others, and I finally decided to embrace blogging and social media, so please follow me on Twitter @caspermanes if you enjoy my posts.


  1. Craig Doleczewski · May 3, 2012

    You mention that as of publication date, “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.”

    Are you implying that there is news or projected attempts to do this in the near future? That would be a pretty interesting piece of information, and I’d be curious to see how or if companies are attempting to do that.

  2. Grazel Caminero · May 5, 2012

    I have the same concerns with Craig. In additions to his questions, my issue is: what do you mean by “non-scalable”. Does this mean that it can only be done on a few machines? If that’s what you mean, how many, if I may ask?

    Not that it’s a specific concern that we might be facing. But, I’m just curious.

    Good article, though. It’s descriptive and helpful. I don’t think there is any way that the article can be improved, even though an administrator might have additional questions upon implementation, which should be directed either to a consultant or a helpdesk, if there is such.

  3. Casper Manes · May 7, 2012

    Sorry guys, I don’t have any inside information, or a Doctor feeding me intel. It’s just that new updates come out all the time, and I hope that Microsoft will give us a way to install our own certs into future versions of their phones. Grazel, as to how many…how many do you feel like doing by hand, versus trying to create a script to do, versus just buying a cert from a public CA? That’s the real number. I wouldn’t buy a Verisign cert for testing, but I would before I would manually install certs into more than a handful of machines I have admin rights to and immediate access to. Our time is worth something, yes?

Leave A Reply