• Home
  • About
  • Blog
  • Training
  • Books
  • Contact
    • Email
    • Facebook
    • Twitter
    • RSS

Practical 365

  • Office 365
  • Exchange 2019
  • Exchange 2016
  • Exchange 2013
  • Hybrid
  • Certificates
  • PowerShell
  • Migration
You are here: Home / Exchange Server / Assign an SSL Certificate to Exchange Server 2016 Services

Assign an SSL Certificate to Exchange Server 2016 Services

October 15, 2015 by Paul Cunningham 23 Comments

Share
Share
Tweet
+1
0 Shares

When an SSL certificate has been installed for Exchange Server 2016 you need to assign it to Exchange services before it will be used. This task can be performed in the Exchange Admin Center.

Navigate to servers, then certificates, and select the server that has the SSL certificate you wish to enable for Exchange services.

exchange-2016-assign-ssl-certificate-01

Select the SSL certificate and click the edit icon.

exchange-2016-assign-ssl-certificate-02

Select services, then tick the boxes for each service you wish to enable.

  • IIS is used for all HTTPS services (such as OWA, ActiveSync, Outlook Anywhere). Only one certificate can be assigned to IIS, so it's important that the certificate contains all of the correct names configured as URLs for your HTTPS services.
  • SMTP is used for TLS-encrypted mail flow. More than one certificate can be assigned to SMTP.
  • POP and IMAP are disabled by default in Exchange Server 2016, but if you are planning to enable them you should assign a certificate, whether that is the same certificate used for HTTPS or a different one.
  • UM is optional as well. If you are planning to use the UM features of Exchange Server 2016 enable a certificate for UM as well, again that can be the same certificate as used for HTTPS services or a different one.

exchange-2016-assign-ssl-certificate-03

Click Save when you've select the services you need to use the SSL certificate for. If you are assigning an SMTP certificate you may be prompted to overwrite the default SMTP certificate. SMTP can have multiple certificates assigned, and for a simple deployment where the single SSL certificate you acquired contains the SMTP namespace you plan to use on connectors it is generally fine to say Yes to this prompt.

exchange-2016-assign-ssl-certificate-04

After you've completed those steps the SSL certificate will be used by Exchange for those services you selected.

If you're interested in how Exchange handles selection of a certificate when multiple certificates are bound to the SMTP protocol, here are some articles that explain it:

  • Selection of Inbound Anonymous TLS certificates
  • Selection of Inbound STARTLS certificates
  • Selection of Outbound Anonymous TLS certificates
Paul Cunningham

Paul is a Microsoft MVP for Office Apps and Services and a Pluralsight author. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server.

Share
Share
Tweet
+1
0 Shares

Exchange Server Certificates, Exchange 2016, SSL

