Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Présentation du protocole TLS mutuel

La TLS mutuelle (mTLS) est un protocole standard du secteur pour l'authentification mutuelle entre un client et un serveur. Il garantit que le client et le serveur s'authentifient mutuellement en vérifiant que chacun détient un certificat valide émis par une autorité de certification (CA) de confiance. Contrairement au protocole TLS standard, où seul le serveur est authentifié, mTLS exige que le client et le serveur présentent des certificats, confirmant l'identité des deux parties avant l'établissement de la communication.

mTLS est configuré sur la ressource de proxy HTTPS cible de tous les équilibreurs de charge d'application :

Équilibreur de charge d'application externe global
Équilibreur de charge d'application classique
Équilibreur de charge d'application externe régional
Équilibreur de charge d'application interne régional
Équilibreur de charge d'application interne interrégional

mTLS utilise l'infrastructure à clé publique (PKI) pour authentifier l'identité des entités qui communiquent sur le réseau. L'infrastructure comprend trois composants : un client, un serveur et une autorité de certification (CA). mTLS pour les équilibreurs de charge est compatible avec les fonctionnalités suivantes :

Vérifier que le client présentant le certificat possède sa clé privée.
Validez les certificats clients à l'aide de l'un des modes de validation client.
Valider les certificats clients par rapport à une ancre PKI (certificat racine) importée, avec la possibilité d'ajouter plusieurs ancres séparément pour permettre une migration fluide d'une ancienne PKI vers une nouvelle sans temps d'arrêt.
Fournir des certificats intermédiaires supplémentaires pour faciliter la construction du chemin de validation du certificat client sur les ancres PKI spécifiées (certificats racine). Ces certificats intermédiaires permettent à mTLS de fonctionner avec les clients qui ne fournissent pas la chaîne de certificats complète.
Générer et transmettre l'empreinte du certificat au backend en tant qu'en-tête de requête personnalisé.
Transmettre les champs sélectionnés extraits du certificat au backend à l'aide d'en-têtes personnalisés.
Transmettre le résultat de la validation et toutes les erreurs de validation au backend à l'aide d'en-têtes personnalisés.

Exigences relatives aux certificats

Lorsque vous configurez des certificats pour mTLS, assurez-vous qu'ils respectent les exigences suivantes :

Les outils de cryptographie modernes constituent la base de l'authentification mTLS. Les certificats doivent utiliser des algorithmes RSA ou ECDSA pour l'échange de clés.

Remarque : Les algorithmes de hachage doivent utiliser SHA-256 ou une fonction de hachage cryptographique plus puissante. Les algorithmes de hachage tels que SHA-1 ne sont pas acceptés, sauf si le mode de validation du client ALLOW_VALIDATION_RELAXATIONS est configuré avec l'assouplissement ALLOW_SHA1_HASHING, qui permet de valider les chaînes de certificats client signées à l'aide d'anciens condensés de message SHA-1. Les algorithmes de hachage tels que MD4 et MD5 ne sont pas acceptés.
Pour les certificats client (feuille) :
- L'extension Contraintes de base ne doit pas contenir CA=true.
- L'extension Utilisation étendue de la clé doit contenir clientAuth.
  
  Remarque : Si vous utilisez le mode de validation du client ALLOW_VALIDATION_RELAXATIONS avec l'assouplissement ALLOW_MISSING_EKU, l'équilibreur de charge ignore cette exigence. Toutefois, si le certificat comporte une extension EKU qui liste un autre objectif (tel que serverAuth), mais pas clientAuth, la connexion est refusée.
- L'extension Utilisation étendue de la clé ne doit pas contenir les champs codeSigning, timeStamping ou OCSPSigning.
- Le certificat ne doit pas être arrivé à expiration.
  
  Remarque : Si vous utilisez le mode de validation du client ALLOW_VALIDATION_RELAXATIONS avec l'assouplissement ALLOW_EXPIRED_LEAF_CERTIFICATE, l'équilibreur de charge ignore cette exigence.
- Le certificat client ne peut pas être un certificat autosigné.
Pour les certificats racines et intermédiaires :
- L'extension Contraintes de base doit contenir CA=true.
- L'extension Utilisation de la clé doit être définie sur keyCertSign.
- L'extension Utilisation étendue de la clé doit contenir le champ clientAuth.
- Le certificat ne doit pas être arrivé à expiration.

