Why do I need a certificate?
Certificates are critically important to Microsoft Exchange Server.
With Exchange 2010 and earlier certificates allow 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:42pm–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.
SuperTekBoy Guides
Check out our installation and configuration guides.

Exchange 2016: Generate a Certificate Request

Exchange 2016: Complete a Certificate Request

Exchange 2016: Assign Services to a Certificate

Exchange 2016: Import & Export SSL Certificates

Exchange 2016: Renew a Certificate

Exchange 2013: Designing a simple namespace

Exchange 2010: Designing a simple namespace

Using SRV records for multiple Autodiscover domains
Purchase from DigiCert
SuperTekBoy is an authorized DigiCert partner (these are affiliate links).



DigiCert’s Guides
Be sure to check out DigiCert’s documentation as well (these are affiliate links).

Exchange 2013 : Generate an SSL Request

Exchange 2013 : SSL Installation

Exchange 2010 : Generate an SSL Request

Exchange 2010 : SSL Installation

Exchange 2007 : Generate an SSL Request