Comments

  1. Bob says

    November 28, 2015 at 11:11 pm

    I need to use IMAPS and SMTPS for some Thunderbird clients. I can connect using TB and can access a users mailbox no problem. The problem I have is that when I try to send email I get a certificate warning as SMTPS (port 587) is using the self signed certificate which is assigned to IIS and SMTP. My wildcard certificate is also assigned to IIS and SMTP but for some reason the self signed certificate is being used when the TB clients try to send email. I cant change the certificate services in the EAC as the services are greyed out for both self signed AND wildcard cert and using the powershell hasn’t helped so far.

    So how can I get port 587/SMTPS to use my trusted wildcard cert rather than the self signed one?

    Reply
    • Paul Cunningham says

      November 29, 2015 at 7:52 am

      Look at the section on external SMTP relay with authentication in this article:
      https://practical365.com/exchange-2016-smtp-relay-connector/

      Reply
      • Bob says

        November 29, 2015 at 9:03 am

        That did it, thank you so much. I battled all day with this.

        Your articles are amazing!

        Reply
  2. MP says

    December 13, 2015 at 6:24 am

    Thanks, you are a Star!

    Reply
  3. LCOUSTEIX says

    March 31, 2017 at 6:15 pm

    Hello Paul,
    In a deployement that have 2 CAS servers and 2 MBX servers,
    On CAS, we have added the IMAP onto the SSL cert we currently for https
    But do we need to add the same SAN cert on our MBX to declare on it IMAP /POP services?

    Thanks

    Reply
    • Paul Cunningham says

      April 1, 2017 at 12:44 pm

      No, I don’t think so. I only ever deploy multi-role servers though, so I’ve never had to work that out.

      Reply
      • saeed says

        August 17, 2017 at 9:19 pm

        IMAP is residing in CAS and MBX has othing to do woth Cx connectivity, i think this the reason why we dont need .

        Reply
  4. Steve says

    June 17, 2017 at 4:30 pm

    I’m getting the following error. Previously exported this Cert with exportable private key:

    The imported certificate file for server DC3-EXCH-A failed to access for the following reason: The account used is a computer account. Use your global user account or local user account to access this server.
    + CategoryInfo : InvalidOperation: (:) [Import-ExchangeCertificate], InvalidOperationException
    + FullyQualifiedErrorId : [Server=DC3-EXCH-A,RequestId=9b5e17e4-b5f3-49cb-9311-7ad7b61fbc18,TimeStamp=6/17/2017 6:
    25:54 AM] [FailureCategory=Cmdlet-InvalidOperationException] BB29AC45,Microsoft.Exchange.Management.SystemConfigur
    ationTasks.ImportExchangeCertificate
    + PSComputerName : dc3-exch-a.XXX.com

    Logged on as Domain / Organization Admin

    Reply
  5. Calvin says

    August 30, 2017 at 8:26 am

    Paul,
    Unable to assign services to SSL in Exchange 2016 Standard CU6. New install on server 2016. Purchased SSL from Godaddy. During the “complete pending” the SSL shows up in CA under personal certificates but in EAC it shows “pending request”. Unable to edit or anything. Have rekeyed two SSL. Can deleted SSL certificate mmc (tried this 10 or more times). Any suggestions would be greatly appreciated

    Reply
    • Paul Cunningham says

      August 30, 2017 at 10:24 am

      If it’s still a pending request then I would assume you haven’t completed the certificate request. What steps/doco have you been following to get this done?

      Reply
  6. Collin says

    November 2, 2017 at 11:54 pm

    I’m having an issue with a secondary mail server answering TLS with the self signed cert instead of the Digicert Multi-SSL cert I’ve installed on it. Obviously as a result the TLS connection fails. The Digicert is assigned SMTP and IIS services and I replaced the the thumbprint when prompted when I completed the new certificate request in the EAC.

    The Digicert SSL cert was created properly with a CSR from the new server and is listed as Valid. Not sure what I am doing wrong or how to force smtp to answer with the SSL cert. Any thoughts?

    Reply
    • Paul Cunningham says

      November 3, 2017 at 8:34 am

      What type of connection? HTTPS? SMTP?

      Reply
      • Paul Cunningham says

        November 5, 2017 at 8:00 am

        For SMTP, if you have a custom connector that you created and you want it to use a specific certificate, you need to set the TLS certificate name on that connector.

        https://practical365.com/exchange-server/configuring-the-tls-certificate-name-for-exchange-server-receive-connectors/

        Reply
        • Collin says

          November 9, 2017 at 2:22 am

          Thanks for the feedback Paul, very appreciated. I’m not using a custom connector, just the defaults. I am assuming I need to run that process for the defaults as well to apply that SSL cert name?

          Reply
          • Paul Cunningham says

            November 9, 2017 at 6:23 am

            I generally don’t mess with the default connectors.

            There’s an article on TechNet about how Exchange chooses a certificate to use for TLS but I can’t find it right now.

  7. Josh Gardner says

    November 15, 2017 at 3:50 am

    Paul,
    I am having an issue with newly completed cert requests automatically assigning IMAP and POP services to the certs. When looking at the EAC I see that the boxes are checked and greyed out. This is after a brand new request submission and completion in order to remove the self signed certs in place of a CA issued cert, no other steps have been done other than the completion of the request. I have not manually assigned services via EAC or EMS and yet it shows IP…. for each of my newly issued certs. I have tried using the Exchange cert request as well as the old school IIS cert request.

    I have noticed that certs that DO NOT include the server name in the cert subject (or SAN if there is one) are not automatically assigned those services and are just “service-less”. Do you know of any way to unlock (make the IMAP and POP options editable) these services so that I can disable them. I’ve tried setting services to NONE in EMS but that does nothing. Our environment is highly secure and we don’t want to have these services enabled. Please help. Thank you in advance.

    Reply
    • Paul Cunningham says

      November 15, 2017 at 8:48 am

      My question would be why are you provisioning certs with the server’s real name on them?

      Reply
  8. Josh Gardner says

    November 16, 2017 at 2:06 am

    We have a common SAN cert that is used for for client access and autodiscover (for instance mail.domain.org) . The certs that have the server name in are meant to be used for the backend communications.

    In depth scenario:
    We have regulations that say that any cert that is not issued by a particular CA issuer is considered a security finding. As such the 3 default certs that get created upon installation of Exchange 2016 (Microsoft Exchange, Microsoft Exchange Server Auth Certificate, and the WMSVC-SHA2) are in violation of this.

    part 1 of response sorry for length

    Reply
    • Paul Cunningham says

      November 16, 2017 at 6:20 am

      I’m not familiar with how to fully replace and remove the self-signed certs that are used for backend and internal stuff. I’m not surprised that removing them causes stuff to break. I suggest you open a support case with Microsoft for guidance on that.

      Reply
  9. Josh Gardner says

    November 16, 2017 at 2:06 am

    We have imported the common cert and made that default for IIS, and SMTP services. In our lab I also assigned this common cert to the IIS management (which means the WMSVC-SHA2 default cert has been replaced by the common cert), and I also set the AuthConfig to use the common cert to replace the default Microsoft Exchange Server Auth cert. At this point all services and what not should theoretically be using the shared cert mail.domain.org. Which means I can remove the default ones and no longer be in violation of the security finding. But when I did remove them (in the lab) I kept getting errors/warnings about receive connectors not being able to find a cert (subject was the fqdn of the server) with a particular thumbprint. The receive connectors (and maybe send connectors as well, I don’t remember off the top of my head) were hidden and not configurable. I assume that these are created specifically for server to server communications, and are not your standard get-receiveconnector results.

    part 2

    Reply
    • Josh Gardner says

      November 16, 2017 at 2:07 am

      This made me think, that I should just keep the common cert for client/front end stuff, and submit requests that are identical in common name as the default created certs (specifically Microsoft Exchange Server Auth Certificate, and the WMSVC-SHA2) and replace each of those, respectively, instead of using the common cert. But in order to finalize a cert request it is mandatory that the domain field be selected, and since the errors/warnings were looking for the fqdn of the server I just used those for the request.

      No wildcard certs are in place

      I hope my explanation isn’t too ridiculously confusing. Thanks!

      Final 3/3

      Reply
  10. Jeremy says

    November 22, 2017 at 10:07 pm

    Paul,

    I have followed this to the “T” and I still get reports of cert name mismatch from end users. We are using a wildcard certificate. Could this be the issue? All the internal Uri are pointing to “https://mail.ourdomain.com” nothing points to the server name itself. We still have both Exchange 2010 and Exchange 2016.

    Any thoughts would be appreciated.

    Thanks!

    Reply
    • Paul Cunningham says

      November 23, 2017 at 6:31 am

      What is the namespace that they’re trying to connect to when the mismatch error appears?

      Reply

