When adding a TLS certificate on an Exchange server, the inevitable prompt will appear to enquire if you wish to overwrite the default SMTP certificate binding. While the UI in the current versions of Exchange is slightly different, it was basically the same prompt in Exchange 2010 & Exchange 2007.
While the prompt language was the same in Exchange 2007 and newer versions, the way that transport deals with TLS certificates did change significantly in Exchange 2010. Exchange 2007 allowed only a single certificate to be bound to SMTP, and thus that certificate needed to have all of the required names. In Exchange 2010, the transport service became more intelligent and was able to determine which TLS certificate should be used based on the connection.
This process is documented for Exchange 2010 here.
The below flowchart illustrates the logic:
When an SMTP session is established, the receiving server initiates a certificate selection process to determine which certificate to use in the TLS negotiation. The sending server also performs a certificate selection process. For more information about that process, see Selection of Outbound Anonymous TLS Certificates. From this link, step 5 outlines some of the pertinent aspects of the certificate selection:
The certificate selection process searches for all certificates in the certificate store that have a matching FQDN. From this list, the certificate selection process identifies a list of eligible certificates. Eligible certificates must meet the following criteria:
- The certificate is an X.509 version 3 or a later version certificate.
- The certificate has an associated private key.
- The Subject or Subject Alternate Name fields contain the FQDN that was retrieved in step 3.
- The certificate is enabled for SSL/TLS use. Specifically, the SMTP service has been enabled for this certificate by using the Enable-ExchangeCertificate cmdlet.
In a nutshell, the fundamental difference with Exchange 2010 onwards is that multiple TLS certificates can be bound to SMTP
To Overwrite, Or Not Overwrite...
While the documentation says that there is typically no need to overwrite the default SMTP certification, I have noted that most customers actually do this as they click the default option which is to overwrite.
In most cases this does not cause issues as they are not using Edge servers for example. They also typically leave the additional SMTP binding so that transport can use both certificates.
My default preference is NOT to overwrite the default SMTP certificate.
Please note that CAS is separate from transport. The IIS binding will be changed from the default CAS configuration, as we do NOT want users to get certificate errors in Outlook.
Walkthrough of Prompts to Overwrite Default SMTP Certificate
The below screenshots illustrate the UI shown when updating TLS certificate on Exchange.
We then chose to bind the certificate to IIS and SMTP services by selecting their respective boxes.
Note that it is at this point we get the warning, and question if we want to overwrite the default SMTP certificate. There is no prompt for if were to choose only IIS as that follows the Highlander principle. *
As an additional note, please note that we use a designated TLS certificate to encrypt cross-premises messages from Exchange to Exchange Online Protection.
If you have updated the on-premises SMTP certificate, please review your hybrid configuration as it is likely you will need to re-run the Hybrid Configuration Wizard (HCW).
As a reminder, the below is what you will see when running the HCW and are prompted to choose the TLS certificate.
* There can be only one!