Authentification TLS mutuelle

En règle générale, la communication HTTPS n'est possible qu'une seule fois : le client vérifie l'identité du serveur.

Pour les applications nécessitant que l'équilibreur de charge authentifie l'identité des clients qui s'y connectent, utilisez le protocole TLS mutuel (mTLS).

Avec l'authentification mTLS, l'équilibreur de charge demande au client d'envoyer un certificat pour s'authentifier lors du handshake TLS avec l'équilibreur de charge. Vous pouvez configurer un magasin de confiance utilisé par l'équilibreur de charge pour valider la chaîne de confiance du certificat client.

Les équilibreurs de charge d'application suivants sont compatibles avec mTLS :

• Équilibreur de charge d'application externe global
• Équilibreur de charge d'application classique
• Équilibreur de charge d'application externe régional (bêta)
• Équilibreur de charge d'application interne régional (Bêta)
• Équilibreur de charge d'application interrégional (aperçu)

Architecture

Les ressources suivantes sont requises pour que les équilibreurs de charge soient compatibles avec un déploiement d'authentification mTLS :

• Une ressource de règle TLS du serveur (ServerTLSPolicy). Permet de spécifier le mode TLS côté serveur et la ressource TrustConfig à utiliser lors de la validation des certificats clients. Les règles TLS du serveur sont compatibles avec l'authentification mTLS. Les règles TLS du serveur peuvent être associées à la ressource de proxy HTTPS cible.

• Une ressource TrustConfig. Une ressource Gestionnaire de certificats. TrustConfig contient une seule ressource de magasin de confiance utilisée pour valider les certificats clients. Pour en savoir plus, consultez la page Gérer les configurations d'approbation.

  Vous pouvez importer des certificats ajoutés à la liste d'autorisation dans TrustConfig. Un certificat figurant sur la liste d'autorisation est toujours considéré comme valide tant qu'il peut être analysé, qu'il fournit la preuve de possession de la clé privée et que les contraintes liées au champ SAN du certificat sont remplies. Les certificats expirés sont également considérés comme valides lorsqu'ils sont ajoutés à la liste d'autorisation.

• Un magasin de confiance. Contient les certificats de l'autorité de certification et de l'autorité de certification intermédiaire utilisés pour valider la chaîne de certificats 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 le certificat racine de confiance de l'équilibreur de charge ou les certificats CA intermédiaires.

  Vous pouvez importer les types de certificats clients 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.
  • Les certificats signés, comme décrit dans la section Configurer un protocole TLS mutuel avec des certificats fournis par l'utilisateur.

L'image suivante montre les composants mTLS :

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.

Figure 1. Authentification TLS mutuelle avec des composants de l'équilibreur de charge d'application externe global (cliquez pour agrandir).

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.

Figure 1. Authentification TLS mutuelle avec des composants de l'équilibreur de charge d'application interne régional (cliquez pour agrandir).

Pour en savoir plus sur les composants d'un déploiement d'équilibreur de charge d'application, consultez les sections suivantes :

