Exchange: Channel 36888 / 36871 error after renewing the BackEnd certificate

After the Renewal of the Exchange backend certificatethere may be frequent Schannel error messages in the event log if the POP3 service of the Exchange server is used. The following two error messages may appear after changing the certificate:

Source: Schannel

Event ID: 36871

Level: Error

Fatal error when creating the client credentials for TLS. The internal error status is 10013.

Another message may be error 36888, which appears to occur more frequently if the Exchange backend certificate has been replaced:

Source: Schannel

Event ID: 36888

Level: Error

A fatal warning has been generated and sent to the remote endpoint. This may result in the connection being terminated. The fatal
Warning has the following code defined for the TLS protocol: 10. The Windows-SChannel error status is: 1203

Error 36888 can usually be rectified by adjusting the configuration of the POP service. In the standard configuration, the value for "ExternalConnectionSettings" is empty, which can lead to the error described above, as Exchange may select the wrong certificate here:

However, the problem can be easily solved by specifying the corresponding host names for POP3 and binding them to a certificate:

After restarting the POP service, the error should have disappeared.

Alternatively, the logging of channel errors can also be completely deactivated by changing the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Name: EventLogging

Value: 0

The error with the EventID 36871 is usually harmless and means that no connection has been established on a TLS/SSL port. The error can be triggered with an HTTP request (unencrypted) against port 443, for example, by opening a browser on an Exchange server and attempting to call up the URL "http://localhost:443". After a short time, the error shown above is logged in the event log. As no connection is established here, error 36871 can be ignored.

The event 36888 which is logged for the POP service, however, should be noted, for example it can happen here that a client uses an unencrypted connection, although in principle a TLS connection would be possible. This would be the case with SMTP and POP, for example, if instead of SMTP/POP with TLS, unencrypted SMTP/POP is negotiated. It is therefore not advisable to completely deactivate the logging of channel errors.