Présentation du TLS authentifié et du mTLS backend

Lorsqu'un équilibreur de charge se connecte à des backends situés dans Google Cloud, il accepte tous les certificats présentés par vos backends. Dans ce cas, l'équilibreur de charge n'effectue aucune validation de certificat.

Avec le protocole TLS authentifié pour le backend ou l'authentification du backend, l'équilibreur de charge peut vérifier l'identité des backends auxquels il se connecte. Avec le mTLS de backend, l'équilibreur de charge peut également prouver son identité aux backends à l'aide d'un certificat TLS client.

Le diagramme suivant illustre la différence entre le mTLS de frontend et de backend, en se concentrant sur le rôle de l'équilibreur de charge dans chaque cas. Dans mTLS de frontend, l'équilibreur de charge fait office de serveur et vérifie l'identité du client. Dans le protocole mTLS de backend, l'équilibreur de charge agit en tant que client, prouvant son identité au backend.

mTLS pour le frontend et le backend.
mTLS de frontend et de backend (cliquez pour agrandir)

Le protocole mTLS fonctionne indépendamment sur le frontend et le backend. Vous pouvez configurer mTLS sur le frontend, le backend, ou les deux.

Ce document fournit une présentation de la TLS authentifiée pour le backend et du mTLS pour le backend. Pour en savoir plus sur le protocole mTLS de l'interface, consultez la présentation du protocole TLS mutuel.

La TLS authentifiée et la mTLS pour le backend peuvent être configurées sur la ressource de service de backend des équilibreurs de charge d'application externes globaux.

Fonctionnalités

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 (AC). L'authentification TLS du backend et l'authentification mTLS du backend ajoutent les fonctionnalités suivantes aux équilibreurs de charge d'application :

  • L'équilibreur de charge peut valider les certificats présentés par les backends par rapport à vos propres ancres de confiance. Vous pouvez importer plusieurs ancres de confiance pour permettre une migration fluide d'une ancienne PKI vers une nouvelle sans temps d'arrêt.

  • L'équilibreur de charge peut valider les certificats TLS des backends par rapport aux racines de confiance publiques (PKI Web).

  • Vous pouvez configurer des certificats intermédiaires en plus de vos ancres de confiance pour vous aider à construire le chemin de validation des certificats de backend. L'utilisation de certificats intermédiaires signifie que vos serveurs de backend n'ont pas besoin de fournir la chaîne de certificats complète.

  • Vous pouvez configurer un nom d'hôte SNI (Server Name Indication) TLS pour votre service de backend. Lors du handshake TLS, l'équilibreur de charge inclut ce nom d'hôte SNI dans le message ClientHello qu'il envoie au backend. Le backend répond ensuite avec son certificat TLS, et l'équilibreur de charge vérifie qu'au moins l'un des champs SAN (Subject Alternative Name, autre nom de l'objet) de ce certificat correspond au nom d'hôte ou à l'un des champs SAN configurés pour le service de backend.

  • Vous pouvez configurer le service de backend de votre équilibreur de charge pour qu'il utilise mTLS. L'équilibreur de charge peut ainsi prouver son identité aux backends. Cette authentification est effectuée à l'aide d'un certificat client (équilibreur de charge) que l'équilibreur de charge présente au backend.

Exigences relatives aux certificats

Lorsque vous configurez des certificats pour l'authentification TLS de backend et le mTLS de backend, 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. 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.

  • Les certificats de serveur feuille fournis par le backend doivent répondre aux exigences suivantes :

  • Pour les certificats client d'entité finale (équilibreur de charge) utilisés dans le mTLS de backend, le certificat doit être une ressource de certificat du gestionnaire de certificats. Le champ d'application de ce certificat doit être client-auth, ce qui indique qu'il est utilisé comme certificat client dans le protocole mTLS du backend.

  • Les certificats racine et intermédiaires utilisés avec la TLS authentifiée pour le backend doivent répondre aux exigences suivantes :

Composants clés de la TLS authentifiée et du mTLS pour le backend

