Renouvellement du certificat CA Sftunnel FMC pour la connectivité FTD

Introduction

Ce document décrit le renouvellement du certificat de l'autorité de certification (CA) sftunnel du Centre de gestion Firepower (FMC) en relation avec la connectivité FTD (Firepower Threat Defense).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Firepower Threat Defense 
• Centre de gestion Firepower
• Infrastructures à clé publique (PKI)

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

FMC et FTD communiquent entre eux via sftunnel (tunnel Sourcefire). Cette communication utilise des certificats pour sécuriser la conversation sur une session TLS. Plus d'informations sur le sftunnel et comment il s'établit peuvent être trouvées sur ce lien.

À partir de la capture de paquets, vous pouvez voir que le FMC (10.48.79.232 dans cet exemple) et le FTD (10.48.79.23) échangent des certificats entre eux. Ils le font afin de valider qu'ils parlent avec le bon appareil et qu'il n'y a pas d'écoute électronique ou d'attaque Man-In-The-Middle (MITM). La communication est chiffrée à l'aide de ces certificats et seule la partie qui a la clé privée associée pour ce certificat est en mesure de le déchiffrer à nouveau.

Certificat_exchange_server_cert

Certificat_change_client_cert

Vous pouvez voir que les certificats sont signés par la même autorité de certification (CA) interne (émetteur) qui est configurée sur le système FMC. La configuration est définie sur le FMC sur le fichier /etc/sf/sftunnel.conf qui contient quelque chose comme :

proxyssl {
  proxy_cert   /etc/sf/keys/sftunnel-cert.pem;                ---> Certificate provided by FMC to FTD for the sftunnel communication (signed by InternalCA)
  proxy_key    /etc/sf/keys/sftunnel-key.pem;
  proxy_cacert /etc/sf/ca_root/cacert.pem;                    ---> CA certificate (InternalCA)
  proxy_crl    /etc/sf/ca_root/crl.pem;
  proxy_cipher 1;
  proxy_tls_version TLSv1.2;
}; 

Indique l’autorité de certification utilisée pour signer tous les certificats pour sftunnel (à la fois le FTD et le FMC) et le certificat utilisé par le FMC pour envoyer à tous les FTD. Ce certificat est signé par l'autorité de certification interne.

Lorsque le FTD s'enregistre auprès du FMC, le FMC crée également un certificat à transmettre au périphérique FTD qui est utilisé pour la communication ultérieure sur le sftunnel. Ce certificat est également signé par le même certificat CA interne. Sur FMC, vous pouvez trouver ce certificat (et la clé privée) sous /var/sf/peers/<UUID-FTD-device> et potentiellement sous le dossier certs_push et est appelé sftunnel-cert.pem (sftunnel-key.pem pour la clé privée). Sur FTD, vous pouvez trouver ceux sous /var/sf/peers/<UUID-FMC-device> avec la même convention d'attribution de noms.

Cependant, chaque certificat a également une période de validité à des fins de sécurité. Lors de l'inspection du certificat InternalCA, nous pouvons également voir la période de validité qui est de 10 ans pour le FMC InternalCA comme indiqué dans la capture de paquets.

FMC-InternalCA_valid

Problème

