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:

  1. 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.
  2. Modify the services assigned to the new certificate to bind SMTP and IIS to the new certificate.
  3. Remove the original certificate from the server.
  4. 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:      <Exchange Server FQDN>
Description:
Microsoft Exchange could not find a certificate that contains the domain name <I><Cert Issuer Details><S><Cert Subject Details> in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector <Receive Connector Name> with a FQDN parameter of <I><Cert Issuer Details><S><Cert Subject Details>. 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 “<Receive Connector Name>” | fl

The property we’re interested in is TlsCertificateName.

To correct the error, the following steps were taken:

  1. 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.
  2. 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 = “<I>” + $certs[0].issuer + “<S>” + $certs[0].subject
  3. Modify the Receive Connector configuration to include the new certificate information assembled above, e.g.:
    Set-ReceiveConnector “<Receive Connector Name>” –TlsCertificateName $certinfo
  4. Restart the Microsoft Exchange Transport Service.
  5. Remove the old certificate from the server.

A quick test of incoming and outgoing mail indicated that everything was flowing as expected.

Changing the Certificate on ADFS 3.0 and Web Application Proxy (WAP)

As with all systems using certificates for security, there comes a time when the certificate is expiring and needs to be replaced. here’s the procedure for ADFS 3.0 and WAP:

Starting with the ADFS server:

  1. Log onto the ADFS server.
  2. Add the new certificate to the server. Make sure this is added to the personal certificate store for the computer account. I usually do this using the certificates snap-in in MMC.
  3. Find the thumbprint for the new certificate. This can be found by looking at the details for the certificate; the thumbprint is usually at/near the bottom of the list of details for the certificate and consists of 40 hexadecimal characters. Take a copy of the thumbprint and ensure that the spaces are removed, so it’s a 40 character string; you’ll need this in a few moments.
  4. Grant the service account that is running the ‘Active Directory Federation Services’ service read access to the private key. To do this, follow these steps:
    1. Within the certificates snap-in of MMC, right click the certificate, select ‘All Tasks’ and then select ‘Manage Private Keys…’:
      Manage private keys
    2. Click ‘Add…’ to add the user account running the ADFS service on the server and grant read access to that user. Click OK on the permissions dialog to close it.
  5. Launch AD FS Management, expand ‘Service’ within the left pane and click ‘Certificates’:
    AF FS Manager Certificates
  6. Click ‘Set Service Communications Certificate…’ from the actions panel at the right of the screen:
    Set Services Communication Cert
  7. A dialog is shown presenting the available certificates on the server. Select the new certificate that is to be used. If you are unsure of the correct certificate, select each certificate in turn and click the ‘Click here to view certificate properties’ link which is shown and compare the thumbprint with that recorded earlier. Click OK on the dialog once the correct certificate is selected.
  8. If at this point you restart the server or ADFS service and make a connection to ADFS, you will still be presented with the original certificate. The change in the GUI changes the configuration in the ADFS configuration database, but not the certificate bound to HTTP.sys.
  9. To complete the configuration change, the following PowerShell command must be run:
    Set-AdfsSslCertificate –Thumbprint 00112233445566778899aabbccddeeff00112233
    Where 00112233445566778899aabbccddeeff00112233 should be replaced with the thumbprint you found earlier.
  10. Restart the server, or the ADFS service on the server to complete the configuration change.

Additional configuration is required on the WAP server:

  1. Log onto the WAP server.
  2. Add the new certificate to the server. Make sure this is added to the personal certificate store for the computer account.
  3. Run the following PowerShell command to change the certificate:
    Set-WebApplicationProxySslCedrtificate –Thumbprint 0011223344556677889900aabbccddeeff00112233
    Where 00112233445566778899aabbccddeeff00112233 should be replaced with the thumbprint you found earlier.
  4. All of the publishing rules need to be updated with the thumbprint of the new certificate (you created these originally using PowerShell, right?). This can be done by either deleting the old rules and recreating them with the new certificate thumbprint specified, or the rules can be updated with the new thumbprint, for example:
    Get-WebApplicationProxyApplication –Name “WebAppPublishingRuleName” | Set-WebApplicationProxyApplication –ExternalCertificateThumbprint “00112233445566778899aabbccddeeff00112233”
    Where (you guessed it!) 00112233445566778899aabbccddeeff00112233 should be replaced with the thumbprint you found earlier and ‘WebAppPublishingRuleName’ should be replaced with the name of the rule as it is shown in the Remote Access Console.
    I expected the federation publishing rule that was created automatically when WAP was originally configured to be updated for me, but had to manually switch the certificate on that one.
  5. Restart the server, or the ADFS and Web Application Proxy services to complete the configuration.
  6. Test that all of the previously published rules function correctly and provide the new certificate to the computer from which you are making a connection. If you need to check the certificate assigned to a specific publishing rule, the following PowerShell will show all of the properties for the publishing rule:
    Get-WebApplicationProxyApplication –Name “WebAppPublishingRuleName” | fl
    Note that the other parameters shown in the list generated by the above can also be changed (with a few exceptions) using the Set-WebApplicationProxyApplication cmdlet.