Exchange Server 2016 communicates with clients, applications and other servers over a variety of network protocols such as HTTPS, SMTP, IMAP and POP. Much of this communication, particularly clients and applications, involves username and password-based authentication. When user credentials are sent over the network they are sent “in the clear”, meaning they can potentially be intercepted and read by an attacker. Other information transmitted during the session may also be sensitive and prone to abuse if interception was possible.

To secure these communications Exchange Server 2016 uses SSL certificates to encrypt the network traffic between the server, clients and applications. This includes:

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

When Exchange Server 2016 is first installed it generates a self-signed SSL certificate that is then enabled for IIS (HTTPS services like OWA, EWS and ActiveSync), SMTP, POP and IMAP. The self-signed certificate allows the server to be “secure by default” and begin encrypting network communications right from the start, but it is only intended to be used temporarily while you provision the correct SSL certificates for your environment.

When deploying Exchange Server 2016 you should plan to replace the self-signed certificate with a valid SSL certificate for your deployment scenario. This involves an investment of anywhere from $99 to several thousand dollars depending on your Client Access namespace scenario, the type of certificate you purchase, and which certificate authority you purchase it from.

If you’re tempted to stick with the self-signed certificate, or to try and disable SSL requirements on Exchange services, I strongly recommend you do not do those things.

  • Deliberately trying to reduce the security of your Exchange environment is unwise
  • The hours you’ll spend configuring and troubleshooting your attempted workarounds is more costly than just buying the correct SSL certificate
  • Some stuff just flat out won’t work if you try to work around SSL requirements

Exchange Server 2016 SSL Certificate Requirements

There are three basic requirements for an SSL certificate in an Exchange Server 2016 deployment.

  • Correct server/domain names – the SSL certificate must contain the namespaces (aka, URLs, aliases, domain names) to match the names that clients will be connecting to (for example, users typing “mail.exchange2016demo.com” in their web browser to access Outlook on the web)
  • Certificate validity period – each SSL certificate has a fixed period of time during which it can be considered valid. When the SSL certificate reaches its expiry date it will need to be renewed to continue working.
  • Trusted certificate authority – clients will only trust SSL certificates that have been issued by a certificate authority that they already trust. This is one reason that the self-signed certificate is not suitable for general production use, because your clients will not trust certificates issued by the Exchange server itself. There are a wide range of certificate authorities available to purchase certificates from that your client operating systems and devices will trust. I generally recommend using Digicert.

Choosing a certificate authority is simple enough, and the validity period will be determined by how long you purchase the certificate for (usually a minimum of 12 months, but the longer the validity period the less the certificate tends to cost per year). That leaves the server/domain names (or namespaces) as the main decision point when planning your SSL certificates.

Namespaces for Exchange Server 2016 SSL Certificates

The simplest approach to namespaces for Exchange Server 2016 is to use a single namespace for all HTTPS services. An example of this approach can be seen at the following article:

In addition to the HTTPS namespace it is also common to use a separate namespace for each of the SMTP, POP and IMAP services, although it is certainly not required to do so. There is also the Autodiscover CNAME to consider, and the root domain as well.

In a simple environment where the domain name used for email addresses is exchange2016demo.com, and taking all of the above into consideration, the namespaces could be planned as:

  • mail.exchange2016demo.com (for all HTTPS, SMTP, POP and IMAP)
  • autodiscover.exchange2016demo.com (for the Autodiscover CNAME)
  • exchange2016demo.com (for root domain Autodiscover lookups)

The recommended practice is to only include aliases as namespaces on SSL certificates, and not any server fully-qualified domain names (real server names). Due to recent changes to certificate issuance rules you may also find it impossible to request an SSL certificate for a domain name that is not internet-routable or that you do not legitimately own (e.g., domain.local). If you’re unsure about how exactly this will work please read my article on avoiding server names in SSL certificates.

Which Type of Certificate to Purchase?

Certificate authorities such as Digicert can sell you a variety of certificate types, and some certificate authorities have different names for what is basically the same thing.

A standard SSL certificate contains a single name and is generally the cheapest to purchase, however these are not suitable for even the simplest of namespace designs.

A wildcard SSL certificate allows you to secure multiple names on a domain without having to specify the exact names on the certificate itself. For example, a Digicert wildcard certificate can be acquired for exchange2016demo.com and *.exchange2016demo.com. While these are often a lower cost option, wildcard certificates can have compatibility issues with some integration scenarios with other systems, as well as not being suitable for secure POP and IMAP configurations.

A SAN or UC (Unified Communications) certificate is the recommended type of SSL certificate to purchase. A SAN certificate can contain multiple names. For example, a Digicert UC certificate can include up to four names at the normal price, with additional names up to 25 total being available at an additional cost. While the cost of a SAN/UC certificate will be more than a wildcard certificate you are less likely to run into any compatibility issues with the SAN/UC certificate, as long as the certificate contains the correct names. If you make an error with your namespace planning or need to add a name later Digicert and some other providers will allow you to re-issue the certificate at no cost, while other providers will charge a re-issuing fee.

