Inspection TLS est utilisé pour détecter et empêcher les menaces avancées sur des canaux TLS chiffrés. La fonctionnalité Inspection TLS déchiffre de manière transparente le trafic chiffré et le rend disponible pour des fonctionnalités de sécurité avancées, telles qu'IDS/IPS, la protection contre les programmes malveillants et le filtrage d'URL. Cela fournit une visibilité du trafic chiffré sans déchargement, tout en conservant le chiffrement de bout en bout.

Sans l'inspection TLS, même si vous activez toutes les fonctionnalités de sécurité avancées pour le pare-feu de passerelle, vous ne pouvez pas appliquer ou avoir une visibilité du trafic chiffré qui peut avoir masqué des programmes malveillants dans les paquets. Le déchiffrement TLS permet aux administrateurs de disposer d'un contrôle d'accès, et d'une détection et d'une prévention des menaces plus efficaces dans le trafic chiffré.

Attention : Cette fonctionnalité est disponible en mode aperçu tech. Pour plus d'informations sur les fonctionnalités de l'aperçu tech, reportez-vous aux Notes de mise à jour de NSX-T Data Center.
  • Prise en charge de l'inspection TLS
  • Concepts d'inspection TLS
  • Stratégies d'inspection TLS
  • Création de profils d'action de déchiffrement TLS
  • Gestion des certificats d'inspection TLS

Prise en charge de l'inspection TLS

Cette rubrique décrit la prise en charge de la fonctionnalité Inspection TLS dans NSX-T Data Center.

La prise en charge de l'inspection TLS inclut :

  • Prise en charge sur les passerelles de niveau 1 uniquement.
  • TLS version 1.0 jusqu'à 1.2 est pris en charge. TLS 1.2 avec PFS (Perfect Forward Secrecy) est pris en charge. Si la version 1.3 est utilisée, le proxy NSX négocie avec une version antérieure et établit une connexion.
  • Utilisation de l'indication du nom du serveur (SNI) TLS dans le message Client Hello de TLS pour classer le trafic.
  • Visibilité du trafic chiffré sans déchargement tout en conservant le chiffrement de bout en bout.
  • Déchiffrement TLS sur les pare-feu de passerelle pour intercepter le trafic et le déchiffrer pour le flux vers les fonctionnalités avancées de sécurité du pare-feu.
  • Stratégies d'Inspection TLS pour créer un ensemble de règles qui décrivent les conditions à faire correspondre et effectuer une action prédéfinie.
  • Les règles de stratégie d'inspection TLS prennent en charge le contournement, les profils d'action de déchiffrement externe et interne.

Concepts de Inspection TLS

Inspection TLS détecte et empêche les menaces avancées dans votre réseau via des canaux TLS chiffrés. Cette rubrique inclut les concepts associés aux fonctionnalités Inspection TLS.

Protocole TLS

