Code d'erreur HTTP 403 lors de la connexion à Internet Information Services (IIS) à l'aide d'un certificat client après le renouvellement du certificat du serveur web

Supposons le scénario suivant :

• Un utilisateur ou une application consulte une page web ou une application web exécutée sur un serveur web Internet Information Services (IIS).
• Le serveur web est configuré de telle sorte qu'un certificat client est demandé pour la ressource appelée.
• Bien qu'il existe un certificat client valide sur le client, le code d'erreur 403 Forbidden est immédiatement renvoyé. L'utilisateur n'est pas invité à choisir un certificat (lors de l'ouverture de la page avec un navigateur).
• Le certificat du serveur web a été récemment renouvelé et la liaison SSL IIS a été configurée en conséquence via le gestionnaire IIS.

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

Le comportement décrit ici peut varier d'une application à l'autre. Plus de détails dans la suite de l'article.

Dépannage

Dans le protocole d'accès du serveur web, le sous-code „7“ (sc-status, soit HTTP 403.7) est consigné avec le code d'erreur „5“ (sc-substatus).

Le code d'erreur (sc-win32-status) peut être résolu avec la commande suivante :

certutil -error {Fehlercode}

Les codes d'erreur sont définis dans le fichier d'en-tête WinError.h, qui fait partie du fichier d'installation. Kit de développement logiciel Windows (SDK) est.

Le code d'erreur „5“ se traduit donc par „ERROR_ACCESS_DENIED“.

Cause

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Dans le cas présent, le serveur web IIS était configuré pour envoyer au client demandeur, lors de l'authentification, une liste des autorités de certification auxquelles le serveur fait confiance pour la connexion.

Ce comportement est contrôlé par la directive „SendTrustedIssuerList“ située sous la clé de registre suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Par défaut, cette valeur n'est pas définie. Ainsi, le serveur web n'envoie pas non plus de liste d'autorités de certification de confiance par défaut.

De plus, le comportement de création de cette liste peut être contrôlé par la directive „ClientAuthTrustMode“ :

Valeur	Description
0	Paramétrage par défaut. Chaque certificat client auquel le serveur web fait confiance est accepté (donc par toutes les chaînes de certificats marquées comme fiables).
1	Position de confiance explicite envers une autorité de certification racine spécifique.
2	Position de confiance explicite envers une autorité de certification émettrice spécifique.

Si la directive „SendTrustedIssuerList“ est configurée à „1“ et que le „ClientAuthTrustMode“ est défini à „0“, il ne doit pas y avoir de certificat dans la liste des autorités de certification racines de confiance qui ne représente pas une autorité de certification racine (donc un certificat non auto-signé).

Si la directive „SendTrustedIssuerList“ est configurée à „1“ et que le „ClientAuthTrustMode“ est défini à „1“ ou „2“, IIS a besoin d'une indication sur le magasin de confiance qu'il doit utiliser pour le statut de confiance explicite. Cela est défini par le paramètre „Ctl Store Name“ dans la configuration de la liaison SSL et est perdu si la liaison SSL est adaptée via IIS Manager.

Ce comportement peut être vérifié à l'aide de la commande de ligne de commande suivante :

netsh http show sslcert

Si le „Ctl Store Name“ n'est pas configuré, la liste est constituée et envoyée à partir du magasin de certificats pour les autorités de certification racines de confiance, ce que toutes les applications n'interprètent pas correctement.

Si l'on inspecte le trafic SSL avec Wireshark, Si l'on se réfère à l'article de la loi sur la protection des données, on peut comprendre le comportement.

La „Certificate Request“ apparaît dans le „Server Hello“ entre le „Server Key Exchange“ et le „Server Hello done“. Si la „Certificate Request“ est absente ici, le serveur ne semble pas demander de certificat client.

Solution : mettre à jour l'engagement SSL

Tout d'abord, les paramètres de configuration suivants doivent être connus :

• La combinaison de l'adresse IP et du port ou du nom d'hôte et du port
• L'empreinte digitale (thumbprint) du certificat du serveur web
• L'ID d'application du site web IIS
• Le magasin de certificats (généralement „My“ ou „Webhosting“)

Si une liaison SSL existe déjà, ces valeurs peuvent être lues à partir de celle-ci :

Identifier le magasin de certificats cible

En outre, il faut définir la liste de certificats souhaitée qui sera utilisée pour stocker les certificats d'autorité de certification approuvés.

En règle générale, le magasin de certificats „Client Authentication Issuers“ (ClientAuthIssuer) est utilisé à cet effet. Les certificats des autorités de certification émettrices, qui sont explicitement autorisées à émettre des certificats pour la connexion au serveur web, sont importés dans cette mémoire.

Une liste des listes de certificats et des noms à utiliser peut être éditée à l'aide de Windows PowerShell :

Get-ChildItem -Path Cert:\LocalMachine\

Personnaliser la liaison des certificats

Ensuite, une mise à jour peut être effectuée à l'aide de la commande de ligne de commande suivante :

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

Contrôle des résultats

Si la configuration est maintenant correctement établie, le serveur web ne devrait plus envoyer au client que les autorités de certification configurées dans „Client Authentication Issuers“.

Erreurs de nature similaire

J'ai déjà rencontré la même erreur (sans parler de l'utilité) lorsque deux certificats SSL étaient liés à la même page web IIS (une liaison avec, l'autre sans Server Name Incidation, SNI, configurée). Une formation SSL avait le Client Authentication Issuers Certificate Store configuré, l'autre non.

En conséquence, l'authentification a échoué si l'adresse configurée pour la liaison SSL mal configurée a été utilisée pour l'appel.

Liens complémentaires :

• Inspecter le trafic TLS avec Wireshark (décrypter HTTPS)

Sources externes

• Aperçu de TLS - SSL (Schannel SSP) (Microsoft)
• Aperçu technique de Schannel SSP (Microsoft)
• Comment ça marche sur le fil : Authentification du certificat client IIS HTTP (Microsoft)
• IIS peut rejeter les demandes de certificat client avec des erreurs HTTP 403.7 ou 403.16 (Microsoft)
• Le code d'état HTTP dans IIS 7.0 et versions ultérieures (Microsoft)