Architecture d'un déploiement mTLS

Avec mTLS, vous pouvez configurer une ressource de configuration de confiance, qui contient un magasin de confiance. Le magasin de confiance encapsule une ancre de confiance (certificat racine) et, éventuellement, un ou plusieurs certificats intermédiaires. Lorsque l'équilibreur de charge reçoit un certificat client, il le valide en établissant une chaîne de confiance entre le certificat client et l'ancre de confiance configurée.

Voici un bref aperçu des différentes ressources que vous devez configurer pour configurer mTLS pour l'équilibreur de charge :

Configuration de confiance. Contient une seule ressource de magasin de confiance, qui encapsule à son tour une ancre de confiance (certificat racine) et, éventuellement, un ou plusieurs certificats intermédiaires. La configuration de confiance permet d'établir une chaîne de confiance entre le certificat client et l'ancre de confiance. Pour en savoir plus, consultez Configurations de confiance.

Si vous devez utiliser un certificat autosigné, expiré ou non valide, ou si vous n'avez pas accès aux certificats racine et intermédiaire, vous pouvez ajouter ce certificat à la configuration de confiance dans le champ allowlistedCertificates. Vous n'avez pas besoin d'un magasin de confiance pour ajouter un certificat à une liste d'autorisation.

L'ajout d'un certificat à la liste d'autorisation signifie que le certificat est toujours considéré comme valide tant qu'il est analysable, que la preuve de possession de la clé privée est établie et que les contraintes du champ SAN du certificat sont respectées.
Magasin de confiance. Contient les certificats de l'ancre de confiance et de l'autorité de certification intermédiaire utilisés pour établir une chaîne de confiance et valider le certificat client. Une autorité de certification est utilisée pour émettre des certificats de confiance pour le client. L'autorité de certification est identifiée par l'ancre de confiance de l'équilibreur de charge (certificat racine) ou les certificats CA intermédiaires.

Vous pouvez importer les types de certificats racine et intermédiaire suivants dans le magasin de confiance :
- Certificats émis par des autorités de certification tierces de votre choix
- Certificats émis par des autorités de certification privées dans votre contrôle, comme décrit dans la section Configurer l'authentification TLS mutuelle avec une autorité de certification privée.
- Certificats fournis par l'utilisateur, comme décrit dans Configurer un protocole TLS mutuel avec des certificats fournis par l'utilisateur.
Authentification client (également appelée ServerTLSPolicy). Spécifie le mode de validation client et la ressource de configuration de confiance à utiliser lors de la validation des certificats client. Lorsque le client présente un certificat non valide ou ne présente aucun certificat à l'équilibreur de charge, le mode de validation client spécifie la façon dont la connexion client est gérée. Vous pouvez spécifier tous les paramètres liés à l'authentification mTLS dans les règles TLS du serveur. La ressource d'authentification du client (ServerTLSPolicy) est associée à la ressource de proxy HTTPS cible.

Les schémas suivants montrent les différents composants mTLS associés à la ressource de proxy HTTPS cible des équilibreurs de charge d'application globaux et régionaux.

global

Le schéma suivant montre les composants d'un déploiement d'équilibreur de charge d'application externe. Cette architecture s'applique également à l'équilibreur de charge d'application interne interrégional, qui est un équilibreur de charge d'application interne utilisant des composants globaux.

régional

Le schéma suivant montre les composants d'un déploiement d'équilibreur de charge d'application interne régional. Cette architecture s'applique également à l'équilibreur de charge d'application externe régional, qui est un équilibreur de charge d'application externe utilisant des composants régionaux.

Modes de validation du client

L'attribut clientValidationMode de la ressource d'authentification client (ServerTLSPolicy) spécifie la manière dont l'équilibreur de charge gère la connexion client. Le mode détermine si les certificats clients non valides ou manquants sont strictement rejetés (REJECT_INVALID), rejetés à l'exception de vérifications X.509 assouplies spécifiques (ALLOW_VALIDATION_RELAXATIONS) ou transférés au backend (ALLOW_INVALID_OR_MISSING_CLIENT_CERT).