Cette rubrique décrit le fonctionnement de l'établissement de liaison du protocole TLS pour établir un canal chiffré entre le client et le serveur. L'illustration du protocole TLS suivante présente les différentes étapes impliquées pour former un canal chiffré.
Figure 1. Protocole TLS
Établissement d'une liaison TLS en trois temps
Pour résumer le protocole TLS :
  • TLS lance une session TLS sur une session TCP établie entre le client et le serveur (également appelée établissement d'une liaison TLS en trois temps).
  • Le client envoie un message Client Hello qui inclut la version et le chiffrement TLS pris en charge, ainsi que l'extension SNI (Server Name Indication, Indication du nom du serveur). Inspection TLS utilise la SNI dans le message Client Hello de TLS pour classer le trafic à l'aide du profil de contexte afin d'utiliser les profils de déchiffrement internes, externes ou de contournement.
  • Le serveur répond avec le certificat de serveur pour l'authentification et l'identification, et un message Server Hello avec la version et le chiffrement proposés par le client.
  • Une fois que le client valide le certificat et vérifie la version finale et le chiffrement, il génère une clé de session symétrique et l'envoie au serveur.
  • Pour initier le tunnel TLS sécurisé qui échange des données d'application sur le canal TLS chiffré, le serveur valide la clé de session et envoie le message terminé.

Par défaut, le protocole TLS ne montre que l'identité du serveur au client à l'aide du certificat X.509 et l'authentification du client sur le serveur incombe à la couche d'application.

Types de déchiffrement TLS

La fonctionnalité Inspection TLS permet aux utilisateurs de définir des stratégies pour déchiffrer ou contourner le déchiffrement. La fonctionnalité d'inspection TLS permet deux types de déchiffrement :
  • Déchiffrement TLS interne : pour le trafic allant vers un service interne d'entreprise dans lequel vous possédez le service, le certificat et la clé privée. Il est également appelé proxy inverse TLS ou déchiffrement entrant.
  • Déchiffrement TLS externe : pour le trafic allant vers un service externe (Internet) dans lequel l'entreprise ne possède pas le service, son certificat et la clé privée. Il est également appelé proxy de transfert TLS ou déchiffrement sortant.
Le diagramme suivant décrit comment le trafic est géré par les types de déchiffrement TLS interne et externe.
Figure 2. Types de déchiffrement TLS NSX
Déchiffrement TLS du pare-feu de passerelle NSX de types interne et externe
Le diagramme et le tableau suivants expliquent le fonctionnement du déchiffrement externe TLS de NSX avec NSX.
Figure 3. Fonctionnement du déchiffrement externe
Workflow de déchiffrement externe pour l'inspection TLS
Légende Workflow
1 La SNI du message Hello Client de TLS correspond au profil de contexte de stratégie Inspection TLS.
2 NSX intercepte la session TLS à partir du client et initie une nouvelle session sur le serveur prévu.
3 NSX applique la version et le chiffrement TLS (configurables).
4 Le serveur répond au client avec un certificat TLS
5 NSX valide le certificat de serveur à l'aide du bundle d'autorité de certification approuvée et génère dynamiquement un certificat d'autorité de certification de proxy et le présente au client.

Le diagramme et le tableau suivants expliquent le fonctionnement du déchiffrement interne TLS de NSX avec NSX.

Figure 4. Fonctionnement du déchiffrement interne
Workflow de déchiffrement externe pour l'inspection TLS
Légende Workflow
1 La SNI du message Client Hello de TLS correspond au profil de contexte de stratégie d'inspection TLS configuré pour le domaine interne.
2 NSX intercepte la session TLS à partir du client et initie une nouvelle session sur le serveur prévu.
3 NSX applique la version/le chiffrement TLS (configurables).
4 Le serveur répond avec le certificat dans le cadre de l'établissement d'une liaison TLS (validation facultative).
5 NSX présente au client le certificat du serveur, qui a été chargé dans le cadre de la configuration.

Stratégies d'inspection TLS

Une stratégie d'inspection TLS s'applique à un ou plusieurs pare-feu de passerelle de niveau 1 sélectionnés. La première fois que vous ajoutez une stratégie d'inspection TLS, vous pouvez utiliser l'assistant ou configurer manuellement la stratégie et les règles associées. Cette rubrique décrit les concepts et la création de stratégies d'inspection TLS.

L'inspection TLS NSX fournit les trois catégories suivantes pour faciliter la gestion des stratégies. À l'instar des catégories de pare-feu de passerelle, vous pouvez utiliser n'importe quelle catégorie en fonction de la condition requise pour définir des stratégies d'inspection TLS.
  • Règles préalables : définit la stratégie pour plusieurs passerelles.
  • Passerelle locale : définit des stratégies spécifiques.
  • Par défaut (règles postérieures) : cette catégorie TLS par défaut est différente des règles de la stratégie de passerelle, car elle ne contient aucune règle ni stratégie par défaut prêt à l'emploi. Elle vous permet également de définir des règles postérieures dans la catégorie Par défaut (qui n'est pas disponible dans le tableau de pare-feu de passerelle). Par exemple, l'ajout de stratégies communes à plusieurs passerelles après la configuration de la passerelle locale peut constituer un cas d'utilisation.

Créer une stratégie d'inspection TLS

Pour simplifier la configuration de la première stratégie d'inspection TLS, vous pouvez utiliser l'assistant Inspection TLS ou créer manuellement votre stratégie à l'aide de l'interface utilisateur. Cette rubrique ne décrit pas la configuration de l'assistant, mais uniquement les étapes de configuration manuelle.