Le certificat FMC InternalCA n'est valide que pour 10 ans. Après le délai d'expiration, le système distant ne fait plus confiance à ce certificat (ainsi qu'aux certificats signés par lui) et cela entraîne des problèmes de communication sftunnel entre les périphériques FTD et FMC. Cela signifie également que plusieurs fonctionnalités clés telles que les événements de connexion, les recherches de programmes malveillants, les règles basées sur l'identité, les déploiements de politiques et bien d'autres choses ne fonctionnent pas.

Les périphériques s'affichent comme désactivés sur l'interface utilisateur FMC sous l'onglet Périphériques > Gestion des périphériques lorsque le sftunnel n'est pas connecté. Le problème lié à cette expiration est suivi sur l'ID de bogue Cisco CSCwd08098. Notez bien que tous les systèmes sont affectés, même lorsque vous exécutez une version fixe du défaut. Vous trouverez plus d'informations sur ce correctif dans la section Solution.

Disabled-devices

Le FMC n’actualise pas automatiquement l’autorité de certification et ne republie pas les certificats sur les périphériques FTD. Et il n'y a pas non plus d'alerte d'intégrité FMC qui indique que le certificat expire. L'ID de bogue Cisco CSCwd08448 est suivi à cet égard pour fournir une alerte de santé sur l'interface utilisateur FMC à l'avenir.

Que se passe-t-il après la date de péremption ?

Au départ, rien ne se passe et les canaux de communication sftunnel continuent à fonctionner comme avant. Cependant, lorsque la communication sftunnel entre les périphériques FMC et FTD est interrompue et qu'il tente de rétablir la connexion, elle échoue et vous pouvez observer des lignes de journal sur le fichier journal des messages qui pointent vers l'expiration du certificat.

Lignes de journal du périphérique FTD de /ngfw/var/log/messages :

Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [INFO] Initiating IPv4 connection to 10.10.200.31:8305/tcp
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [INFO] Wait to connect to 8305 (IPv4): 10.10.200.31
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [INFO] Connected to 10.10.200.31 from resolved_ip_list (port 8305) (IPv4)
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR] -Error with certificate at depth: 1
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR]   issuer   = /title=InternalCA/OU=Intrusion Management System/CN=06f5f3ca-c77b-11e2-81bf-884d9d11f3ef/O=Sourcefire, Inc.
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR]   subject  = /title=InternalCA/OU=Intrusion Management System/CN=06f5f3ca-c77b-11e2-81bf-884d9d11f3ef/O=Sourcefire, Inc.
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR]   err 10:certificate has expired
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR] SSL_renegotiate error: 1: error:00000001:lib(0):func(0):reason(1)
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR] Connect:SSL handshake failed
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [WARN] SSL Verification status: certificate has expired

Lignes de journal du périphérique FMC à partir de /var/log/messages :

Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [INFO] VERIFY ssl_verify_callback_initial ok=1!
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] SSL_renegotiate error: 1: error:00000001:lib(0):func(0):reason(1)
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [WARN] establishConnectionUtil: SSL handshake failed
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [WARN] establishConnectionUtil: SSL Verification status: ok
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [WARN] establishConnectionUtil: SSL handshake failed: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [INFO] establishConnectionUtil: Failed to connect using SSL to: '10.10.21.10'
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] establishSSLConnection: Unable to connect with both threads:
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] establishSSLConnection: ret_accept status : Too many levels of symbolic links
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] establishSSLConnection: iret_connect status: Too many levels of symbolic links
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] establishSSLConnection: Failed connecting with SSL to using to: '10.10.21.10' rval[40] *CA cert from FMC

La communication sftunnel peut être interrompue pour diverses raisons :

• Perte de communication en raison d'une perte de connectivité réseau (éventuellement temporaire)
• Redémarrage de FTD ou FMC
  • Celles attendues : redémarrage manuel, mises à niveau, redémarrage manuel du processus sftunnel sur FMC ou FTD (par exemple par pmtool restartbyid sftunnel)
  • Des inattendues : tracebacks, coupure de courant

Étant donné le grand nombre de possibilités qui peuvent interrompre la communication sftunnel, il est fortement conseillé de corriger la situation le plus rapidement possible, même lorsque tous les périphériques FTD sont actuellement correctement connectés malgré l'expiration du certificat.

Comment vérifier rapidement si le certificat a expiré ou quand il expire ?

Le plus simple est d’exécuter ces commandes sur la session FMC SSH :

expert
sudo su
cd /etc/sf/ca_root
openssl x509 -dates -noout -in cacert.pem

