HTTP error code 403 when logging on to Internet Information Services (IIS) with a client certificate after renewing the web server certificate

Assume the following scenario:

A user or application accesses a web page or web application running on an Internet Information Services (IIS) web server.
The web server is configured to request a client certificate for the requested resource.
Although there is a valid client certificate on the client, the error code 403 Forbidden is returned immediately. The user is not prompted (when calling the page with a browser) to select a certificate.
The web server certificate was recently renewed and the IIS SSL binding was configured accordingly via the IIS Manager.

403 - Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.

The behavior described here may vary from application to application. More details in the further course of the article.

Troubleshooting

In the access log of the web server the subcode "7" (sc-status, i.e. HTTP 403.7) is logged with error code "5" (sc-substatus).

The error code (sc-win32-status) can be resolved with the following command:

certutil -error {error code}

The error codes are defined in the header file WinError.h, which is part of the Windows Software Development Kit (SDK) is.

The error code "5" is translated as "ERROR_ACCESS_DENIED".

Cause

Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.

In this case, the IIS Web Server was configured to send a list of certificate authorities that the server trusts for logon to the requesting client during authentication.

This behavior is controlled by the SendTrustedIssuerList directive below the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

By default, the value is not set, so the Web Server does not send a list of trusted certificate authorities by default.

In addition, the behavior for generating this list can be controlled via the ClientAuthTrustMode directive:

Value	Description
0	Default setting. Any client certificate trusted by the web server is accepted (that is, by all certificate chains marked as trusted).
1	Explicit reliance on a specific root Certification Authority.
2	Explicit position of trust in a particular issuing Certification Authority.

If the "SendTrustedIssuerList" directive is configured to "1" and the "ClientAuthTrustMode" is set to "0", must not have a certificate in the trusted root CA store that does not map to a root CA (i.e. a certificate that is not self-signed).

Now, if the "SendTrustedIssuerList" directive is configured to "1" and the "ClientAuthTrustMode" is set to "1" or "2", IIS needs an indication of which trust store to use for the explicit trust state. This is set via the "Ctl Store Name" parameter in the SSL binding configuration and is lost when the SSL binding is adjusted via IIS Manager.

This behavior can be checked with the following command line command:

netsh http show sslcert

If the "Ctl Store Name" is not configured, the list is formed and sent from the certificate store for trusted root certificate authorities, which not every application interprets correctly.

Inspecting SSL traffic with Wireshark, you can understand the behavior accordingly.

The "Certificate Request" appears in the "Server Hello" between the "Server Key Exchange" and the "Server Hello done". If the "Certificate Request" is missing here, the server does not seem to request a client certificate.

Solution: Update SSL binding

First, the following configuration parameters must be known:

The combination of IP address and port or host name and port
The fingerprint (thumbprint) of the Web Server certificate
The Application ID of the IIS web page
The certificate store (usually "My" or "Webhosting")

If an SSL binding already exists, these values can be read from it:

Identify target certificate store

In addition, the desired certificate store to be used for storing the trusted certificate authority certificates must be specified.

As a rule, the "Client Authentication Issuers" (ClientAuthIssuer) certificate store is used for this purpose. The certificates of the issuing certification authorities that are explicitly allowed to issue certificates for logging on to the web server are imported into this store.

A list of certificate stores and the names to use can be output using Windows PowerShell:

Get-ChildItem -Path Cert:\LocalMachine\

Customizing the certificate binding

Afterwards, an update can be done with the following command line command:

netsh ^
http ^
update sslcert ^
hostnameport=pki.adcslabor.com:443 ^
certstorename=MY ^
certhash=846762724f99a530cae257c8d18ceafb46723cd2 ^
appid={4dc3e181-e14b-4a21-b022-59fc669b0914} ^
sslctlstorename=ClientAuthIssuer

Result control

If the configuration is now set up correctly, the web server should only send the certificate authorities configured in the "Client Authentication Issuers" to the client.

Related errors

I have also encountered the same error (making no sense) when two SSL certificates were bound to the same IIS web page (one of them bound with, the other without Server Name Incidation, SNI, configured). One SSL formation had the Client Authentication Issuers certificate store configured, the other did not.

Accordingly, authentication failed if the address configured to the misconfigured SSL binding was used to make the call.

HTTP error code 403 when logging on to Internet Information Services (IIS) using client certificate after renewing web server certificate