• Architecture (équilibreurs de charge d'application externes)
• Architecture et ressources (équilibreurs de charge d'application internes)

Fonctionnalités

Les fonctionnalités compatibles avec mTLS pour les équilibreurs de charge vous permettent d'effectuer les opérations suivantes :

• Valider la preuve de possession de la clé privée du certificat présenté par le client.

• Valider les certificats clients dans l'un des deux modes suivants :

  • Refuser les demandes si nous ne pouvons pas valider la chaîne de certificats client auprès d'un magasin de confiance.
  • Transmettre toutes les requêtes au backend, même si elles ne fournissent pas de certificat client.

• Effectuer une validation du certificat client sur une ancre PKI importée. Possibilité d'ajouter séparément plusieurs ancres PKI pour faciliter la migration sans temps d'arrêt d'une ancienne PKI vers une nouvelle.

• Fournir des certificats intermédiaires supplémentaires à utiliser pour la création du chemin de validation sur les ancres PKI spécifiées. Les certificats intermédiaires vous permettent d'utiliser l'authentification mTLS avec des clients qui ne réussissent 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 de requêtes personnalisés.

• Transmettre le résultat de la validation et toutes les erreurs de validation au backend à l'aide d'en-têtes de requêtes personnalisés.

Pour obtenir une description plus détaillée du processus de validation, consultez la section Étapes de validation du certificat client plus loin sur cette page.

Modes de validation du client MTLS

Lorsque le client présente un certificat non valide ou aucun certificat à l'équilibreur de charge, clientValidationMode spécifie la manière dont la connexion client est gérée.

Les valeurs clientValidationMode sont les suivantes :

• ALLOW_INVALID_OR_MISSING_CLIENT_CERT autorise la connexion à partir du client même si la validation de la chaîne de certificats du certificat client a échoué ou si aucun certificat client n'a été présenté. La preuve de possession de la clé privée est toujours vérifiée lorsque le certificat client est présenté.

  Vous pouvez utiliser des variables d'en-tête personnalisées avec ce mode pour indiquer au backend si le client a fourni un certificat, si la validation du certificat a réussi et d'autres informations extraites du certificat.

• REJECT_INVALID rejette la connexion si un client ne fournit pas de certificat ou si la validation du certificat a échoué.

Vous pouvez afficher les journaux pour la validation du certificat client mTLS lorsque la journalisation est activée sur le service de backend.

Valeurs d'en-têtes personnalisées transmises au backend

Le tableau suivant répertorie toutes les valeurs des variables d'en-têtes personnalisés TLS mutuels qui sont toujours transmises au backend (type de requête "Transmettre la requête au backend"). Les en-têtes personnalisés sont transmis au backend lorsque le paramètre clientValidationMode est défini sur ALLOW_INVALID_OR_MISSING_CLIENT_CERT ou que le certificat client a réussi la validation du certificat.

État du certificat client	clientValidationMode	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 ou son émetteur ne dispose pas de 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>

Erreurs consignées pour les connexions fermées

Les erreurs suivantes entraînent une connexion client fermée lorsque clientValidationMode est défini sur ALLOW_INVALID_OR_MISSING_CLIENT_CERT ou REJECT_INVALID. Pour en savoir plus, consultez la section Messages d'échec HTTP statusDetails. Ces erreurs sont consignées dans Cloud Logging et décrites dans le tableau suivant.

Remarque : Ces erreurs ne sont pas consignées pour les équilibreurs de charge d'application internes interrégionaux, les équilibreurs de charge d'application externes régionaux ou les équilibreurs de charge d'application internes régionaux.

État du certificat client	Demande	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 connexion	client_cert_exceeded_size_limit

Erreurs consignées avec la validation REJECT_INVALID

Les erreurs suivantes entraînent une connexion fermée (type de requête "Arrêter la connexion") lorsque clientValidationMode est défini sur REJECT_INVALID. Pour en savoir plus, consultez la section Messages d'échec HTTP statusDetails. Ces erreurs sont consignées dans Cloud Logging et décrites dans le tableau suivant.

Remarque : Ces erreurs ne sont pas consignées pour les équilibreurs de charge d'application internes interrégionaux, les équilibreurs de charge d'application externes régionaux ou les équilibreurs de charge d'application internes régionaux.

É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 ou son émetteur ne dispose pas de 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

Étapes de validation du certificat client

Lors de la validation d'un certificat client, l'équilibreur de charge effectue les étapes suivantes :

1. L'équilibreur de charge valide la signature du client pour prouver qu'il possède la clé privée du certificat client. Si cette étape échoue, l'équilibreur de charge fait toujours échouer le handshake TLS, même si votre configuration autorise les certificats clients non valides ou manquants, et aucune information n'est consignée.
2. Si la configuration inclut un TrustAnchor, l'équilibreur de charge valide une chaîne de confiance entre le certificat client et le TrustAnchor configuré. Plus précisément, l'équilibreur de charge vérifie les éléments suivants :
   • Les certificats client, intermédiaires et racines sont conformes aux exigences relatives aux certificats.
   • Le champ d'objet des certificats parents correspond au champ du problème dans les certificats enfants.
   • 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.
   • Le SAN d'un certificat enfant n'enfreint pas le champ NameConstraints du certificat parent.
3. Si la vérification de la chaîne de confiance réussit, la requête est transmise au backend avec tous les en-têtes personnalisés mTLS configurés pour le point de terminaison.
4. Si la vérification de la chaîne de confiance échoue :
   • Si ClientValidationMode est défini sur REJECT_INVALID, l'équilibreur de charge interrompt la connexion et enregistre la raison dans Cloud Logging.
     Remarque : Ces erreurs ne sont pas consignées pour les équilibreurs de charge d'application internes interrégionaux, les équilibreurs de charge d'application externes régionaux ou les équilibreurs de charge d'application internes régionaux.
   • Si ClientValidationMode est défini sur ALLOW_INVALID_OR_MISSING_CLIENT_CERTIFICATE, l'équilibreur de charge transfère toujours la requête au backend. Vous pouvez utiliser des en-têtes de requêtes personnalisés pour indiquer au backend que la validation a échoué et le motif de l'échec. Pour les équilibreurs de charge d'application internes interrégionaux, les équilibreurs de charge d'application externes régionaux ou les équilibreurs de charge d'application internes régionaux, en plus des en-têtes de requêtes personnalisés, vous pouvez configurer des champs facultatifs mTLS pour vérifier la raison de l'échec.

Exigences relatives aux certificats

• Les certificats doivent utiliser des algorithmes de chiffrement RSA ou ECDSA.
• 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.
  • 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.
  • 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. Ceci est nécessaire pour le certificat qui émet le certificat client.
  • Le certificat ne doit pas être arrivé à expiration.

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 100 ancres de confiance, 100 certificats intermédiaires et 500 certificats ajoutés à la 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 certificats clients autosignés sont toujours considérés comme non valides par l'équilibreur de charge.

Étapes suivantes

• Configurer un protocole TLS mutuel avec des certificats fournis par l'utilisateur

• Configurer un protocole TLS mutuel avec une autorité de certification privée

• Variables pouvant apparaître dans la valeur d'en-tête

• Configurer le protocole TLS mutuel pour un équilibreur de charge d'application externe global

• Configurer le protocole TLS mutuel pour un équilibreur de charge d'application classique

• Configurer le protocole TLS mutuel pour un équilibreur de charge d'application interne

• Configurer le protocole TLS mutuel pour un équilibreur de charge d'application externe régional