Event ID 36870 and 36874: IIS drops HTTPS clients during the TLS handshake

Fix it now

The connection is dying during the TLS handshake, below IIS, which is why there is nothing useful in the site log. Microsoft publishes Event ID 36870 as a fatal error accessing the TLS server credential private key, and attributes it to the keys in the MachineKeys folder not being readable. Start there.

certutil -store my
icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
Get-TlsCipherSuite | Format-Table Name

1. Open certlm.msc, expand Personal then Certificates, find the certificate bound to the site, and confirm it reports a corresponding private key.
2. If the key association is broken, repair it: certutil -repairstore my <thumbprint>.
3. Check the permissions on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. Microsoft’s documented remediation for 36870 grants Full control to NT AUTHORITY\System and BUILTIN\Administrators and Read to NT AUTHORITY\NETWORK SERVICE on that folder and its contents.
4. For a per-certificate fix instead, right-click the certificate, All Tasks, Manage Private Keys, and grant Read to the account the site or service runs as.
5. If the handshake fails without any key problem, compare the cipher suites the two ends offer. Get-TlsCipherSuite lists what this server will accept.

Take a copy of the current permissions before you change them. Microsoft’s own script writes the before and after state of the MachineKeys ACL to a file for exactly this reason.

If HTTPS is working again, stop here. If it is not, the next section separates a key problem from a negotiation problem, which have nothing in common but the symptom.

Why it happens

TLS termination happens below IIS. The kernel accepts the connection and Schannel negotiates the session using the certificate bound to that address, port and host name. Only once that succeeds does an HTTP request exist for IIS to route. That is why a handshake failure produces no useful entry in the IIS log at all: from the web server’s point of view, nothing ever arrived.

Event ID 36870 is the one Microsoft actually publishes, and it is worth reading carefully. The message is that a fatal error occurred when attempting to access the TLS server credential private key, with an error code from the cryptographic module. The documented cause is that the local RSA keys in the MachineKeys folder cannot be accessed, either because the permissions on that folder or on the individual key files are wrong, or because the key is corrupted or missing. Note where the fault is: not the certificate, the key.

Two other Schannel event IDs are quoted constantly for this, 36874 and 36886, and Microsoft does not publish a meaning for either. This article will not invent one. What is documented is the behaviour behind the symptom people attach to 36874: the client advertises its cipher suites in the Client Hello and the server returns its choice in the Server Hello, and if there are no matching suites the server closes the connection instead of sending a Server Hello at all. That is what a negotiation failure looks like on the wire, and it is diagnosable without knowing what any event ID is called.

The next fix edits the SCHANNEL keys under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders. Export the branch first and change one thing at a time. A protocol misconfiguration here can lock you out of remote management on the same server, so have console access before you start.

Full reference

Which of these Microsoft actually publishes

That table is the reason this article is shaped the way it is. Most treatments of this problem confidently assign meanings to 36874 and 36886, and those meanings may well be right, but they are not published, so they should not be the thing you plan a change window around. Diagnose from the certificate, the key, and the cipher suites, all three of which you can read directly.

The MachineKeys folder

Machine-scoped private keys live as files under C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, and each one carries its own access control list. Import a certificate through a wizard, renew it through a different tool, or restore it from a backup, and the key can end up readable only by administrators. The service then finds the certificate, fails to open the key, and drops the connection. Microsoft’s documented remediation is:

Capture the current state with icacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys /t /c to a file before you change anything, and again afterwards. Microsoft’s own published script does both, which tells you how often this needs undoing.

Certificate store commands worth knowing

certutil -repairstore takes a store name and a certificate match token, and a SHA-1 thumbprint is one of the documented forms of that token, which is why the usual invocation works. netsh http show sslcert is the other command people reach for here, to read the certificate hash bound to an address and port; it is standard but this article could not confirm it against a Microsoft page, so treat its output as a cross-check rather than as the authority.

Protocol and cipher configuration, and where it is read from

• Cipher suite changes through Enable-TlsCipherSuite and Disable-TlsCipherSuite take effect without a restart. Microsoft states that explicitly.
• Protocol version changes under the SCHANNEL Protocols registry branch are read when Schannel starts, so they do need a reboot.
• Group Policy wins. The SSL cipher suite order policy overrides local configuration, so a change that keeps reverting is a policy, not a bug.
• If a hardening tool or script made the original change, re-run it with a documented profile rather than unpicking individual values by hand. You will otherwise be doing this again after the next run.

When the certificate and the ciphers are both fine

• Confirm the binding actually points at the certificate you think it does, and that the host name in the binding matches what clients are asking for.
• Check the certificate chain from the client’s point of view, not the server’s. A server that trusts its own issuer tells you nothing about what a client sees.
• Check the clock on both ends before blaming the certificate dates.
• Remember that a wildcard or multi-domain certificate does not change any of this mechanically. What it changes is the blast radius: one unreadable key takes down every host name the certificate covers.

Every code this article covers

Confirm the fix worked

1. Connect to the site over HTTPS from a client that was previously failing and confirm the handshake completes.
2. Check the System log for new Schannel entries after that test.
3. Run certutil -store my and confirm the certificate you expect is present with its private key.
4. Run Get-TlsCipherSuite and confirm the suites your required clients need are listed.
5. Restart the server and re-test, so you know the fix survives a reboot rather than living in a running process.

Questions people ask about this