Public SSL Certificate on Exchange 2016

Security has been major issues these days. And if we have to count this on emails…. Emails are most critical as well vulnerable service. Hence to minimize this vulnerability on Email services, one of the most important checklist is to use Public SSL Certificate. As on my previous blog, I have already shared how we can generate the certificate for the Exchange server. So, on this blog I am sharing my knowledge on best practice for the Public SSL certificate on Exchange 2016.

Consideration:

Let’s start with the Exchange network protocols that are required for the public Services. To secure these communications Exchange Server 2016 uses SSL certificates to encrypt the network traffic between the server, clients and applications. Which includes:

• Outlook connecting to Outlook Anywhere (RPC-over-HTTP) or MAPI-over-HTTP
• Web browsers connecting to Outlook on the web (OWA) using IIS Protocol
• Mobile devices connecting to ActiveSync to access mailboxes and calendars using HTTP/HTTPS protocol
• Applications connecting to Exchange Web Services (EWS) for free/busy and other lookups using HTTP/HTTPS Protocol
• Email clients connecting to secure POP or IMAP
• TLS encrypted SMTP between Exchange servers or other email servers

So, what we can see is the SMTP, IMAP, POP, IIS are the protocol that we required on the Internet to access to our mail server. Although these protocols can be address from our private certificate server on intranet but it will not be facilitating service on the internet. Hence to facilitate the secure connection over the internet we will be requiring the Public SSL.

Now, we go through the varieties of the public SSL. We can find two types.

1. SAN (Subject Alternative Name) based SSL Certificate. For e.g. mail.yourdomain.com
2. Wild Card Certificate. For e.g. *.yourdoamin.com

So, what is the different between SAN based SSL Certificate and Wild Card Certificate. They both are public certificate and can be used for the Exchange server. Even Wild Card Certificate are cheaper and can be used for ‘n’ subdomains. While for the SAN based SSL, these can be used for specific domains or subdomain.

If this is so why can’t we use Wild Card Certificate as it seems to be beneficial? This is because in case of exchange there are certain limitation with wildcard Certificate. If you are using the wildcard certificate on Exchange you cannot address the services like IMAP and POP with it. That means wildcard certificates are not compatible with Exchange server, hence it is not recommended. But if you guys are using the IIS or web browsing, you can recommend wildcard certificate.

The next Important thing we need to consider is about the certificate generation. During the CSR generation we need to be cautious on below things:

1. Name of the SAN: you need to consider the name of the SAN which you are generating should be same namespace as of you are going to get browse through the web. If you don’t have your SAN name matched with your browsing namespace, the certificate is will not work.
2. Validity of Certificate: you also need to consider the Validity of the certificate, as this is one of the major component. It shows ‘not before’ and ‘not after’
3. Encryption Type: you also need to consider the Encryption type of the certificate, for detail this link can help you
4. Trusted Certificate Authority: you also need to check, whether the SSL certificate provider for your organization is the Trusted and renowned or not?? Normally we use of GeoTrust, DigiCert, Symantec.

Now to get the SAN for the Public communication with Exchange server, we need to get consideration for the below namespaces:

• Mydomain.com (for root domain)
• Mail.mydomain.com (for all HTTPS, SMTP, POP and IMAP protocols)
• Autodiscover.mydomain.com (for the autodiscover)

I hope this blog might have given you the insight for the Exchange Certificate on how we can generated the required SAN for any Exchange server environment.