How Many SSL Certificates Should You Purchase?

After planning your namespaces and choosing a certificate authority you may be considering how many SSL certificates to purchase, especially if you have more than one Exchange 2016 server.

The recommend practice is to provision as few SSL certificates as possible, because it is simpler to administer as well as less costly to purchase. So while it is possible to have separate certificates for each of the HTTPS, SMTP, POP and IMAP services, it is recommended to use one certificate for all of them unless you have a specific scenario that requires different certificates.

Note that while only one SSL certificate can be enabled for HTTPS on a server, multiple SSL certificates can be enabled for SMTP. However in most simple deployments only a single certificate will be required for SMTP.

Similarly it is recommended to use the same SSL certificate for all of the Exchange servers that will be configured with the same namespaces. For example, if you have two Exchange 2016 servers in a site that will be load-balanced, and both have the “mail.exchange2016demo.com” namespace configured for HTTPS services, they should have the same certificate installed. You achieve this by provisioning the certificate on the first server, and then exporting it and importing it to as many additional servers as needed.

Next Steps

After planning your Exchange Server 2016 SSL certificates the next steps are:

  1. Generate a certificate signing request (CSR) for Exchange Server 2016
  2. Submit the CSR to your chosen certificate authority
  3. Complete the pending certificate request on the Exchange server
  4. Export/import the SSL certificate to any additional servers (for multi-server scenarios)
  5. Enable the SSL certificate for services in Exchange Server 2016

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. Sourabh

    Hello Guy’s, I need ur help. I have tried to connect mail2016 server using EWS in java. but facing the “The remote server returned an error: (440)Login Timeout” issue. On the browser, I can connect using the same credentials.
    THe code snippets are below,

    ExchangeService service = new ExchangeService();
    ExchangeCredentials credentials = new WebCredentials(username, password);
    service.setCredentials(credentials);

    service.setUrl(new URI(exchangeUrl));

    //service.autodiscoverUrl(emailId, new RedirectionUrlCallback());

    // Bind to the Inbox.
    Folder inbox = Folder.bind(service, WellKnownFolderName.Inbox);

    Here If I tried to access the folder it gave me a 440 login timeout issue.
    Is this related to the SSL certificate or anything else??

  2. Колян

    Нужны установка wildcard ssl сертификата в exchange 2016

  3. Chrasis

    I am upgrading to exchange 2016 from 2013. Our current exchange 2013 server is named houexch2k13.( mydomain.com) it hosts about 100 email accounts distributed to Outlook 2016, owa and with Iphone & Ipad Exchange. it currently has a wildcard certificate to easily handle the internal and external connections to houexch2k13.(mydomain.com), mail.(mydomain.com) and autodiscover.(mydomain.com).

    As I move on to Exchange 2016, do I really need a wildcard certificate? During the Exchange 2016 new Exchange Certificate wizard, Create a request for a certificate from a certificate authority, where I DO NOT choose a wildcard certificate for the *Root Domain, , I am allowed to choose the specific domains for the ACCESS Services (Exchange ActiveSync, Pop, IMAP, OWA, OAB, etc.), then on to DOMAINS: .mydomain.com, houexch2k19.mydomain.com & autodiscover.mydomain.com, are all listed. At this point, can I just add webmail.mydomain.com or mail.mydomain.com for those external device request so that I don’t keep getting unmatched certificate requesting mail.mydomain.com? or do I need to have a wildcard cert?

    I think maybe when I was creating the first request, I accidentally left out the mail.(mydomain.com). is there a way to go and see what I requested and see if it was me or the cert authority left it out?

    and there’s no way to add mail.(mydomain.com) to the cert..

  4. Md Kamrul Hasan Sagor

    Hello ,

    I am configure Digicert SSL Multi domain Public SSL in exchnage server 2016 & it’s success fully install but when send a email to outside domain like gmail & others showing did not encrypt this message in massage . Note that previously install on the server exchange self sign & rapidssl public SSL . anyone can me help about tls encrypt massage during email communication.

    Thanks ,
    shagor

  5. Dave Chapman

    Hi Paul
    I have set up a Exchange 2016 test server using a LetEncrypt certificate.
    This has been enabled in Exchange for SMTP, IMAP, POP & IIS.

    Can I now safely remove the self signed certificated generated when I installed Exchange? Or is this a bad idea?

    Thanks in Advance Dave

  6. @ngolano

    Hi

    Which SSL certificate is suitable for exchange 2016? Can I use Standard SSL?

    Regards

  7. Binh

    I’m interested in this part:
    “So while it is possible to have separate certificates for each of the HTTPS, SMTP, POP and IMAP services, it is recommended to use one certificate for all of them unless you have a specific scenario that requires different certificates.”
    So I have some questions:
    1. This thing is only for Exchange 2016 or can use on 2010/2013?
    2. When I install EV SSL on my IIS (included mail.domain.com, autodiscover.domain..com and owa.domain.com), and OV SSL for other services such as IMAP, POP, are there any issue?

  8. N92

    Hi Folks,

    We have server 2013 & 2016. In both, we have implemented SSL certificate. Still, logs say the password is going to clear text. So I have read somewhere it may be implemented partially not fully.

    So, I want to know how it can be implemented partially not for the full site?

  9. Robinho

    Hello dear all,

    Couldo you please help me? i have an exchange server 2013, with a valid certificate, but is about to expire. I need to renew my Wildcard certificate, can someone please help me hpw to renew a wilcard certificate in exchange 2013.

    Regards
    RN

  10. Robinho

    Hello dear all,

    Couldo you please help me? i have an exchange server 2013, with a valid certificate, but is about to expire. I need to renew my Wildcard certificate, can someone please help me hpw to renew a wilcard certificate in exchange 2013.

    Regards
    RN

  11. Moana

    Hi Paul,

    I am looking for a certificate for a site that has only one Exchange server. We’re looking to have it for external mail use and mail on IOS and Android. Which certificate would you recommend better.

    Regards

    Moana

  12. A

    If I have an all internal exchange setup for lab, can I install the Active Directory Certificate Services instead of using Digicert? Will everything work (internally of course) if I choose this approach?

      1. A

        Ah nice. Thanks for a fast reply!

        Regarding the certificate, in your example above, what CN’s do you put in the certificate? Just mail.exchange2016demo.com or do you include something more?

  13. Rodel

    Hi Paul!

    Our company has on-premised Exchange 2016 with FQDN/Namespace for mail.domain.com and we have around 7 accepted domains configured as authoritative.

    What is your recommended type of SSL for our exchange? As we prefer for Symantec SSL, can we go for Symantec Secure Site with EV only or Pro or Pro EV?

    Do 7 authoritative accepted domains needs separate SSL or this will be also secured by 1 single SSL cert for our mail.domain.com?

    Highly appreciate your input. Thanks so much!

    Regards!

    1. Avatar photo

      You can have one SSL certificate bound to IIS for handling HTTPS client traffic, so it must be valid for all of the HTTPS namespaces configured on your server. So it depends whether you’re using all those domains for HTTPS (e.g. autodiscover) or just the one mail domain for HTTPS.

      You can have multiple SSL certificates bound to SMTP for TLS encrypted SMTP connections, if you need multiple namespaces to work for SMTP services.

  14. Colm

    My company currently has a 2010 exchange server. I recently installed a 2016 exchange server. I tried to install the SSL certificate as per your instruction. Under ECP-Servers there is no “certificates” option?? Am I looking in the wrong place?

  15. VC

    I could not locate Microsoft’s requirements for secure SMTP and POP service associations to be not supporting wild card certs.

    Could you please explain a bit more or break down on why the wild card certs are not a good choice for secure SMTP and POP service associations ?

  16. Hans

    Hi Paul

    I am currently planning to migrate from 2010 to 2016. Will my 3rd party cert exported from 2010 work if i Import it onto my 2016 servers?

    Thank you

    regards

  17. Umer

    Thank YOu ! Really informative material for sysAdmins 🙂

  18. Fredric

    Hi Paul

    Can you add to this article that MS does not support SHA1 certificates in Exchange 2016? Ran into this today. Reused a wildcard cert from an Exchange 2010 and it came up as invalid in Exchange 2016.

    Regards
    Fredric

  19. Turbomcp

    Hi Paul
    First thanks
    Second I think 2016 migration from 2010 or,2013 doesn’t require separate url’s on cert
    Thanks

  20. Guy

    With the comment:
    “A standard SSL certificate contains a single name and is generally the cheapest to purchase, however these are not suitable for even the simplest of namespace designs.”

    Why are they not suitable? We successfully deploy Exchange servers with a single mail.domain.com certificate servers using a SVR record for autodiscover.

    The only client that has any difference in response to this is Outlook, which will prompt to confirm the redirection of autodiscover.domain.com to mail.domain.com, to which you select ‘Allow’ and tick the ‘Always Allow’ box and you never see it again. Android and iPhone just accept the redirection automatically (its transparent).

    Granted in larger organisations with lots of clients this may make setting up clients more trouble than the cost of SAN or wildcard SSL, however in small business its a no brainer (SAN/Wildcards are expensive). There may however be a group policy that can be created to accept the redirection automatically (not sure though on that one, we have never needed it).

    Cheers

    Guy

    1. Avatar photo

      Because for maximum compatibility across clients, devices, mobile apps, external testing tools, load balancers, etc etc etc, I recommend SAN certificates. I’m not going to recommend “Use a single named cert” when it comes with a list of known caveats and unknown potential problems in the wide variety of environments that people reading this blog post might have.

  21. Gordon Howes

    Very good article. In essence this is the same as 2010/2013 so the process is the same for 2016. If it isn’t broken then it doesn’t need fixing.

Leave a Reply