L'assistant fournit une démonstration du workflow de configuration de l'inspection TLS pour vos pare-feu de passerelle de niveau 1. L'assistant s'affiche sur la page d'accueil de l'inspection TLS uniquement pour la première stratégie, mais vous pouvez accéder à l'assistant dans les onglets Toutes les règles partagées et Règles spécifiques à la passerelle. Vous pouvez ignorer l'assistant de configuration et terminer la création de stratégie et la configuration manuelle du profil d'action de déchiffrement en cliquant sur Ignorer sur la page d'ouverture.

Conditions préalables

Ces conditions préalables sont valides pour les stratégies d'inspection TLS.

Activez les paramètres suivants. Par défaut, ils sont désactivés.
  • Activation des paramètres d'inspection TLS par passerelle.

    Accédez à Sécurité > Inspection TLS et sélectionnez l'onglet Paramètres. Sélectionnez une ou plusieurs passerelles dans la liste des passerelles compatibles TLS et cliquez sur Activer.

  • Activation de la base de données d'URL sur le cluster Edge.

    Accédez à Sécurité > Paramètres généraux > Base de données d'URL. Les nœuds Edge doivent disposer d'une connectivité Internet afin que le service NSX Threat Intelligence Cloud (NTICS) puisse effectuer des téléchargements de base de données d'URL.

  • Pour afficher les statistiques d'inspection TLS à l'aide du tableau de bord Sécurité, déployez NSX Application Platform sur votre environnement NSX-T Data Center 3.2 ou version ultérieure et assurez-vous qu'il est dans un état correct. Une licence spécifique est requise pour la surveillance de séries chronologiques. Pour plus d'informations, reportez-vous au guide Déploiement et gestion de NSX Application Platform et à la section Surveillance des statistiques de sécurité.

Procédure

  1. Avec des privilèges d'administrateur, connectez-vous à NSX Manager.
  2. Sélectionnez Sécurité > Inspection TLS.
  3. Sélectionnez la catégorie pour définir la stratégie, puis cliquez sur Ajouter une stratégie.
  4. Entrez un nom pour la nouvelle stratégie.
  5. (Facultatif) Si vous souhaitez empêcher plusieurs utilisateurs d'apporter des modifications à la section, cliquez sur l'icône Configuration avancée, puis cliquez sur Verrouillé et Appliquer.
  6. Sélectionnez la stratégie que vous avez créée et cliquez sur Ajouter une règle.
    Variable Description
    Services sources, de destination et L4 Correspond aux mêmes champs du trafic entrant que la règle de pare-feu de passerelle.
    Profil de contexte Définissez et sélectionnez un profil de contexte pour classer le trafic en fonction de la catégorie d'URL, de la réputation et du nom de domaine. Pour plus de détails, reportez-vous à la section Profils de contexte.
    Profil d'action de déchiffrement Définissez et sélectionnez le profil de déchiffrement pour le trafic correspondant. Il peut s'agir de profils externes, internes et de contournement. Pour plus d'informations, reportez-vous à la section Création de profils d'action de déchiffrement TLS.
    Appliqué à Sélectionnez une ou plusieurs passerelles de niveau 1.
  7. Cliquez sur Publier.
    Vous avez terminé la création de votre stratégie.

Création de profils d'action de déchiffrement TLS

Vous pouvez créer trois types de profils d'action de déchiffrement dans Inspection TLS. Cette rubrique décrit les profils et comment les utiliser.

Les profils d'action de déchiffrement sont les suivants :
  • Profils de contournement de déchiffrement : ce profil est utilisé pour contourner le déchiffrement du trafic destiné à des catégories spécifiques de sites Web, pour des raisons de conformité et de confidentialité. Par exemple, les sites Web de santé et financiers. Le profil de contournement ne peut pas être modifié.
  • Profils de déchiffrement externes : ces profils sont destinés aux connexions TLS destinées à un service non détenu par l'entreprise. Par exemple, http://merriam-webster.com. En général, les sites Web Internet.
  • Profils de déchiffrement internes : ces profils sont destinés aux connexions TLS destinées à un service détenu par l'entreprise elle-même. Par exemple, http://www.corp.internal.com.
Pour savoir comment créer des profils d'action de déchiffrement TLS, reportez-vous aux rubriques suivantes :
  • Créer un profil de déchiffrement externe
  • Créer un profil d'action de déchiffrement interne
  • Créer un profil d'action de contournement du déchiffrement

Créer un profil de déchiffrement externe