Avec le protocole TLS authentifié pour le backend, l'équilibreur de charge peut vérifier l'identité des backends auxquels il se connecte. Vous pouvez configurer TLS authentifié pour le backend sur un équilibreur de charge HTTP(S) qui utilise HTTPS ou HTTP/2 comme protocole de service de backend. Si vous ne configurez pas la TLS authentifiée pour le backend, l'équilibreur de charge accepte n'importe quel certificat du backend. Avec le mTLS de backend, vous pouvez également configurer l'équilibreur de charge pour qu'il présente son propre certificat client au backend, que celui-ci peut utiliser pour authentifier l'équilibreur de charge.

Pour configurer le protocole TLS authentifié du backend, vous devez procéder comme suit :

  • Créez une ressource de configuration de confiance.
  • Créez une ressource de configuration d'authentification de backend.
  • Mettez à jour l'attribut de paramètre TLS sur le service de backend, en le pointant vers la ressource de configuration d'authentification de backend.

Pour configurer le mTLS de backend, vous devez créer un certificat client et l'associer à la ressource de configuration d'authentification de backend. Vous ne pouvez pas joindre le certificat client une fois la ressource de configuration d'authentification de backend créée.

Le schéma suivant montre les différents composants associés au service de backend d'un équilibreur de charge d'application, qui permettent d'activer le protocole TLS authentifié par le backend et le protocole mTLS de backend.

Composants TLS authentifiée et mTLS pour le backend.
Composants TLS authentifiée et mTLS pour le backend (cliquez pour agrandir)

Les informations suivantes présentent ces différents composants utilisés pour configurer la TLS authentifiée et la mTLS mutuelle pour le backend.

Configuration de confiance

Pour authentifier les certificats de serveur que votre backend présente à l'équilibreur de charge, ce dernier doit être configuré avec des certificats X.509 qui établissent une chaîne de confiance avec l'émetteur du certificat du backend. Vous configurez la configuration d'approbation à l'aide d'une ressource TrustConfig, qui exprime l'intégralité de la configuration d'approbation et contient un seul magasin de confiance.

Un truststore encapsule une ancre de confiance (certificat racine) et, éventuellement, un ou plusieurs certificats intermédiaires. Une ancre de confiance est un certificat représentant une racine de confiance. Un certificat de serveur valide doit afficher une chaîne de confiance vers un ancrage de confiance dans le magasin de certificats.

Un certificat intermédiaire est un certificat qui fait partie d'une chaîne de confiance menant à une ancre de confiance dans le magasin de confiance. Il est utilisé, avec toutes les autorités de certification intermédiaires supplémentaires incluses dans le certificat de feuille, pour créer la chaîne de confiance lors du processus de validation. La création d'un certificat intermédiaire est facultative.

Si vous devez utiliser un certificat autosigné, expiré, qui ne s'enchaîne pas à une racine de confiance spécifiée ou dont la validation a échoué, vous pouvez l'ajouter à une liste d'autorisation dans la configuration de confiance. La création d'un certificat autosigné pouvant être ajouté à une liste d'autorisation est également facultative.

Le magasin de confiance ne contient aucune clé privée, car seuls les certificats sont nécessaires pour valider une chaîne de confiance.

Ressource de configuration d'authentification de backend

