A couple of weeks ago I have been troubleshooting some SSL related issues on an Internet Facing Management Point on a Windows Server 2012 R2 server, this blog is as a note/reminder for myself ;). The Internet connected client was refused to connect with the certificate with errors like 403.13 and 403.16 in the IIS log files. The IIS error 403.13 stands for Client Certificate Revoked, but since the CRL of the subordinate Certificate Authority was reachable and the certificate was just enrolled it shouldn’t be reported as revoked.
Error 403.16 refers to issues that the client certificate is untrusted or invalid which is related to the fact IIS cannot process a complete certificate chain.
Also the MPControl.log on the Internet Facing Management Point was reporting the following error, “Call to HttpSendRequestSync failed for port 443 with status code 403, text: Forbidden”. Seeing this error means that the Management Point is not able to authenticate itself to check the availability against local computer (the local Management Point). After some digging it seems that there are some issues with client certificate authentication and IIS 8.x in Windows Server 2012 (R2).
403.16 Forbidden: Client Certificate Untrusted or Invalid
It seems that IIS 8.X is not using the Certificate Trust List by default, without this list client authentication via certificates will fail with the 403.16 error and the certificate is considered untrusted.
To work around this issue we need to configure the Windows Server 2012 operating system not to send the trusted list and use the Certificate Store of the server. The work around is described here and is done by adding two DWORD registry keys in HKey_Local_Machine\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
- SendTrustedIssuerList = 0 (stop sending list of trusted root certification authorities during the TLS/SSL handshake process)
- ClientAuthTrustMode = 2 (Set trust mode to Exclusive CA Trust, requires that a client certificate chain to either an intermediate CA certificate or root certificate in the caller-specified trusted issuer store.)
After checking the root certificates of the subordinate certificate authority and the offline root certificate authority and setting the two registry keys the 403.16 error went away.
403.13 Forbidden: client certificate revoked
Now that the 403.16 issue was solved IIS was still reporting the 403.13 (Client Certificate Revoked) and the MPControl.log of the Management Point was still reporting the error “Call to HttpSendRequestSync failed for port 443 with status code 403, text: Forbidden”.
To be able to fix this one we need to actually disable CRL checking in IIS. This can be done via a solution provided here! Checking the configuration can be done with netsh http show sslcert this will report the current Verify Client Certificate Revocation setting like shown below.
Reconfiguring the Verify Client Certificate Revocation setting can be done by using the NETSH commands (removing and re-adding the HTTPS binding) or adding the DWORD registry key DefaultSslCertCheckMode to 1. Like shown below.
After setting all of the registry keys, rebooting the system, the Management Point was installed and operational again and the 403.13 and 403.16 errors were disappeared from the IIS logs.
So far the note to myself, hope you can use it also 😉 Till next time!
Thanks for posting that Peter – exactly my issues too!. 🙂
Now worries! Thanks for letting me know 🙂
Does this cause any sort of security holes? I’m specifically wondering about the ClientAuthTrustMode=2 Registry Key which is what fixed my problem.
Hi John, not that I know of. The workaround is described by Microsoft at their blog. https://blogs.technet.microsoft.com/configurationmgr/2013/08/13/support-tip-a-configmgr-2012-management-point-enabled-for-ssl-fails-with-403-forbidden/
Finally, after searching the internet for 1 year and a half I find this solution.
I had given up and reattempted to fix this every so often.
7 years later, and this solved my problem.
Took me 9 days to find this Post
Thanks a million
Craziness that this post has helped us in 2021… If you are still around Peter, Thanks!