Vous voyez ainsi les éléments Validité du certificat. La partie principale pertinente ici est le "notAfter" qui montre que le certificat ici est valable jusqu'au 5 octobre 2034.

NonAprès

Si vous préférez exécuter une seule commande qui vous donne immédiatement le nombre de jours pendant lesquels le certificat est toujours valide, vous pouvez utiliser ceci :

CERT_PATH="/etc/sf/ca_root/cacert.pem"; EXPIRY_DATE=$(openssl x509 -enddate -noout -in "$CERT_PATH" | cut -d= -f2); EXPIRY_DATE_SECONDS=$(date -d "$EXPIRY_DATE" +%s); CURRENT_DATE_SECONDS=$(date +%s); THIRTY_DAYS_SECONDS=$((30*24*60*60)); EXPIRY_THRESHOLD=$((CURRENT_DATE_SECONDS + THIRTY_DAYS_SECONDS)); DAYS_LEFT=$(( (EXPIRY_DATE_SECONDS - CURRENT_DATE_SECONDS) / (24*60*60) )); if [ "$EXPIRY_DATE_SECONDS" -le "$CURRENT_DATE_SECONDS" ]; then DAYS_EXPIRED=$(( (CURRENT_DATE_SECONDS - EXPIRY_DATE_SECONDS) / (24*60*60) )); echo -e "\nThe certificate has expired $DAYS_EXPIRED days ago.\nIn case the sftunnel communication with the FTD is not yet lost, you need to take action immediately in renewing the certificate.\n"; elif [ "$EXPIRY_DATE_SECONDS" -le "$EXPIRY_THRESHOLD" ]; then echo -e "\nThe certificate will expire within the next 30 days!\nIt is ONLY valid for $DAYS_LEFT more days.\nIt is recommended to take action in renewing the certificate as quickly as possible.\n"; else echo -e "\nThe certificate is valid for more than 30 days.\nIt is valid for $DAYS_LEFT more days.\nThere is no immediate need to perform action but this depends on how far the expiry date is in the future.\n"; fi

Un exemple de configuration où le certificat est encore valide pendant plusieurs années est affiché.

Certificate_expiry_validation_command

Comment être averti à l'avenir de l'expiration prochaine d'un certificat ?

Avec les mises à jour récentes de VDB (399 ou plus), vous êtes automatiquement alerté lorsque votre certificat expire dans les 90 jours. Par conséquent, vous n'avez pas besoin d'effectuer un suivi manuel vous-même, car vous êtes alerté lorsque vous approchez du délai d'expiration. Il apparaît ensuite sur la page Web de FMC sous deux formes. Les deux méthodes font référence à la page d'avis de champ.

La première méthode est via l'onglet Tâche. Ce message est rémanent et disponible pour l'utilisateur, sauf s'il est explicitement fermé. La fenêtre contextuelle de notification s'affiche également et est disponible jusqu'à ce que l'utilisateur la ferme explicitement. Il s'affiche toujours comme une erreur.

Notification d'expiration sur l'onglet Tâche

La deuxième méthode est via Health Alert. Cela apparaît dans l'onglet Health (Intégrité), mais cela n'est pas rémanent et remplace ou supprime lorsque le moniteur d'intégrité est exécuté, qui par défaut est toutes les 5 minutes. Il affiche également une fenêtre contextuelle de notification qui doit être explicitement fermée par l'utilisateur. Cela peut apparaître à la fois comme une erreur (lorsqu'il est arrivé à expiration) et comme un avertissement (lorsqu'il va expirer).

Notification d'expiration sur l'onglet Intégrité

Notification d'avertissement dans la fenêtre contextuelle Alerte d'intégrité

Notification d'erreur dans la fenêtre contextuelle Alerte d'intégrité

Solution 1 - Le certificat n'a pas encore expiré (scénario idéal)