Les différents modes de validation client sont les suivants :

Autoriser un certificat client non valide ou l'absence de certificat client (ALLOW_INVALID_OR_MISSING_CLIENT_CERT)
Rejeter les certificats client non valides (REJECT_INVALID)
Autoriser les assouplissements de validation (ALLOW_VALIDATION_RELAXATIONS)

Autoriser un certificat client non valide ou l'absence de certificat client

Le mode ALLOW_INVALID_OR_MISSING_CLIENT_CERT autorise la connexion à partir du client même si la validation du certificat client échoue ou si le client ne présente pas de certificat. Dans ce mode, l'équilibreur de charge autorise la connexion à partir du client et transmet toutes les requêtes au backend, qu'une chaîne de confiance puisse être établie ou non.

La preuve de possession de la clé privée est toujours vérifiée lorsque le certificat client est présenté. Si le client ne peut pas prouver qu'il possède la clé privée, le handshake TLS est arrêté, même si le mode de validation du client autorise un certificat client non valide ou manquant.

Refuser un certificat client non valide

Le mode REJECT_INVALID rejette la connexion si un client ne fournit pas de certificat ou si la validation du certificat a échoué. Dans ce mode, l'équilibreur de charge met fin à la connexion du client s'il ne peut pas établir de chaîne de confiance entre le certificat client et l'ancre de confiance.

Autoriser les assouplissements de validation

Le mode ALLOW_VALIDATION_RELAXATIONS applique la validation du certificat client, mais permet d'assouplir certaines vérifications de validation, par exemple lors d'une migration lorsque les anciens certificats clients ne répondent pas à toutes les exigences strictes concernant les certificats. Si vous disposez d'une ressource ServerTLSPolicy existante en mode REJECT_INVALID, vous pouvez la mettre à jour pour utiliser le mode ALLOW_VALIDATION_RELAXATIONS et spécifier la liste des assouplissements de validation que vous souhaitez autoriser.

Vous pouvez spécifier une ou plusieurs des valeurs suivantes dans le champ clientValidationRelaxations :

ALLOW_MISSING_EKU : permet au certificat client d'omettre l'extension d'utilisation étendue de la clé (EKU).

ALLOW_MISSING_EKU n'autorise qu'un certificat qui n'a pas d'extension EKU. Il n'ignore pas une extension EKU présente avec un objectif incorrect. Par exemple, si l'extension EKU est présente dans le certificat client, elle doit toujours inclure l'objectif de la clé clientAuth (OID 1.3.6.1.5.5.7.3.2), comme spécifié dans les exigences concernant les certificats. Si le certificat comporte une extension EKU qui liste un autre objectif (tel que serverAuth), mais pas clientAuth, la connexion est refusée.

Attention : L'activation de ALLOW_MISSING_EKU est risquée si vous utilisez une autorité de certification racine qui émet des certificats à des fins multiples. Sans l'application de l'EKU, un certificat destiné à un usage autre que l'authentification (comme S/MIME ou l'authentification serveur uniquement) peut être accepté pour l'authentification client mTLS. N'utilisez cet assouplissement que si vous utilisez une autorité de certification privée dédiée pour émettre des certificats d'authentification client.
ALLOW_SHA1_HASHING : permet de valider les chaînes de certificats client signées à l'aide d'anciens condensés de message SHA-1.

Attention : Autoriser les condensés de message SHA-1 n'est pas sécurisé. N'utilisez cet assouplissement que temporairement pour prendre en charge les anciens clients pendant les périodes de migration.
ALLOW_EXPIRED_LEAF_CERTIFICATE : permet de valider un certificat client d'entité finale arrivé à expiration. L'équilibreur de charge valide le certificat client d'entité finale expiré comme si l'heure actuelle était une seconde avant la fin de sa période de validité (notAfter moins une seconde). Cela permet au certificat client d'entité finale de passer la vérification de l'expiration. Cet assouplissement s'applique strictement au certificat d'entité finale du client, et non aux certificats intermédiaires ou racine de la chaîne. Les certificats d'entité finale client qui ne sont pas encore valides (où l'heure actuelle est antérieure au code temporel notBefore) sont toujours rejetés.