Leave a Reply Cancel reply

Recent Articles

  • Retiring the Practical 365 Blog
  • Using SharePoint Online Document Libraries as a Document Management System
  • Office 365 Message Tracking Improvements
  • Managing Change in Office 365
  • Multi-factor Authentication by Default for Administrators in Azure AD and Office 365
Practical 365

Popular Articles

Deploying the Microsoft Teams Desktop ClientDeploying the Microsoft Teams Desktop Client
Microsoft Is Changing How They Publish Office 365 IP Addresses and Urls for Firewall and Proxy AccessMicrosoft Is Changing How They Publish Office 365 IP Addresses and Urls for Firewall and Proxy Access
Automating New User Account On-boarding Using SharePoint Online, Flow, and PowerAppsAutomating New User Account On-boarding Using SharePoint Online, Flow, and PowerApps
The Junkings will Continue Until Morale ImprovesThe Junkings will Continue Until Morale Improves
Securing Administrator Access with Privileged Identity Management for Azure Active DirectorySecuring Administrator Access with Privileged Identity Management for Azure Active Directory

Training Courses

  • Configuring and Managing Office 365 Security
  • Office 365 Admin Playbook
  • Exchange 2016 Exam 70-345
  • Managing Exchange Mailboxes and Distribution Groups in PowerShell
  • More Training Courses...

Recommended Resources

  • Office 365 Security Resources
  • Office 365 Books
  • Exchange Server Books
  • Exchange Server Migrations
  • Exchange Analyzer
  • Digicert SSL Certificates

About This Site

Practical 365 is a leading site for Office 365 and Exchange Server news, tips and tutorials, run by Paul Cunningham, Microsoft MVP, author, speaker, and consultant. Read more...
  • Email
  • Facebook
  • Twitter
  • RSS

Copyright © 2018 LockLAN Systems Pty Ltd · Disclosure · Privacy Policy
PO BOX 7002, Hemmant, Queensland 4174 · ABN: 25 121 101 255

We are an Authorized DigiCert™ SSL Partner.