La ressource de configuration d'authentification de backend (BackendAuthenticationConfig), associée au service de backend de l'équilibreur de charge, permet les opérations suivantes :

  • TLS authentifiée pour le backend (à l'aide de la configuration de confiance et des racines de confiance publiques)
  • mTLS de backend (à l'aide du certificat client)

Pour activer la TLS authentifiée et la mTLS mutuelle pour le backend, la ressource de configuration d'authentification de backend pointe vers les ressources suivantes :

  • Configuration de confiance (trustConfig) : configuration de confiance associée utilisée pour valider le certificat de serveur fourni par le backend.

  • Racines de confiance publiques (wellKnownRoots) : indique si l'équilibreur de charge approuve les certificats de serveur backend émis par des autorités de certification publiques, en plus des certificats approuvés par la configuration de confiance. Pour en savoir plus, consultez Utiliser des racines de confiance publiques.

  • Certificat client (clientCertificate) : certificat client que l'équilibreur de charge utilise pour exprimer son identité au backend, si la connexion au backend utilise mTLS. Pour la TLS authentifiée pour le backend (authentification du backend), ce champ peut être vide. Dans ce cas, l'équilibreur de charge authentifie uniquement le backend, mais pas lui-même, auprès du backend.

Service de backend

Dans le service de backend, l'attribut tlsSettings pointe vers les ressources suivantes pour valider le certificat de backend.

  • Configuration d'authentification de backend (authenticationConfig)
  • Nom d'hôte SNI (sni)
  • SAN acceptés (subjectAltNames)

Les champs SNI (sni) et SAN (subjectAltNames) de l'attribut tlsSettings contrôlent la façon dont l'équilibreur de charge valide le certificat du backend en fonction des valeurs SAN du certificat. Ces champs influencent le processus de validation, que la TLS authentifiée par le backend soit configurée ou non.

Lorsque le champ SNI est défini (tlsSettings.sni), l'équilibreur de charge effectue les opérations suivantes :

  • Envoie le nom d'hôte SNI au serveur de backend lors du handshake TLS.
  • Vérifie que le certificat TLS du backend inclut un SAN correspondant au nom d'hôte SNI.

Par défaut, l'équilibreur de charge vérifie que le certificat TLS du backend inclut un SAN correspondant au nom d'hôte SNI. Toutefois, si les SAN sont configurés sur le service de backend (tlsSettings.subjectAltNames), l'équilibreur de charge effectue les opérations suivantes :

  • Ignore le nom d'hôte SNI pour la validation SAN.
  • Vérifie que le certificat TLS du backend inclut un SAN qui correspond à l'un des SAN acceptés (subjectAltNames) configurés sur le service de backend.

Certificat client

En plus de l'authentification TLS du backend (authentification du backend), vous pouvez configurer le service de backend d'un équilibreur de charge pour qu'il utilise mTLS. L'équilibreur de charge peut ainsi prouver son identité au backend. Cette authentification utilise un certificat client (équilibreur de charge) que l'équilibreur de charge présente au backend.

Pour configurer le mTLS de backend, vous devez effectuer les opérations suivantes :

  • Créez une ressource de certificat client contenant le certificat client (équilibreur de charge) et sa clé privée.
  • Associez le certificat client à la ressource de configuration d'authentification de backend.

L'authentification mTLS du backend est également compatible avec les identités de charge de travail gérées Compute Engine lorsque vous configurez des certificats gérés via Certificate Manager. Les certificats PKI publics gérés ne sont pas acceptés. Tous les certificats client doivent avoir un champ d'application client-auth et respecter les exigences relatives aux certificats.

Si le backend demande un certificat client, il doit être configuré pour l'accepter. Si le backend refuse la connexion de l'équilibreur de charge, celui-ci renvoie un code d'état HTTP 502 pour les requêtes qu'il proxyfie et enregistre un état générique dans Cloud Logging.

Configurer la TLS authentifiée et la mTLS mutuelle pour le backend sur l'équilibreur de charge

Vous pouvez configurer la TLS authentifiée et la mTLS mutuelle pour le backend sur l'équilibreur de charge à l'aide d'une infrastructure à clé publique (PKI) privée ou de racines de confiance publiques.

Utiliser une infrastructure à clé publique privée

Vous trouverez ci-dessous une présentation générale des principales étapes à suivre pour configurer l'authentification TLS et l'authentification mTLS du backend sur votre équilibreur de charge à l'aide de certificats émis par votre infrastructure à clé publique privée. L'avantage d'une infrastructure à clé publique privée est qu'elle est entièrement sous votre contrôle et isolée des systèmes d'infrastructure à clé publique de l'Internet public.

  1. 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.

  2. Pour configurer l'authentification mTLS du backend, créez un certificat client contenant le certificat client (équilibreur de charge) et sa clé privée.

  3. Créez une ressource de configuration d'authentification de backend qui fait référence à la configuration de confiance. Si vous souhaitez configurer le mTLS de backend, la ressource de configuration d'authentification de backend fait référence à la fois à la configuration de confiance et au certificat client.

  4. Associez la ressource de configuration d'authentification de backend au service de backend de l'équilibreur de charge.

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

Utiliser des racines de confiance publiques

En plus d'utiliser des certificats émis par votre PKI privée pour activer le protocole TLS authentifié du backend, vous pouvez également utiliser des racines de confiance publiques pour valider le certificat du backend.

Pour utiliser des racines de confiance publiques, vous n'avez pas besoin de créer de configuration de confiance ni de l'associer à la ressource de configuration d'authentification de backend. Vous devez plutôt définir PUBLIC_ROOTS comme valeur dans le champ wellKnownRoots de la ressource de configuration de l'authentification du backend. Cela dit, vous pouvez également créer une configuration de confiance qui inclut explicitement les racines de vos certificats émis publiquement, en plus des certificats approuvés par la configuration de confiance.

Le paramètre PUBLIC_ROOTS utilise un ensemble d'AC racines, semblable à l'ensemble d'AC racines approuvé par les navigateurs, qui est géré par Google et peut changer au fil du temps. Cela présente un risque d'invalidation de vos certificats de backend lorsque ces racines changent. Si vous devez valider des certificats émis publiquement, envisagez de choisir une autorité de certification fiable et bien établie, qui utilise la signature croisée intermédiaire pour émettre vos certificats de backend. Cela permet de réduire le risque d'expiration ou de révocation d'un certificat racine.

Étapes de validation du certificat de serveur

Lors de la validation du certificat de serveur pendant la TLS authentifiée pour le backend ou l'authentification du backend, l'équilibreur de charge effectue les opérations suivantes :

  1. Vérifiez que le serveur possède la clé privée du certificat.

    Le serveur prouve qu'il possède la clé privée associée au certificat qu'il présente à l'équilibreur de charge en signant une information à l'aide de sa clé privée et en l'envoyant à l'équilibreur de charge dans le message CertificateVerify. L'équilibreur de charge valide ensuite cette signature à l'aide de la clé publique du certificat du serveur. Si la validation de la signature échoue, cela indique que le serveur backend ne possède pas la clé privée correspondant au certificat. Dans ce cas, l'équilibreur de charge met fin au handshake TLS sans enregistrer d'erreur.

  2. Vérifiez la chaîne de confiance.

    Si la configuration de confiance inclut au moins une ancre de confiance ou si l'attribut wellKnownRoots est défini sur PUBLIC_ROOTS, l'équilibreur de charge tente de valider une chaîne de confiance entre le certificat de serveur et l'ancre de confiance configurée. Les vérifications incluent les éléments suivants :

    • Le certificat de serveur du backend, les certificats intermédiaires (le cas échéant) et le certificat racine configuré sont conformes aux exigences relatives aux certificats.
    • Pour tous les certificats de la chaîne de confiance, le champ "Objet" du certificat parent correspond au champ "Émetteur" du certificat enfant. Cette vérification permet de s'assurer que l'identité (sujet) du certificat parent est la même que celle indiquée comme émetteur dans le certificat enfant.
    • Pour tous les certificats de la chaîne de confiance, 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 la bonne autorité racine et qu'il peut être considéré comme fiable, car la clé publique de la racine est référencée dans l'AKID pour vérifier la validité du certificat.

  3. Établissez une connexion avec le backend.

    Si la validation du certificat réussit, l'équilibreur de charge poursuit la connexion au backend.

    Toutefois, si la validation du certificat échoue, l'équilibreur de charge met fin à la connexion au backend, envoie un code d'état HTTP 502 au client et enregistre la raison de l'arrêt dans Cloud Logging. En cas d'erreur de validation du certificat, les requêtes entrantes ultérieures déclenchent la réinitialisation de la connexion au backend par l'équilibreur de charge.

    La connexion au backend peut également échouer si le serveur backend refuse la connexion. Avec l'authentification mTLS du backend, cela peut se produire si le certificat client est considéré comme non valide. Lorsque la connexion au backend échoue, l'équilibreur de charge répond aux requêtes proxy avec un code d'état HTTP 502 et enregistre une raison d'erreur générique dans Cloud Logging.

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 de serveur, 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 façon dont elles sont consignées.

Si la validation du certificat du serveur échoue, 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 serveur Erreur consignée
La chaîne de certificats du serveur est trop longue (plus de 10 certificats intermédiaires inclus dans le certificat du serveur). server_cert_chain_exceeded_limit

La taille d'une clé RSA d'un serveur 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.

 server_cert_invalid_rsa_key_size

Un serveur 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.

 server_cert_unsupported_elliptic_curve_key

Un serveur ou un certificat intermédiaire utilise un algorithme non RSA ou ECEC.

Aucune validation n'est effectuée.

 server_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.

 server_cert_pki_too_large

Un certificat intermédiaire fourni pour la validation comportait plus de 10 contraintes de nom.

server_cert_chain_max_name_constraints_exceeded

Le certificat du serveur comporte un champ d'extension Extended Key Usage (EKU), mais ce champ n'inclut pas serverAuth.

server_cert_chain_invalid_eku
Le délai avant expiration est dépassé lors de la tentative de validation de la chaîne de certificats. server_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 de serveur. Le nombre maximal d'itérations est de 100 (certificats examinés pour valider la chaîne de certificats du serveur).

 server_cert_validation_search_limit_exceeded

Vous avez configuré mTLS sans configurer de ressource TrustConfig.

 server_cert_validation_not_performed

Le serveur n'a pas fourni le certificat demandé lors du handshake.

 server_cert_not_provided

La validation du certificat de serveur a échoué avec la ressource TrustConfig.

 ssl_certificate_verification_failed

Le service ne peut pas effectuer la validation de la chaîne de certificats.

 server_cert_validation_unavailable
Erreur interne de validation de la chaîne de certificats. server_cert_validation_internal_error

Correspondance TrustConfig introuvable.

 server_cert_trust_config_not_found
La charge utile du certificat de serveur (y compris les certificats intermédiaires) est trop volumineuse (plus de 16 Ko). server_cert_exceeded_size_limit

Limites

  • La TLS authentifiée et la mTLS mutuelle pour le backend ne peuvent être configurées que pour les équilibreurs de charge d'application externes globaux. Les équilibreurs de charge d'application classiques ne sont pas compatibles avec l'authentification TLS du backend ni avec mTLS du backend.

  • La TLS authentifiée et la mTLS pour le backend ne sont pas compatibles avec les types de backend suivants :

    • Backends NEG Internet globaux

    • Backends App Engine

  • Pour activer le mTLS de backend, vous devez également configurer le TLS authentifié de backend.

  • Si vous souhaitez activer le mTLS de backend, vous devez créer le certificat client avant de configurer la ressource de configuration d'authentification de backend.

  • Les vérifications de l'état utilisées par les backends n'implémentent pas les fonctionnalités d'authentification TLS ni mTLS. Vous devez configurer les backends avec des points de terminaison de vérification de l'état;état pouvant répondre aux requêtes HTTP ou HTTPS.

  • L'équilibreur de charge ne transmet pas le nom d'hôte SNI du client à partir de la connexion TLS du frontend lorsqu'il se connecte à un backend. Toutefois, les backends peuvent accéder au nom d'hôte SNI du client à l'aide d'un en-tête de requête personnalisé.

  • Pour le mTLS de backend, les clés de certificat client sont limitées aux éléments suivants :

    • Les clés RSA peuvent aller de 2 048 à 4 096 bits.
    • Les clés ECDSA peuvent utiliser les courbes P-256 ou P-384.

  • La TLS authentifiée pour le backend n'est pas compatible avec les vérifications de révocation de certificat.

Quotas et limites

  • Un même magasin de confiance peut contenir jusqu'à 200 ancres de confiance et certificats intermédiaires combinés, avec une limite distincte de 100 certificats intermédiaires. Pas plus de trois certificats intermédiaires peuvent partager les mêmes informations "Objet" et "Clé publique de l'objet".

  • La profondeur maximale d'une chaîne de certificats est de 10 certificats, y compris les certificats racine et feuille. Le nombre maximal de certificats intermédiaires pouvant être évalués lors de la tentative de création de la chaîne de confiance est de 100.

  • La TLS authentifiée pour le backend limite la chaîne de certificats reçue du backend à 16 Ko et à 10 certificats.

  • Les certificats racines utilisés pour la validation ne peuvent pas contenir plus de 10 contraintes de nom.

  • Le nombre maximal d'autres noms d'objet autorisés dans le champ tlsSettings.subjectAltNames[] est de cinq.

Étapes suivantes