Cette page a été traduite par l'API Cloud Translation.

Présentation du protocole TLS mutuel

Le TLS mutuel, ou 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 que la communication ne soit établie.

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

Équilibreur de charge d'application externe mondial
É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 une 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érifiez que le client présentant le certificat possède sa clé privée.
Valider les certificats clients dans l'un des deux modes suivants:
- Refuser les certificats non valides: applique une authentification stricte en rejetant les requêtes si la chaîne de certificats client ne peut pas être validée.
- Autoriser les certificats non valides ou manquants: offre une flexibilité en transmettant toutes les requêtes au backend, même si un certificat client est manquant ou non valide.
Validez les certificats client sur une ancre PKI (certificat racine) importée, avec la possibilité d'ajouter séparément plusieurs ancres pour faciliter la migration d'une ancienne PKI vers une nouvelle sans temps d'arrêt.
Fournir des certificats intermédiaires supplémentaires pour aider à créer le chemin de validation du certificat client par rapport aux ancres PKI spécifiées (certificats racine). Ces certificats intermédiaires permettent à mTLS de fonctionner avec des 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 conditions 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. Les algorithmes de hachage doivent utiliser SHA-256 ou une fonction de hachage cryptographique plus sécurisée. Les algorithmes de hachage tels que MD4, MD5 et SHA-1 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.
- 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.
- 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 truststore. Le truststore 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 à partir du certificat client jusqu'à l'ancre de confiance configurée.

Vous trouverez ci-dessous 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 la section Configurations de confiance.

Si vous devez utiliser un certificat autosigné, expiré ou autrement non valide, ou si vous n'avez pas accès aux certificats racine et intermédiaires, 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.

Ajouter un certificat à la liste d'autorisation signifie qu'il 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 sur le champ SAN du certificat sont respectées.
Magasin de confiance. Contient l'ancre de confiance et les certificats d'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 (certificat racine) de l'équilibreur de charge ou les certificats CA intermédiaires.

Vous pouvez importer les types de certificats racine et intermédiaires 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 sous 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 la section Configurer un protocole TLS mutuel avec des certificats fournis par l'utilisateur.
Authentification client (également appelée ServerTLSPolicy) : spécifie le mode de validation du 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 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.

Mode de validation client

Lorsque le client présente un certificat non valide ou aucun certificat à l'équilibreur de charge, 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.

Les valeurs du mode de validation client sont les suivantes:

ALLOW_INVALID_OR_MISSING_CLIENT_CERT : autorise la connexion à partir du client même si la validation du certificat client a échoué ou si aucun certificat client n'a été présenté. Dans ce mode, l'équilibreur de charge autorise la connexion du client et transmet toutes les requêtes au backend, que la 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 est en possession 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.
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 interrompt la connexion du client s'il ne peut pas établir une chaîne de confiance à partir du certificat client jusqu'à l'ancre de confiance.

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 ALLOW_INVALID_OR_MISSING_CLIENT_CERT ou REJECT_INVALID.
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érifiez que le client possède la clé privée.

Le client prouve qu'il est en possession 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 entre le certificat client et la configuration de confiance configurée. Les vérifications de validation incluent 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 du certificat enfant. Cette vérification garantit 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 peut être approuvé, car la clé publique de la racine est référencée dans l'AKID pour valider la validité du certificat.
- Le nom d'objet de remplacement (SAN) d'un certificat enfant n'enfreint pas le champ NameConstraints du certificat parent.
Remarque :Les certificats clients autosignés ne forment pas de chaîne de confiance valide et sont toujours rejetés.
Transférez la requête vers le backend.

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

Toutefois, en cas d'échec de la validation, l'action effectuée 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 le motif 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: 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 en-têtes mTLS personnalisés qui sont transmis au backend, à la fois lorsque le certificat client a réussi la validation et lorsqu'il a échoué. Si la validation du certificat client échoue, les en-têtes personnalisés ne sont transmis au backend que lorsque le mode de validation client est défini sur ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

É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>`

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 client, 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 survenir lors de la validation mTLS et la manière dont elles sont consignées.

Erreurs consignées en mode `REJECT_INVALID`

Si la validation du certificat client échoue et que le mode de validation client est défini sur REJECT_INVALID, 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'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 client est défini sur ALLOW_INVALID_OR_MISSING_CLIENT_CERT ou REJECT_INVALID, certaines erreurs entraînent des connexions fermées 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 afficher les erreurs consignées pour les connexions fermées lors de la 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 100 ancres de confiance, 100 certificats intermédiaires 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.