Cette rubrique fournit les étapes de configuration manuelle d'un profil d'action de déchiffrement externe.

Conditions préalables

  • Assurez-vous de disposer du rôle d'utilisateur et des autorisations appropriés pour configurer l'inspection TLS.
  • Assurez-vous de disposer d'une autorité de certification de proxy approuvée et d'une autorité de certification de proxy non approuvée, importées ou prêtes à être importées, ou de disposer des informations associées pour générer un certificat.

Procédure

  1. Avec des privilèges d'administrateur, connectez-vous à NSX Manager.
  2. Accédez à Sécurité > Inspection TLS > Profils.
  3. Cliquez sur Ajouter un profil d'action de déchiffrement > déchiffrement externe.
  4. Entrez un nom pour le nouveau profil.
  5. (Facultatif) Sélectionnez un paramètre de profil : Équilibré (par défaut), Haute fidélité, Haute sécurité ou utilisez Personnalisé pour modifier les sous-paramètres.
    Paramètre du profil Description
    Certificats non valides : Autoriser ou Bloquer et journaliser Définissez des règles pour autoriser ou bloquer le trafic lorsqu'un certificat non valide est présenté par le serveur. Si Autoriser est sélectionné et que le serveur présente un certificat expiré ou non approuvé, ce choix permet à la connexion de continuer en envoyant un certificat de proxy non approuvé au client.
    Échec de déchiffrement : Contourner et journaliser ou Bloquer et journaliser Définit ce qu'il faut faire en cas d'échec de déchiffrement qui peut être dû à mTLS (authentification TLS mutuelle) ou à l'épinglage de certificat en cours d'utilisation. Si Contourner et journaliser est sélectionné, NSX met en cache ce domaine et toutes les connexions suivantes au domaine sont contournées.
    Application du chiffrement : transparent ou appliquer Définit les versions TLS et les suites de chiffrement minimales et maximales pour le client et le serveur. Vous pouvez contourner ce paramètre à l'aide de l'option Transparent.
  6. (Facultatif) Modifiez le délai d'expiration de la connexion. Il s'agit de la durée en secondes pendant laquelle le serveur peut rester inactif après l'établissement d'une connexion TCP. La valeur par défaut est 5 400 secondes. Maintenez ce délai d'expiration inférieur aux paramètres de délai d'inactivité du pare-feu de passerelle.
  7. (Facultatif) Sélectionnez les paramètres d'autorité de certification approuvée pour sélectionner Bundle d'autorité de certification approuvé, Listes de révocation de certificats (CRL) et l'option d'association OCSP.
    Option Description
    Bundle d'autorité de certification approuvé Valide le certificat que le service externe présente à NSX. Vous pouvez utiliser le bundle d'autorité de certification approuvé par défaut ou importer un nouveau bundle d'autorité de certification, puis choisir plusieurs bundles par profil si nécessaire. Ce bundle n'est pas automatiquement mis à jour. Vous devez donc le mettre à jour si nécessaire. Pour plus d'informations, reportez-vous à la section Importer ou mettre à jour un bundle d'autorité de certification approuvée sous Gestion des certificats.
    CRL NSX inclut également une liste de révocation de certificat (CRL) pour valider le certificat présenté par le serveur. Vous pouvez utiliser la liste de révocation des certificats par défaut ou en importer une nouvelle, puis choisir plusieurs listes de révocation de certificats par profil si nécessaire. Cette liste de révocation des certificats n'est pas automatiquement mise à jour. Vous devez donc la mettre à jour si nécessaire. Pour plus d'informations, reportez-vous à la section Importation et récupération de listes de révocation de certificats sous Gestion des certificats.
    Exiger l'association OCSP Pour appliquer l'association OSCP pour le certificat de serveur présenté. Dans l'association OCSP, le serveur propriétaire du certificat interroge le répondeur OCSP et inclut la réponse OCSP horodatée et signée reçue en tant qu'extension CertificateStatusRequest, ainsi que son certificat. Si le serveur dispose d'un certificat chaîné, il doit également effectuer l'association OCSP pour tous les certificats d'autorité de certification intermédiaires.
  8. Pour importer ou générer une autorité de certification de proxy approuvée ou non approuvée, sélectionnez la liste déroulante Autorité de certification de proxy, sélectionnez l'onglet Autorité de certification du proxy approuvée ou Autorité de certification du proxy non approuvé, puis effectuez l'une des opérations suivantes :
    • Sélectionnez Importer > Certificat d'autorité de certification.
    • Sélectionnez Générer > Certificat d'autorité de certification auto-signé.

      Entrez les informations requises et cliquez sur Enregistrer. Pour plus de détails sur l'importation d'autorités de certification approuvées, reportez-vous à la section Importation et remplacement de certificats.

  9. Pour enregistrer le profil, qui peut ensuite être utilisé pour les stratégies d'inspection TLS, sélectionnez Enregistrer.

