Why do I need a certificate?
Certificates are critically important to Microsoft Exchange Server.
Starting with Exchange 2010 and earlier, certificates allowed for a secure connection to Outlook Web App, ActiveSync, or, Outlook Anywhere. Internally Outlook maintained a direct RPC connection to Exchange and didn’t utilize a certificate. This changed with Exchange 2013. Beginning in 2013, all client requests were established as RPC over HTTP versus direct RPC. This meant Outlook Anywhere now managed Outlook connectivity both internally as well as externally. With Exchange 2013, SP1 MAPI over HTTP was introduced as an alternative to RPC over HTTP–although disabled by default. With Exchange 2016, MAPI over HTTP is now listed as the preferred client connectivity protocol. It is also enabled by default in a greenfield installation.
Regardless of the connection protocol, your environment uses the lack of a properly configured certificate will cause you major problems. It is imperative to correctly request and configure an SSL certificate. Otherwise, clients won’t be able to establish the necessary encrypted connections. This will lead to all sorts of problems.
How do I get a certificate?
For Exchange, it is important to get a certificate through a trusted authority. Trying to use a self-signed certificate will cost you more money and time in the long run. There are plenty of trusted authorities out there, but I personally recommend DigiCert (affiliate). Not only do they have fantastic technical support, but they also have some really neat tools. Best of all, their turnaround time is incredibly fast (even on a Sunday at 7:42 pm–yep, personal experience right there.).
The specific steps for each trusted authority are different, but the principles remain the same. You provide a certificate signing request (CSR). The trusted authority validates your identity. You will then be issued a certificate.
For Exchange, I recommend a Unified Communications (UC) certificate. This is also referred to as a Subject Alternative Name (SAN). It is possible to use a wildcard certificate–although this can be considered less secure because no one server owns the private key. It is also possible to use a standard certificate for Exchange, but it requires your external DNS provider support SRV records.
The validation process can vary between providers as well. Some providers will perform a simple domain validation where they send an email to the recipients listed on your domain registration. Others will perform more extensive checks, including the validation of your business against various agencies. Once your identity has been validated, your certificate will be approved. It can then be installed and configured on your Exchange servers and any load balancers.
For specific steps on how to do this, be sure to check our articles to the right.
Exchange 2016 and 2019
These guides are for Exchange 2016 CU23 and greater and Exchange 2019 CU12 and greater
Generate a Certificate Request for Exchange 2016 and Exchange 2019
Complete a Certificate Request for 2016 and Exchange 2019
Assign Services to a Certificate for Exchange 2016 and Exchange 2019
Import & Export SSL Certificates in Exchange 2016 and Exchange 2019
Renew a Certificate in Exchange 2016 & 2019
Exchange 2013
These guides are for Exchange 2013 (and can also be used with Exchange 2016 CU22 and earlier and Exchange 2019 CU11 and earlier)
Generate a Certificate Request for Exchange 2013
(and older versions of 2016 & 2019)
Complete a Certificate Request for Exchange 2013
(and older versions of 2016 & 2019)
Assign Services to a Certificate for Exchange 2013
(and older versions of 2016 & 2019)
Import & Export SSL Certificates for Exchange 2013
(and older versions of 2016 & 2019)
Renew a Certificate in Exchange 2013
(and older versions of 2016 & 2019)
Exchange 2013: Designing a simple namespace
Exchange 2010
These guides are for Exchange 2010.
Exchange 2010: Designing a simple namespace