Attention : Autoriser les certificats clients d'entité finale expirés n'est pas sécurisé. N'utilisez cet assouplissement que temporairement pour prendre en charge les anciens clients pendant les périodes de migration.

Le mode ALLOW_VALIDATION_RELAXATIONS nécessite un certificat client et valide la chaîne de certificats par rapport à la ressource de configuration de confiance configurée, tout en appliquant les assouplissements de validation spécifiques que vous spécifiez dans le champ clientValidationRelaxations.

Lorsque vous sélectionnez ALLOW_VALIDATION_RELAXATIONS, vous devez spécifier au moins un assouplissement de la validation. Si vous sélectionnez plusieurs assouplissements, ils sont tous appliqués simultanément. Tant que le client fournit un certificat valide après l'application des assouplissements sélectionnés, l'équilibreur de charge accepte la connexion. Par exemple, si vous configurez ALLOW_MISSING_EKU et ALLOW_SHA1_HASHING, l'équilibreur de charge accepte les connexions des clients qui présentent des certificats valides, mais qui omettent l'extension d'utilisation étendue de la clé (EKU) et utilisent le hachage SHA-1.

Si un client ne fournit pas de certificat ou si la validation du certificat échoue pour une raison non couverte par les assouplissements configurés, l'équilibreur de charge met fin à la connexion et enregistre l'erreur dans Cloud Logging.

Google Cloud recommande d'utiliser les assouplissements de validation uniquement comme solution temporaire lors des migrations de certificats. L'utilisation de ALLOW_VALIDATION_RELAXATIONS est plus sécurisée que celle de ALLOW_INVALID_OR_MISSING_CLIENT_CERT, car l'équilibreur de charge applique toujours toutes les autres vérifications de validation et ne nécessite pas de logique de validation personnalisée sur votre backend.

Configurer mTLS sur l'équilibreur de charge

Vous trouverez ci-dessous une présentation générale des étapes clés à suivre pour configurer mTLS sur votre équilibreur de charge :

Créez une ressource de configuration de confiance comprenant l'ancre de confiance (certificat racine) et les certificats intermédiaires qui servent de racines de confiance.
Associez la configuration de confiance à la ressource d'authentification client (ServerTLSPolicy), qui définit le mode de validation client.
Associez la ressource d'authentification du client (ServerTLSPolicy) à la ressource de proxy HTTPS cible de l'équilibreur de charge.
Facultatif : Vous pouvez utiliser des en-têtes mTLS personnalisés pour transmettre des informations sur la connexion mTLS à un service de backend ou à un mappage d'URL.

Pour en savoir plus sur cette configuration, consultez les guides suivants :

Étapes de validation du certificat client

Lors de la validation du certificat client, l'équilibreur de charge effectue les opérations suivantes :

Vérifier que le client possède la clé privée

Le client prouve qu'il possède la clé privée associée à la clé publique du certificat en générant une signature lors du processus de handshake. L'équilibreur de charge valide cette signature à l'aide de la clé publique du client. Si la validation de la signature échoue, cela signifie que le client n'est pas le propriétaire du certificat. Dans ce cas, le handshake TLS est arrêté, même si votre configuration autorise un certificat client non valide ou manquant. Aucune erreur n'est consignée pour les équilibreurs de charge d'application externes globaux, mais une erreur TLS est consignée dans le champ proxyStatus pour les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge d'application internes.
Vérifiez la chaîne de confiance.

L'équilibreur de charge vérifie la chaîne de confiance en validant le certificat client par rapport aux certificats configurés dans la configuration de confiance. Le mode de validation client détermine si les certificats clients non valides ou manquants sont strictement rejetés (REJECT_INVALID), rejetés à l'exception de vérifications X.509 assouplies spécifiques (ALLOW_VALIDATION_RELAXATIONS) ou transférés au backend (ALLOW_INVALID_OR_MISSING_CLIENT_CERT).