C'est la meilleure situation car, selon l'expiration du certificat, nous avons encore le temps. Soit nous adoptons l'approche entièrement automatisée (recommandée) qui dépend de la version FMC, soit nous adoptons une approche plus manuelle qui nécessite l'intervention du TAC.

Approche recommandée

Il s'agit d'une situation dans laquelle aucun temps d'arrêt et un minimum d'opérations manuelles sont prévus dans des circonstances normales.

Avant de continuer, vous devez installer le correctif logiciel correspondant à votre version spécifique, comme indiqué ici. L'avantage ici est que ces correctifs ne nécessitent pas un redémarrage du FMC et donc une éventuelle rupture de la communication sftunnel lorsque le certificat a déjà expiré. Les correctifs disponibles sont les suivants :

• 7.0.0 - 7.0.6: Correctif FK - 7.0.6.99-9
• 7.1.x : pas de version fixe en fin de maintenance logicielle
• 7.2.0 - 7.2.9: Hotfix FZ - 7.2.9.99-4
• 7.3.x : HotFix AE - 7.3.1.99-4
• 7.4.0 - 7.4.2: Hotfix AO - 7.4.2.99-5
• 7.6.0 : Correctif B - 7.6.0.99-5

Une fois le correctif installé, le FMC contient maintenant le script generate_certs.pl qui :

1. Régénère la CA interne
2. Recrée les certificats sftunnel signés par cette nouvelle autorité de certification interne
3. Diffuse les nouveaux certificats sftunnel et les clés privées vers les périphériques FTD respectifs (quand le sftunnel est opérationnel)

Il est donc recommandé (si possible) de :

1. Installez le correctif logiciel correspondant à votre version de train
2. Effectuez une sauvegarde sur le FMC
3. Validez toutes les connexions sftunnel actuelles en utilisant le script sftunnel_status.pl sur le FMC (à partir du mode expert)
4. Exécutez le script en mode expert en utilisant generate_certs.pl
5. Examiner le résultat pour vérifier si des opérations manuelles sont nécessaires (lorsque les périphériques ne sont pas connectés au FMC) [expliqué plus loin]
6. Exécutez sftunnel_status.pl à partir du FMC pour valider que toutes les connexions sftunnel fonctionnent correctement

Script Generate_certs.pl

Dans l'exemple ici, vous voyez qu'il crée un fichier journal sur /var/log/sf/sfca_generation.log, indique d'utiliser sftunnel_status.pl, indique l'heure d'expiration sur l'InternalCA et indique pour toute défaillance sur elle. Ici, par exemple, il n'a pas réussi à transmettre les certificats au périphérique BSNS-1120-1 et au périphérique EMEA-FPR3110-08, ce qui est attendu parce que le sftunnel était désactivé pour ces périphériques.

Afin de corriger le sftunnel pour les connexions défaillantes, vous exécutez les étapes suivantes :

1. Sur l'interface de ligne de commande de FMC, ouvrez le fichier FAILED_PUSH en utilisant cat /var/tmp/certs/1728303362/FAILED_PUSH (la valeur du nombre représente l'heure unix, vérifiez donc le résultat de la commande précédente dans votre système) qui a le format suivant : FTD_UUID FTD_NAME FTD_IP SOURCE_PATH_ON_FMC DESTINATION_PATH_ON_FTD
   
   ECHEC_POUSSÉE
   
   
