When do I need "Negotiate Client Certificate" to be set to Enabled?

Question

I optionally want to support Client Certificates. That's why I set Client certificates to Accept on IIS. This works on most machines. However, on some machines IIS returns a 500. This can either be "solved" by setting Client certificates to Ignore (which is not an option to me) or by setting Negotiate Client Certificate to Enabled (this can either be done with netsh http add ... or by changing DefaultFlags to 2 in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslBindingInfo\0.0.0.0:443\; can this also be changed in IIS Manager?). While (enabling) this setting sounds reasonable just from looking at the name I don't understand why it's needed on some machines but not on others...

Tyrontyrone

Answer 1

TL;DR

You can enable this all the time if you require client-certificate to access any resource on the server. The primary reason is that some clients do not allow TLS re-negotiation due to possible Man-in-the-Midddle (MITM) attacks.

You can disable this if your clients support TLS re-negotiation and the MITM risk is acceptable.

Description

IIS has two ways to negotiate TLS:

• Where the client sends the client certificate in the initial request. This is useful when all resources on the server require TLS client authentication.
• Where the client doesn't send the client in the initial request, but later after IIS performs a TLS re-negotiation. This is useful when only some resources require TLS client authentication.

The Negotiate Client Certificate setting determines which is used, the first if enabled, and the second if disabled. Here is more from Microsoft's blog:

• If this setting is enabled, the client certificate will be sent by the client browser when the initial secure connection with the web-server is negotiated.
• If it is disabled, an initial secure connection will be negotiated between the web-server and the browser based on the server certificate, and then the connection will be re-negotiated when the client sends the client certificate.

• https://blogs.msdn.microsoft.com/friis/2017/01/16/the-complete-list-of-changes-to-make-to-activate-client-certificate-mapping-on-iis-using-active-directory/

Client Support and Error

The issue is that some clients do not re-negotiate the TLS session. If the client does not do this, you may encounter the following error in the server log. Setting Negotiate Client Certificate to Enabled can fix this.

The following fatal alert was generated: 20. The internal error state is 960.

• https://blogs.iis.net/rickbarber/require-client-certificates-in-iis-7-5

TLS Re-Negotiation MITM Attack

A reason some clients do not re-negotiate the TLS connection is due to Man-In-The-Middle (MITM) attacks associated with TLS re-negotiation:

Since the discovery of the MITM attack arround SSL Renegotiation, the answer in alot of circles has been to hangup on renegotitation requests.

• Make IIS require SSL client certificate during initial handshake
• http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.156.4428&rep=rep1&type=pdf
• https://security.stackexchange.com/questions/63867/ssl-tls-renegotiation-handshakes-mitm-plaintext-data-injection-medium-or-low

The clients requiring Negotiate Client Certificate likely do this to prevent MITM attacks during TLS re-negotiation.

Summary

If you have no issue requiring client certificates for all IIS resources, enabling this feature may allow you to interoperate with more clients and enable you to further protect your traffic.

Disable this to support differential TLS client authentication support while understanding the MITM risks.

Schultz