Résultats

Vous pouvez désormais utiliser le profil d'action de déchiffrement pour configurer des règles de déchiffrement externes sur vos passerelles de niveau 1.

Que faire ensuite

Créez des stratégies et des règles de déchiffrement externes d'Inspection TLS.

Créer un profil d'action de déchiffrement interne

Cette rubrique fournit les étapes de configuration manuelle d'un profil d'action de déchiffrement interne.

Conditions préalables

  • Assurez-vous de disposer du rôle d'utilisateur et des autorisations appropriés pour configurer l'inspection TLS.
  • Assurez-vous de disposer d'un certificat de serveur interne importé ou prêt à être importé ou de disposer des informations associées pour générer le certificat.

Procédure

  1. Avec des privilèges d'administrateur, connectez-vous à NSX Manager.
  2. Sélectionnez Sécurité > Inspection TLS > Profils.
  3. Cliquez sur Ajouter un profil d'action de déchiffrement > Déchiffrement interne.
  4. Entrez un nom pour la nouvelle stratégie.
  5. (Facultatif) Sélectionnez un paramètre de profil : Équilibré (par défaut), Haute fidélité, Haute sécurité ou utilisez Personnalisé pour modifier les sous-paramètres.
    Paramètre du profil Description
    Échec de déchiffrement : Contourner et journaliser ou Bloquer et journaliser Définit ce qu'il faut faire en cas d'échec de déchiffrement qui peut être dû à mTLS (authentification TLS mutuelle) ou à l'épinglage de certificat en cours d'utilisation. Si vous sélectionnez Contourner et journaliser, NSX met en cache ce domaine et toutes les connexions suivantes au domaine sont contournées.
    Application du chiffrement : transparent ou appliquer Définit les versions TLS et les suites de chiffrement minimales et maximales pour le client et le serveur. Vous pouvez contourner ce paramètre à l'aide de l'option Transparent.
  6. (Facultatif) Modifiez le délai d'expiration de la connexion. Il s'agit de la durée en secondes pendant laquelle le serveur peut rester inactif après l'établissement d'une connexion TCP. La valeur par défaut est 5 400 secondes. Maintenez ce délai d'expiration inférieur aux paramètres de délai d'inactivité du pare-feu de passerelle.
  7. Développez la section Certificats et clés de serveur et configurez un ou plusieurs certificats de serveur internes.
    1. Importez un certificat ou un certificat d'autorité de certification (CA). Reportez-vous à la section Importer un certificat auto-signé ou signé par une autorité de certification.
    2. Générez un certificat auto-signé ou un certificat d'autorité de certification auto-signé.
    3. Sélectionnez un certificat de serveur existant en cochant la case située à l'avant de la ligne.
    4. Définissez un certificat de serveur existant par défaut en cliquant sur le bouton radio Par défaut à la fin de la ligne.

    Si l'extension SNI n'est pas présente dans le client hello, le certificat de serveur par défaut est présenté au client. Si cette option n'est pas configurée, le proxy TLS n'intercepte pas les connexions qui ne contiennent aucune extension SNI dans le client hello. Si l'extension SNI est présente dans le client hello, mais qu'il n'existe aucun certificat correspondant pour cette extension dans la liste des certificats configurés, le proxy TLS n'intercepte pas ces connexions.

    Lorsqu'un client accède à l'un de ces services internes, le proxy TLS présente ce certificat sélectionné en fonction du domaine du serveur correspondant au champ Émis pour le champ (nom commun).

    Si plusieurs certificats de serveur sont configurés, ils doivent tous avoir des domaines différents, spécifiés par Nom commun (CN) ou Autre nom du sujet (SAN). Deux certificats ne peuvent pas être configurés pour le même domaine, qu'il s'agisse d'un nom de domaine complet (par exemple, www.vmware.com) ou d'un caractère générique (*.vmware.com). Cependant, les certificats avec des domaines génériques qui chevauchent des certificats de nom de domaine complet spécifiques sont autorisés. Dans ce cas, des certificats plus spécifiques sont préférés aux certificats génériques lors de la sélection d'un certificat à présenter au client en fonction de l'extension SNI dans le client hello, .

  8. (Facultatif) Par défaut, la validation du certificat de serveur est facultative et désactivée. Il n'est pas nécessaire de configurer cette option s'il s'agit d'un service appartenant à l'entreprise. Si vous souhaitez appliquer cette validation, activez la validation du certificat de serveur en la basculant sur Activé.
    1. Développez la section et configurez vos options de validation. Vous pouvez choisir le bundle d'autorité de certification approuvé par défaut et la liste de révocation des certificats ou les importer.
    2. Cliquez sur Enregistrer.

