Exchange 2013 Cert Change - Unable to Support the STARTTLS SMTP Verb
I saw a issue recently on an Exchange server after the certificate used to secure SMTP and IIS services was changed as the old certificate was about to expire. The original default certificate that is self-generated had been replaced with one from a certificate authority. This had been used for several years without issue. The Exchange server is configured in hybrid mode, with incoming e-mail routed through Microsoft’s Exchange Online Protection (EOP) and TLS is configured to be required. The actions taken were:
- Add the new certificate to the certificate store on the Exchange server. This made the new certificate available within the Exchange Admin Center on the server.
- Modify the services assigned to the new certificate to bind SMTP and IIS to the new certificate.
- Remove the original certificate from the server.
- Restart the Microsoft Exchange Transport Service on the server.
At this point, an error was thrown in the Application Event Log on the server and incoming mail from Exchange Online Protection stopped flowing. The error thrown was:
Log Name: Application Source: MSExchangeFrontEndTransport Date: 04/02/2016 12:17:20 Event ID: 12014 Task Category: TransportService Level: Error Keywords: Classic User: N/A Computer:
Description: Microsoft Exchange could not find a certificate that contains the domain name in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector with a FQDN parameter of . If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.
I ran the suggested command to ensure that the Exchange Transport Service had access to the certificate key, but this didn’t help. Restoring the soon-to-expire certificate to the certificate store on the server and restarting the Microsoft Exchange Transport Service fixed the error, however the certificate in question was going to expire soon, and the use of expired certificates for TLS to EOP is no longer allowed, so this didn’t really help much. While digging into the configuration for the receive connector specified in the error thrown, I noticed something interesting. Despite the new certificate being supplied by the same certificate authority as the old one, the issuer specified for the certificate had changed slightly. The subject information was still the same. Sure enough, the properties of the receive connector in question still showed the old certificate details even through Exchange had been configured with the new certificate for SMTP and IIS. The information on the receive connector can be found by issuing the following command:
Get-ReceiveConnector "
" | fl
The property we’re interested in is TlsCertificateName. To correct the error, the following steps were taken:
- Locate the issuer and subject information from the new certificate. This can be done by examining the certificate directly via the certificate store, or using PowerShell, e.g. $certs = Get-ExchangeCertificate Locate the certificate you want to use. The one we wanted was the first on the list.
- Assemble the new issuer and subject information in a suitable format for the Receive Connector configuration. Again this can be done by copying the required text from the certificate information, or using PowerShell, e.g.: $certinfo = “” + $certs[0].issuer + “
” + $certs[0].subject - Modify the Receive Connector configuration to include the new certificate information assembled above, e.g.: Set-ReceiveConnector “
” –TlsCertificateName $certinfo - Restart the Microsoft Exchange Transport Service.
- Remove the old certificate from the server.
A quick test of incoming and outgoing mail indicated that everything was flowing as expected.