2. Transférez ces nouveaux certificats (cacert.pem / sftunnel-key.pem / sftunnel-cert.pem) du FMC vers les périphériques FTD
   ===Approche automatique===
   
   L'installation du correctif fournit également les scripts copy_sftunnel_certs.py et copy_sftunnel_certs_jumpserver.py qui automatisent le transfert des différents certificats vers les systèmes pour lesquels le sftunnel n'était pas activé pendant la régénération des certificats. Cela peut également être utilisé pour les systèmes qui avaient une connexion sftunnel interrompue parce que le certificat a déjà expiré.
   
   Vous pouvez utiliser le script copy_sftunnel_certs.py quand le FMC lui-même a un accès SSH aux différents systèmes FTD. Si ce n'est pas le cas, vous pouvez télécharger le script (/usr/local/sf/bin/copy_sftunnel_certs_jumpserver.py) du FMC vers un serveur de saut qui a un accès SSH à la fois aux FMC et aux périphériques FTD et exécuter le script Python à partir de là. Si cela n'est pas possible, suggérez d'exécuter l'approche manuelle indiquée ci-dessous. Les exemples suivants montrent le script copy_sftunnel_certs.py utilisé, mais les étapes sont les mêmes pour le script copy_sftunnel_certs_jumpserver.py.
   
   A. Créez un fichier CSV sur le FMC (ou serveur de saut) qui contient les informations de périphérique (nom_périphérique, adresse IP, nom_utilisateur_admin, mot_de_passe_admin) utilisées pour établir la connexion SSH.
   
   Lorsque vous exécutez ceci à partir d'un serveur distant comme un serveur de saut pour le FMC principal, assurez-vous d'ajouter dans les détails du FMC principal comme la première entrée suivie par tous les FTD gérés et FMC secondaire. Lorsque vous exécutez ceci à partir d'un serveur distant comme un serveur de saut pour le FMC secondaire, assurez-vous d'ajouter dans les détails du FMC secondaire comme première entrée suivie de tous les FTD gérés.
   
   i. Créez un fichier à l'aide de vi devices.csv.périphériques vi.csv
   
   ii. Cela ouvre le fichier vide (non affiché) et vous remplissez les détails comme indiqué après avoir utilisé i letter sur le clavier pour passer en mode INTERACTIF (vu en bas de l'écran).
   devices.csv, exemple
   
   iii. Une fois terminé, vous fermez et enregistrez le fichier en utilisant ESC suivi de :wq et puis Enter.
   Enregistrez les périphériques.csv
   
   B. Exécutez le script (à partir de la racine en utilisant sudo) avec copy_sftunnel_certs.py devices.csv et il vous montre le résultat. Ici, il montre que le certificat vers FTDv a été correctement envoyé et que pour BSNS-1120-1, il n'a pas pu établir la connexion SSH au périphérique.
   
   copy_sftunnel_certs.py devices.csv
   
   ===Approche manuelle===
   
   
   1. Imprimez (cat) la sortie de chacun des fichiers pour chaque FTD affecté (cacert.pem / sftunnel-key.pem (non affiché complètement à des fins de sécurité) / sftunnel-cert.pem) sur l'interface de ligne de commande FMC en copiant l'emplacement du fichier à partir de la sortie précédente (fichier FAILED_PUSH).
      
      cacert.pem
      sftunnel-key.pem
      sftunnel-cert.pem
   2. Ouvrez l'interface de ligne de commande FTD de chaque FTD respectif en mode expert avec les privilèges root via sudo su et renouvelez les certificats avec la procédure suivante.
      1. Accédez à l'emplacement affiché sur la surbrillance bleu clair de la sortie FAILED_PUSH (cd/var/sf/peers/cdb123c8-4347-11ef-aca1-f3aa241412a1 ici par exemple, mais ceci est différent pour chaque FTD).
      2. Effectuer des sauvegardes des fichiers existants.
         

         cp cacert.pem cacert.pem.backup
         cp sftunnel-cert.pem sftunnel-cert.pem.backup
         cp sftunnel-key.pem sftunnel-key.pem.backup​

         
         Effectuer des sauvegardes des certificats actuels
      3. Videz les fichiers afin que nous puissions y écrire du nouveau contenu.
         

         > cacert.pem
         > sftunnel-cert.pem
         > sftunnel-key.pem​

         
         Contenu vide des fichiers de certificats existants
      4. Écrivez le nouveau contenu (à partir de la sortie FMC) dans chacun des fichiers individuellement en utilisant vi cacert.pem / vi sftunnel-cert.pem / vi sftunnel-key.pem (commande séparée par fichier - les captures d'écran ne montrent cela que pour cacert.pem mais doivent être répétées pour sftunnel-cert.pem et sftunnel-key.pem).vi cacert.pem
         1. Appuyez sur i pour passer en mode interactif (après avoir entré la commande vi et vu un fichier vide).
         2. Copiez et collez l'intégralité du contenu (y compris -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----) dans le fichier.
            Copier le contenu en vi (mode INSERT)
         3. Fermez le fichier et écrivez-le avec ESC suivi de :wq, puis entrez.
            Échap suivi de : wq pour écrire dans le fichier
      5. Vérifiez que les autorisations correctes (chmod 644) et les propriétaires (chown root:root) sont définis pour chaque fichier à l'aide de la commande ls -hal. Ceci est correctement défini en fait lorsque nous mettons à jour le fichier existant.
         Tous les fichiers de certificat mis à jour avec les propriétaires et autorisations de droits
         
         
   3. Redémarrez sftunnel sur chaque FTD respectif où sftunnel n'était pas opérationnel pour que les modifications dans le certificat prennent effet avec la commande pmtool restartbyid sftunnel
      
      pmtool restartbyid sftunnel
      
      
3. Vérifiez que tous les FTD sont correctement connectés maintenant en utilisant la sortie sftunnel_status.pl

Solution 2 - Le certificat a déjà expiré

Dans cette situation, nous avons deux scénarios différents. Soit toutes les connexions sftunnel sont toujours opérationnelles, soit elles ne le sont plus (ou ne le sont plus partiellement).

FTD toujours connectés via sftunnel

Nous pouvons appliquer la même procédure que celle indiquée dans la section Certificat non encore expiré (scénario idéal) - Approche recommandée.

Cependant, ne mettez PAS à niveau ou ne redémarrez PAS le FMC (ou tout FTD) dans cette situation car il déconnecte toutes les connexions sftunnel et nous devons exécuter manuellement toutes les mises à jour de certificat sur chaque FTD. La seule exception à celle-ci, sont les versions de correctifs répertoriées car elles ne nécessitent pas de redémarrage du FMC.

Les tunnels restent connectés et les certificats sont remplacés sur chacun des FTD. Dans le cas où certains certificats ne seraient pas remplis, il vous invite avec ceux qui ont échoué et vous devez adopter l'approche manuelle comme indiqué précédemment sur la section précédente.

Les FTD ne sont plus connectés via sftunnel

Approche recommandée

Nous pouvons appliquer la même procédure que celle indiquée dans la section Certificat non encore expiré (scénario idéal) - Approche recommandée. Dans ce scénario, le nouveau certificat sera généré sur le FMC mais ne pourra pas être copié sur les périphériques car le tunnel est déjà arrêté. Ce processus peut être automatisé avec les scripts copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py

Si tous les périphériques FTD sont déconnectés du FMC, nous pouvons mettre à niveau le FMC dans cette situation car il n'a pas d'impact sur les connexions sftunnel. Si certains périphériques sont toujours connectés via sftunnel, alors sachez que la mise à niveau du FMC ferme toutes les connexions sftunnel et qu'elles ne se réactivent pas en raison de l'expiration du certificat. L'avantage de la mise à niveau ici serait qu'elle vous fournit une bonne orientation sur les fichiers de certificat qui doivent être transférés à chacun des FTD.

Approche manuelle

Dans cette situation, vous pouvez alors exécuter le script generate_certs.pl à partir du FMC qui génère les nouveaux certificats mais vous devez quand même les pousser vers chacun des périphériques FTD manuellement. En fonction de la quantité de périphériques, cette opération est faisable ou peut s'avérer fastidieuse. Cependant, lors de l'utilisation des scripts copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py, ceci est hautement automatisé.