Les vérifications incluent également les éléments suivants :
- Les certificats client, intermédiaires et racines sont conformes aux exigences relatives aux certificats.
- Le champ d'objet du certificat parent correspond au champ de l'émetteur dans le certificat enfant. Cette vérification permet de s'assurer que l'identité (objet) du certificat parent est identique à l'identité indiquée comme émetteur dans le certificat enfant.
- L'identifiant de la clé de l'objet (SKID) du certificat parent correspond à l'identifiant de la clé d'autorité (AKID) dans le certificat enfant. Cette correspondance confirme que le certificat enfant a été émis par l'autorité racine appropriée et qu'il est fiable, car la clé publique de la racine est référencée dans l'AKID pour vérifier la validité du certificat.
- L'autre nom de l'objet (SAN) d'un certificat enfant n'enfreint pas le champ NameConstraints du certificat parent.
Remarque : Les certificats clients autosignés ne parviennent pas à former une chaîne de confiance valide et sont toujours rejetés.
Transférer la requête au backend

Si la validation du certificat client réussit, la requête est transmise au backend à l'aide d'en-têtes mTLS personnalisés.

Toutefois, si la validation échoue, l'action entreprise dépend de la valeur du mode de validation du client :
- ALLOW_INVALID_OR_MISSING_CLIENT_CERT : la requête est transmise avec des en-têtes mTLS personnalisés indiquant la raison de l'échec de la validation. Pour les équilibreurs de charge d'application internes interrégionaux, les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge d'application internes régionaux, en plus des en-têtes mTLS personnalisés, vous pouvez configurer des champs facultatifs mTLS pour vérifier la raison de l'échec.
- REJECT_INVALID et ALLOW_VALIDATION_RELAXATIONS : la connexion est interrompue et les erreurs sont consignées dans Cloud Logging.

En-têtes mTLS personnalisés transmis au backend

Le tableau suivant présente les variables d'en-tête mTLS personnalisées qui peuvent être transmises au backend, que le certificat client soit validé ou non. Si la validation du certificat client échoue, les requêtes ne sont transmises au backend que lorsque le mode de validation client est défini sur ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

Ces variables peuvent également être définies sur un mappage d'URL.

État du certificat client	Mode de validation client	En-têtes personnalisés
La chaîne de certificats client est trop longue (plus de 10 certificats intermédiaires inclus dans le certificat client).	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_chain_exceeded_limit` `client_cert_sha256_fingerprint: <cert hash>`
La taille d'une clé RSA d'un client ou d'un certificat intermédiaire n'est pas valide. Aucune validation n'est effectuée. Les clés RSA peuvent aller de 2 048 à 4 096 bits.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_invalid_rsa_key_size` `client_cert_sha256_fingerprint: <cert hash>`
Un client ou un certificat intermédiaire utilise une courbe elliptique non compatible. Aucune validation n'est effectuée. Les courbes elliptiques valides sont P-256 et P-384.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_unsupported_elliptic_curve_key` `client_cert_sha256_fingerprint: <cert hash>`
Un client ou un certificat intermédiaire utilise un algorithme non-RSA et non-ECDSA. Aucune validation n'est effectuée.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_unsupported_key_algorithm` `client_cert_sha256_fingerprint: <cert hash>`
L'infrastructure PKI à utiliser pour la validation dispose de plus de 10 certificats intermédiaires qui partagent les mêmes informations "Subject" et "Subject Public Key Info". Aucune validation n'est effectuée.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_pki_too_large` `client_cert_sha256_fingerprint: <cert hash>`
Un certificat intermédiaire fourni pour la validation comportait plus de 10 contraintes de nom.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_chain_max_name_constraints_exceeded` `client_cert_sha256_fingerprint: <cert hash>`
Le certificat client ne dispose pas de l'extension `Extended Key Usage (EKU)` qui inclut `clientAuth`.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_chain_invalid_eku` `client_cert_sha256_fingerprint: <cert hash>`
Le délai avant expiration est dépassé lors de la tentative de validation de la chaîne de certificats.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_validation_timed_out` `client_cert_sha256_fingerprint: <cert hash>`
La limite de profondeur ou d'itération est atteinte lors de la tentative de validation de la chaîne de certificats. La profondeur maximale pour une chaîne de certificats est de 10, y compris les certificats racine et client. Le nombre maximal d'itérations est de 100 (certificats examinés pour valider la chaîne de certificats client).	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_validation_search_limit_exceeded` `client_cert_sha256_fingerprint: <cert hash>`
Vous avez configuré mTLS sans configurer de ressource `TrustConfig`. Aucune validation ne peut être effectuée, mais le hachage du certificat est transféré au backend.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_validation_not_performed` `client_cert_sha256_fingerprint: <cert hash>`
Aucun certificat client.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: false` `client_cert_chain_verified: false` `client_cert_error: client_cert_not_provided` `client_cert_sha256_fingerprint: <empty>`
La validation du certificat client échoue par rapport à la ressource `TrustConfig`.	`ALLOW_INVALID_OR_MISSING_CLIENT_CERT`	`client_cert_present: true` `client_cert_chain_verified: false` `client_cert_error: client_cert_validation_failed` `client_cert_sha256_fingerprint: <cert hash>`
Le certificat client réussit la validation de l'outil de vérification des certificats.	Non applicable	`client_cert_present: true` `client_cert_chain_verified: true` `client_cert_error: <empty>` `client_cert_sha256_fingerprint: <cert hash>` `client_cert_serial_number: <serial_number>` `client_cert_valid_not_before: <date>` `client_cert_valid_not_after: <date>` `client_cert_uri_sans: <list>` `client_cert_dnsname_sans: <list>` `client_cert_issuer_dn: <issuer>` `client_cert_subject_dn: <subject>` `client_cert_leaf: <certificate>` `client_cert_chain: <list>`

