When switching to transport encryption TLS 1.2, the Windows Error Reporting Service may stop working and dops some errorss in event log. Here are a few details about that topic.
Recently the transport encryption TLS 1.3 was officially approved by the IETF as RFC 8446. It occurred to me that blog reader Thomas B. pointed out an issue with TLS 1.2 to me at the end of July 2018. Thomas wrote
During hardening our systems (RDP, Exchange, SQL, Server 2008R2/2012R2) with TLS 1.2, I noticed the following.
After only TLS 1.2 is allowed, the Windows Error Reporting Service no longer works and triggers an Event Id 36871 channel error in the event log / system log. At least under Windows Server 2008 R2 SP1.
There has several articles on TLS 1.2 Hardening been published. Microsoft has published articles like TLS/SSL Settings or Exchange Server TLS guidance, part 1: Getting Ready for TLS 1.2, andTLS 1.2 support for Microsoft SQL Server (thanks to Thomas for the links). Thomas writes:
If you select Control Panel – Maintenance – Check for solutions and want to connect to the Windows Error Reporting Service, the error mentioned above occurs.
his problem has also been noticed by other administrators. On Microsoft Answers you can find this English forum thread, which also deals with the event ID 36871 with the TLS-Error 10013.
SChannel Error 36871:
"A fatal error occurred while creating a TLS client credential. The internal error state is 10013."
Within the forum thread the affected person writes that reactivating SSLv3.0 in IISCrypto fixed the SChannel error. Perhaps helpful as a hint to administrators in this area – thanks to Thomas for the tip.
Cookies helps to fund this blog: Cookie settings