Résultats

Vous pouvez désormais utiliser le profil d'action de déchiffrement interne pour configurer des stratégies et des règles d'inspection TLS sur vos passerelles de niveau 1.

Que faire ensuite

Créez des stratégies et des règles de déchiffrement internes d'inspection TLS.

Créer un profil d'action de contournement du déchiffrement

Cette rubrique fournit des détails sur le profil d'action de contournement du déchiffrement.

Conditions préalables

Les politiques de confidentialité de vos administrations locales et d'entreprise peuvent interdire le déchiffrement de certains contenus. Par exemple, lorsque le client accède à un site Web financier ou site Web d'un fournisseur de santé, des lois peuvent interdire l'interception et le déchiffrement de ce trafic.

Pour faciliter la configuration, NSX inclut un profil de contexte prédéfini, default-bypass-highfidelity-profile, afin de répondre à ces exigences. NSX utilise des profils de contexte pour faire correspondre des URL de domaine à ignorer ou à contourner à partir du déchiffrement. Le profil par défaut inclut les catégories d'URL : santé et finances.

Dans cette version, vous ne pouvez pas créer de profils d'action de contournement du déchiffrement ni modifier le profil par défaut. Le profil par défaut est paramétré comme suit :
Paramètre du profil Description
Certificats non valides : autoriser Définir sur Autoriser : si le serveur présente un certificat expiré ou non approuvé, ce choix permet à la connexion de continuer.
Application du chiffrement : transparent Défini sur transparent : aucune application de chiffrement ou de version TLS ne se produit si l'URL correspond à la règle de profil de contournement du déchiffrement.

Gestion des certificats d'inspection TLS

Un certificat de sécurité est requis pour Inspection TLS sur NSX-T Data Center. Pour intercepter, déchiffrer et chiffrer le trafic pour Inspection TLS et d'autres applications de sécurité avancées, vous devez préparer le proxy TLS afin qu'il puisse agir comme un proxy transparent pour les connexions TLS. NSX Manager nécessite ces certificats pour établir une approbation entre les applications.

La gestion des certificats prend en charge les options suivantes pour l'inspection TLS.
  • Importation d'un certificat existant ou génération d'une CSR auto-signée ou auto-signée par une autorité de certification (demande de signature de certificat).
  • Exportation d'un certificat existant.
  • Importation ou mise à jour d'un bundle d'autorité de certification approuvée par défaut.
  • Importation ou mise à jour d'une liste de révocation des certificats (CRL) publics par défaut.
  • Filtrage avancé sur toutes les options de filtre prédéfinies.
  • Bannière de certificat expiré sur la page Certificats.
  • Notification de certificats valides ou non valides avec un code couleur.

Pour plus d'informations sur les options de déploiement, reportez-vous au Certificats.

Le proxy TLS nécessite un certificat d'autorité de certification, également appelé autorité de certification de proxy. NSX Manager utilise l'autorité de certification de proxy pour générer des certificats qui empruntent l'identité des points de terminaison dans la connexion interceptée. En d'autres termes, il permet d'usurper les certificats pour le trafic intercepté sur les serveurs de sites Web. Vous pouvez choisir l'un des deux types de certificats d'autorité de certification de proxy :