Analyser les valeurs des variables d'en-tête personnalisées transmises au backend

Certaines valeurs de variables d'en-tête mTLS personnalisées sont des représentations de chaînes encodées en Base64 de données de certificat DER (Distinguished Encoding Rules) binaires. Vous pouvez décoder des chaînes encodées en base64 à l'aide des outils ou des bibliothèques logicielles de votre choix. Voici quelques exemples :

Les systèmes macOS et Linux peuvent utiliser l'outil de ligne de commande base64, qui est un utilitaire de base inclus dans les deux systèmes d'exploitation. Pour décoder des chaînes encodées en base64 à l'aide de l'utilitaire base64, transmettez la chaîne encodée en tant qu'entrée standard à la commande base64 et utilisez l'option -d pour décoder la chaîne comme suit :
```
echo BASE_64_ENCODED_STRING | base64 -d
```

Python inclut le module base64, qui peut être utilisé pour décoder des chaînes encodées en Base64 comme suit :

import base64
encoded_string=BASE_64_ENCODED_STRING
decoded_string=base64.b64decode(encoded_string).decode()
print(decoded_string) # Note that a newline character (\n) is added to the end of the string.

Gestion des erreurs et journalisation

Les équilibreurs de charge d'application fournissent des fonctionnalités de journalisation détaillées qui vous permettent de surveiller la validation des certificats clients, d'identifier les problèmes potentiels et de résoudre les problèmes de connexion. Cette section décrit les différents types d'erreurs pouvant se produire lors de la validation mTLS et la manière dont elles sont consignées.

Erreurs consignées dans les modes `REJECT_INVALID` et `ALLOW_VALIDATION_RELAXATIONS`

Si la validation du certificat client échoue et que le mode de validation client est défini sur REJECT_INVALID ou ALLOW_VALIDATION_RELAXATIONS, la connexion est interrompue et les erreurs sont consignées dans Cloud Logging. Ces erreurs sont décrites dans le tableau suivant.

