HTTP Fehlercode 403 bei Anmeldung mittels Client-Zertifikat an Internet Information Services (IIS) nach Erneuerung des Webserver-Zertifikats

Folgendes Szenario angenommen:

Ein Benutzer oder eine Anwendung ruft eine auf einem Internet Information Services (IIS) Webserver betriebene Webseite oder Webanwendung auf.
Der Webserver is so konfiguriert, dass für die aufgerufene Ressource ein Clientzertifikat angefordert wird.
Obwohl auf dem Client ein gültiges Clientzertifikat vorliegt, wird umgehend der Fehlercode 403 Forbidden zurückgegeben. Der Anwender wird (bei Aufruf der Seite mit einem Browser) nicht zur Auswahl eines Zertifikats aufgefordert.
Das Webserver-Zertifikat wurde jüngst erneuert und die IIS SSL-Bindung entsprechend über den IIS-Manager konfiguriert.

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

Das hier beschriebene Verhalten kann von Anwendung zu Anwendung abweichen. Nähere Details im weiteren Verlauf des Artikels.

Fehlersuche

Im Zugriffsprotokoll des Webservers ist der Subcode "7" (sc-status, also HTTP 403.7) mit Fehlercode "5" (sc-substatus) protokolliert.

Der Fehlercode (sc-win32-status) kann mit folgendem Befehl aufgelöst werden:

certutil -error {Fehlercode}

DIe Fehlercodes sind in der Header-Datei WinError.h definiert, welche Bestandteil des Windows Software Development Kit (SDK) ist.

Der Fehlercode "5" lautet übersetzt also "ERROR_ACCESS_DENIED".

Ursache

Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.

Im vorliegenden Fall war der IIS Web Server konfiguriert, bei der Authentifizierung eine Liste der Zertifizierungsstellen an den anfragenden Client zu senden, denen der Server für die Anmeldung vertraut.

Dieses Verhalten wird über die Direktive "SendTrustedIssuerList" unterhalb des folgenden Registrierungsschlüssels gesteuert:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

In der Standardeinstellung ist der Wert nicht gesetzt, somit sendet die Web Server in der Standardeinstellung auch keine Liste von vertrauenswürdigen Zertifizierungsstellen.

Darüber hinaus kann das Verhalten zum Erzeugen dieser Liste über die Direktive "ClientAuthTrustMode" gesteuert werden:

Wert	Beschreibung
0	Standardeinstellung. Jedem Clientzertifikat, dem der Webserver vertraut, wird akzeptiert (also von allen als vertrauenswürdig markierten Zertifikatketten).
1	Explizite Vertrauensstellung zu einer bestimmten Stammzertifizierungsstelle.
2	Explizite Vertrauensstellung zu einer bestimmten ausstellenden Zertifizierungsstelle.

Ist die "SendTrustedIssuerList" Direktive auf "1" konfiguriert und die "ClientAuthTrustMode" auf "0" gesetzt, darf kein Zertifikat im Speicher für vertrauenswürdige Stammzertifizierungsstellen liegen, das keine Stammzertifizierungsstelle abbildet (also ein nicht selbstsigniertes Zertifikat).

Ist nun die "SendTrustedIssuerList" Direktive auf "1" konfiguriert und die "ClientAuthTrustMode" auf "1" oder "2" gesetzt, benötigt der IIS eine Angabe, welchen Vertrauensspeicher er für den expliziten Vertrauensstatus verwenden soll. Dies wird über den Parameter "Ctl Store Name" in der Konfiguration der SSL-Bindung gesetzt und geht verloren, wenn die SSL-Bindung per IIS Manager angepasst wird.

Überprüft werden kann dieses Verhalten mit folgendem Kommandozeilenbefehl:

netsh http show sslcert

Ist der "Ctl Store Name" nicht konfiguriert, wird die Liste aus dem Zertifikatspeichert für vertrauenswürdige Stammzertifizierungsstellen gebildet und gesendet, was nicht jede Anwendung korrekt interpretiert.

Inspiziert man den SSL Datenverkehr mit Wireshark, kann man das Verhalten entsprechend nachvollziehen.

Der "Certificate Request" erscheint im "Server Hello" zwischen dem "Server Key Exchange" und dem "Server Hello done". Fehlt der "Certificate Request" hier, scheint der Server kein Clientzertifikat anzufordern.

Lösung: SSL-Bindung aktualisieren

Zunächst müssen folgende Konfigurationsparameter bekannt sein:

Die Kombination aus IP-Adresse und Port oder Hostnamen und Port
Den Fingerabdruck (Thumbprint) des Web Server Zertifikats
Die Application ID der IIS-Webseite
Der Zertifikatspeicher (in der Regel "My" oder "Webhosting")

Wenn bereits eine SSL-Bindung vorhanden ist, können diese Werte aus dieser ausgelesen werden:

Ziel-Zertifikatspeicher identifizieren

Darüber hinaus muss der gewünschte Zertifikatspeicher festgelegt werden, der für die Speicherung der vertrauenswürdigen Zertifizierungsstellen-Zertifikate verwendet werden soll.

In der Regel wird hierfür der "Client Authentication Issuers" (ClientAuthIssuer) Zertifikatspeicher verwendet. In diesen werden die Zertifikate der ausstellenden Zertifizierungsstellen importiert, denen explizit die Ausstellung von Zertifikaten für die Anmeldung am Webserver gestattet wird.

Eine Liste der Zertifikatspeicher und der zu verwendenen Namen kann mit der Windows PowerShell ausgegeben werden:

Get-ChildItem -Path Cert:\LocalMachine\

Anpassen der Zertifikatbindung

Anschließend kann eine Aktualisierung mit folgendem Kommandozeilenbefehl erfolgen:

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

Ergebniskontrolle

Ist die Konfiguration nun korrekt eingerichtet, sollte der Webserver nur noch die im "Client Authentication Issuers" konfigurierten Zertifizierungsstellen an den Client senden.

Artverwandte Fehler

Den gleichen Fehler habe ich auch schon angetroffen (die Sinnhaftigkeit außen vor gelassen), wenn zwei SSL-Zertifikate auf die gleiche IIS Webseite gebunden waren (eine Bindung davon mit, die andere ohne konfigurierte Server Name Incidation, SNI). Eine SSL Bildung hatte den Client Authentication Issuers Zertifikatspeicher konfiguriert, die andere nicht.

Entsprechend ist die Authentifizierung fehlgeschlagen, wenn die zur falsch konfigurierten SSL Bindung konfigurierte Adresse zum Aufruf verwendet wurde.

Weiterführende Links:

TLS-Datenverkehr mit Wireshark inspizieren (HTTPS entschlüsseln)

Externe Quellen

Overview of TLS – SSL (Schannel SSP) (Microsoft)
Schannel SSP Technical Overview (Microsoft)
How it works on the wire: IIS HTTP Client certificate authentication (Microsoft)
IIS may reject client certificate requests with HTTP 403.7 or 403.16 errors (Microsoft)
The HTTP status code in IIS 7.0 and later versions (Microsoft)