Pour générer des certificats qui empruntent l'identité des points de terminaison dans la connexion interceptée, le proxy TLS nécessite un certificat d'autorité de certification, également appelé autorité de certification de proxy. NSX Manager utilise l'autorité de certification de proxy. En d'autres termes, il permet d'usurper. Vous pouvez choisir l'un des deux types de certificats d'autorité de certification de proxy :
  • Les certificats auto-signés sont généralement utilisés pour les tests ou les déploiements limités non approuvés. Ce workflow commence par une demande à NSX Manager de générer une paire de clés de certificat d'autorité de certification avec une demande de signature de certificat (CSR). Il demande ensuite à NSX manager d'auto-signer la CSR.
  • Une autorité de certification émettrice d'entreprise signe des certificats d'autorité de certification subordonnée approuvés. Ce workflow commence par une demande à NSX Manager de générer une paire de clés de certificat d'autorité de certification avec une CSR, de télécharger celle-ci, puis de l'envoyer à l'autorité de certification émettrice, ce qui entraîne la réception d'un certificat signé. Il charge ensuite le certificat d'autorité de certification public signé vers NSX Manager. Le chargement peut inclure une chaîne de certificats. Les chaînes de certificats sont des certificats de signature intermédiaires entre le nouveau certificat et le certificat d'autorité de certification racine.

Il existe plusieurs façons de charger un nouveau certificat d'autorité de certification dans NSX manager : utilisez l'assistant TLS dans l'interface utilisateur, ajoutez manuellement le certificat dans l'interface utilisateur ou utilisez NSX API. Pour plus de détails, reportez-vous à la section Importer un certificat d'autorité de certification.

Bundles d'autorité de certification approuvée

Après la configuration, ces certificats d'autorité de certification sont distribués aux nœuds exécutant le proxy TLS. Vous pouvez charger plusieurs bundles de certificat d'autorité de certification avec des noms différents. Chaque bundle d'autorité de certification utilisé par le proxy TLS est configuré dans le profil d'action de déchiffrement. Lors du chargement, le bundle d'autorité de certification est validé en tant que concaténation bien formée de certificats codés en PEM et n'est pas stocké s'il n'est pas valide. Si un bundle n'est pas valide, il renvoie des messages d'erreur d'API.

Un seul bundle est limité à une taille de 1 Mo et à 1 000 certificats.

Liste de révocation de certificats

Pour vous assurer que les certificats fournis par les points de terminaison de la connexion interceptée ne sont pas révoqués, vous pouvez utiliser la CRL du proxy TLS, default_public_crl. Vous pouvez mettre à jour cet objet en chargeant une nouvelle CRL pour remplacer l'actuelle. Vous pouvez l'utiliser dans des profils de stratégie. Pour charger une nouvelle CRL vers NSX Manager, utilisez l'interface utilisateur ou l'API. La CRL est distribuée aux nœuds exécutant le proxy TLS. L'API valide la CRL lors du chargement et refuse de la stocker si elle n'est pas valide. NSX prend en charge deux formats de CRL :
  • CRL X.509 codé au format PEM : taille maximale de 40 Mo, 500 000 entrées
  • Mozilla OneCRL : taille maximale de 5 Mo, 10 000 entrées

Gestion des alarmes pour les certificats d'inspection TLS

Si vous ne conservez pas vos certificats d'autorité de certification de proxy et qu'ils sont sur le point d'expirer ou ont expiré ou que vous avez reçu un certificat d'autorité de certification expiré, NSX Manager utilise des alarmes pour vous en informer.

NSX déclenche le même ensemble d'alarmes pour les certificats arrivant à expiration ou expirés dans les bundles d'autorité de certification.

Vous pouvez également recevoir une erreur de serveur de journalisation distant en raison d'un certificat TLS non valide. L'erreur d'événement consignée est Log messages to logging server {hostname_or_ip_address_with_port}({entity_id}) cannot be delivered possibly due to an unresolvable FQDN, an invalid TLS certificate or missing NSX appliance iptables rule.. Pour vérifier que le certificat spécifié est valide, utilisez la commande openssl openssl x509 -in <cert-file-path> -noout -dates. Vous pouvez également afficher et mettre à jour les certificats dans l'interface utilisateur d'inspection TLS.

Pour plus d'informations sur l'expiration du certificat, reportez-vous à la section Notification d'alarme pour l'expiration du certificat. Pour plus d'informations sur les « événements de certificat » spécifiques à TLS à partir de NSX Manager, reportez-vous à la section Catalogue d'événements.