État du certificat client	Erreur consignée
La chaîne de certificats client est trop longue (plus de 10 certificats intermédiaires inclus dans le certificat client).	`client_cert_chain_exceeded_limit`
La taille d'une clé RSA d'un client ou d'un certificat intermédiaire n'est pas valide. Aucune validation n'est effectuée. Les clés RSA peuvent aller de 2 048 à 4 096 bits.	`client_cert_invalid_rsa_key_size`
Un client ou un certificat intermédiaire utilise une courbe elliptique non compatible. Aucune validation n'est effectuée. Les courbes valides sont P-256 et P-384.	`client_cert_unsupported_elliptic_curve_key`
Un client ou un certificat intermédiaire utilise un algorithme non RSA ou ECEC. Aucune validation n'est effectuée.	`client_cert_unsupported_key_algorithm`
L'infrastructure PKI à utiliser pour la validation dispose de plus de 10 certificats intermédiaires qui partagent les mêmes informations "Subject" et "Subject Public Key Info". Aucune validation n'est effectuée.	`client_cert_pki_too_large`
Un certificat intermédiaire fourni pour la validation comportait plus de 10 contraintes de nom.	`client_cert_chain_max_name_constraints_exceeded`
Le certificat client ne dispose pas d'une extension `Extended Key Usage (EKU)` qui inclut `clientAuth`.	`client_cert_chain_invalid_eku`
Le délai avant expiration est dépassé lors de la tentative de validation de la chaîne de certificats.	`client_cert_validation_timed_out`
La limite de profondeur ou d'itération est atteinte lors de la tentative de validation de la chaîne de certificats. La profondeur maximale pour une chaîne de certificats est de 10, y compris les certificats racine et client. Le nombre maximal d'itérations est de 100 (certificats examinés pour valider la chaîne de certificats client).	`client_cert_validation_search_limit_exceeded`
Vous avez configuré mTLS sans configurer de ressource `TrustConfig`.	`client_cert_validation_not_performed`
Le client n'a pas fourni le certificat demandé lors du handshake.	`client_cert_not_provided`
La validation du certificat client échoue avec la ressource `TrustConfig`.	`client_cert_validation_failed`

Erreurs consignées pour les connexions fermées

Lorsque le mode de validation du client est configuré, certaines erreurs entraînent la fermeture des connexions et sont consignées dans Cloud Logging. Ces erreurs sont décrites dans le tableau suivant.

État du certificat client	Requête	Erreur consignée
Échec de la correspondance de signature lors de l'établissement du certificat client.	Interrompre le handshake SSL	Aucun
Le service ne peut pas effectuer la validation de la chaîne de certificats.	Interrompre la connexion	`client_cert_validation_unavailable`
Erreur interne de validation de la chaîne de certificats.	Interrompre la connexion	`client_cert_validation_internal_error`
Correspondance `TrustConfig` introuvable.	Interrompre la connexion	`client_cert_trust_config_not_found`
La charge utile du certificat client (y compris les certificats intermédiaires) est trop volumineuse (plus de 16 Ko).	Interrompre la connection	`client_cert_exceeded_size_limit`

Si la journalisation est activée sur le service de backend, vous pouvez exécuter une requête pour afficher les journaux de validation du certificat client mTLS.

Limites

L'équilibreur de charge n'effectue pas de vérifications de la révocation des certificats clients.
Les équilibreurs de charge d'application vous permettent d'importer une configuration de confiance avec un seul magasin de confiance contenant au maximum 200 ancres de confiance et certificats intermédiaires (le nombre de certificats intermédiaires est limité à 100) et 500 certificats ajoutés à une liste d'autorisation. Tous les certificats intermédiaires ne doivent pas comporter plus de trois certificats partageant les mêmes informations de sujet et de clé publique d'objet. Pour plus d'informations, consultez la section Quotas et limites.
La profondeur maximale pour une chaîne de certificats est de 10, y compris les certificats racine et client. Le nombre maximal d'évaluations des certificats intermédiaires lors de la tentative de création de la chaîne de confiance est de 100. Pour en savoir plus, consultez la page Quotas et limites.
Les clés de certificats importés et transmis du client sont limitées aux éléments suivants :
- Les clés RSA peuvent aller de 2 048 à 4 096 bits. Pour plus d'informations, consultez la section Quotas et limites.
- Les clés ECDSA peuvent utiliser les courbes P-256 ou P-384.
La chaîne de certificats acceptée par le client est limitée à 16 Ko et à 10 certificats. Pour en savoir plus, consultez la page Quotas et limites.
Les certificats racines utilisés pour la validation ne peuvent pas contenir plus de 10 contraintes de nom. Pour en savoir plus, consultez la page Quotas et limites.
Les Google Front End (GFE) de couche 1 appliquent un délai avant expiration non configurable de 10 secondes pour que le client présente son certificat lors du handshake TLS. En cas de charge maximale, ce délai avant expiration peut être plus court. Les clients doivent présenter le certificat dans ce délai pour établir une connexion mTLS.