Rinnovo del certificato CA del tunnel SFC del CCP per la connettività FTD

Introduzione

In questo documento viene descritto il rinnovo del certificato CA (Certification Authority) di Firepower Management Center (FMC) in relazione alla connettività Firepower Threat Defense (FTD).

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Firepower Threat Defense
• Firepower Management Center
• PKI (Public Key Infrastructure)

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Il FMC e l'FTD comunicano tra loro attraverso il tunnel Sourcefire. In questa comunicazione vengono utilizzati i certificati per proteggere la conversazione in una sessione TLS. Per maggiori informazioni su sftunnel e su come viene stabilito, cliccare su questo link.

Dall'acquisizione dei pacchetti è possibile notare che i due FMC (10.48.79.232 nell'esempio) e FTD (10.48.79.23) si scambiano certificati. Lo fanno per convalidare che parlano con il dispositivo corretto e non c'è alcun tipo di intercettazione o attacco Man-In-The-Middle (MITM). La comunicazione viene crittografata utilizzando tali certificati e solo la parte che dispone della chiave privata associata per il certificato è in grado di decrittografarla nuovamente.

Certificato_scambio_server_cert

Certificato_scambio_client_cert

È possibile visualizzare i certificati firmati dalla stessa CA interna (autorità di certificazione) impostata nel sistema FMC. La configurazione è definita nel file /etc/sf/sftunnel.conf del FMC che contiene:

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;
}; 

Indica l'autorità di certificazione utilizzata per firmare tutti i certificati per sftunnel (FTD e FMC uno) e il certificato utilizzato dal FMC per inviare tutti i FTD. Il certificato è firmato dalla CA interna.

Quando un FTD si registra nel FMC, quest'ultimo crea anche un certificato da inviare al dispositivo FTD utilizzato per le successive comunicazioni nel tunnel sfc. Il certificato è firmato anche dallo stesso certificato CA interno. In FMC, il certificato (e la chiave privata) si trovano nella cartella /var/sf/peers/<UUID-FTD-device> e potenzialmente nella cartella certs_pushed ed è denominato sftunnel-cert.pem (sftunnel-key.pem per la chiave privata). Su FTD, è possibile trovare quelli sotto /var/sf/peers/<UUID-FMC-device> con la stessa convenzione di denominazione.

Ogni certificato ha tuttavia anche un periodo di validità a fini di sicurezza. Quando si controlla il certificato InternalCA, è possibile verificare anche il periodo di validità che è di 10 anni per l'InternalCA FMC, come mostrato dall'acquisizione del pacchetto.

FMC-ValiditàCA_interna

Problema

Il certificato CA interna del CCP è valido solo per 10 anni. Dopo la scadenza, il sistema remoto non considera più attendibile il certificato (e i certificati da esso firmati) e ciò comporta problemi di comunicazione del tunnel tra i dispositivi FTD e FMC. Questo significa anche che diverse funzionalità chiave come gli eventi di connessione, le ricerche di malware, le regole basate sull'identità, le distribuzioni di criteri e molti altri elementi non funzionano.

I dispositivi vengono visualizzati come disattivati nell'interfaccia utente di FMC nella scheda Dispositivi > Gestione dispositivi quando sftunnel non è connesso. Il problema relativo alla scadenza viene registrato nell'ID bug Cisco CSCwd08098. Si noti tuttavia che il problema interessa tutti i sistemi, anche se si esegue una versione fissa del problema. Per ulteriori informazioni su questa correzione, vedere la sezione Soluzione.

Periferiche disabilitate

Il FMC non aggiorna automaticamente la CA e ripubblica i certificati sui dispositivi FTD. Non è inoltre presente alcun avviso di integrità del CCP che indica che il certificato scade. A questo proposito, viene registrato l'ID bug Cisco CSCwd08448 per fornire un avviso sullo stato di salute sull'interfaccia utente del Cisco in futuro.

Cosa succede dopo la data di scadenza?

Inizialmente non accade nulla e i canali di comunicazione sftunnel continuano a funzionare come prima. Tuttavia, quando la comunicazione sftunnel tra i dispositivi FMC e FTD si interrompe e tenta di ristabilire la connessione, non riesce ed è possibile osservare le righe di registro nel file di registro dei messaggi che indicano la scadenza del certificato.

Righe di registro dal dispositivo FTD da /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

Righe di registro dal dispositivo FMC da /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 comunicazione con il tunnel alternativo può essere interrotta per diversi motivi:

• Perdita di comunicazione a causa della perdita di connettività di rete (potenzialmente solo temporanea)
• Riavvio di FTD o FMC
  • Previsti: riavvio manuale, aggiornamenti, riavvio manuale del processo sftunnel su FMC o FTD (ad esempio tramite pmtool restartbyid sftunnel)
  • Quelli imprevisti: traceback, interruzione dell'alimentazione

Poiché ci sono così tante possibilità che possono interrompere la comunicazione sftunnel, si consiglia vivamente di correggere sulla situazione il più rapidamente possibile, anche quando attualmente tutti i dispositivi FTD sono correttamente collegati nonostante il certificato scaduto.

Come verificare rapidamente se il certificato è scaduto o quando scade?

Il modo più semplice è eseguire questi comandi sulla sessione SSH del FMC:

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

Vengono visualizzati gli elementi Validità del certificato. La parte principale qui rilevante è il "notAfter" che mostra che il certificato qui è valido fino al 5 ottobre 2034.

NonDopo

Se si preferisce eseguire un unico comando che fornisca immediatamente il numero di giorni per cui il certificato è ancora valido, è possibile utilizzare quanto segue:

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

Viene visualizzato un esempio di installazione in cui il certificato è ancora valido per più anni.

Comando_convalida_scadenza_certificato

Come si riceve in futuro una notifica relativa alla prossima scadenza di un certificato?

Con gli aggiornamenti recenti di VDB (399 o versione successiva), viene visualizzato automaticamente un avviso quando il certificato scade entro 90 giorni. Pertanto, non è necessario tenere traccia manualmente della situazione da soli, in quanto si viene avvisati quando si è vicini alla scadenza. Questo viene visualizzato nella pagina Web del CCP in due forme. In entrambi i casi si fa riferimento alla pagina di notifica.

Il primo metodo consiste nell'utilizzare la scheda Task. Questo messaggio è permanente e disponibile per l'utente a meno che non sia stato esplicitamente chiuso. Viene visualizzata anche la finestra popup di notifica, disponibile fino alla chiusura esplicita da parte dell'utente. Viene sempre visualizzato come un errore.

Notifica di scadenza nella scheda Task

Il secondo metodo è tramite Health Alert. Questa opzione viene visualizzata nella scheda Integrità ma non è permanente e sostituisce o rimuove quando si esegue Health Monitor che, per impostazione predefinita, è ogni 5 minuti. Viene inoltre visualizzato un popup di notifica che deve essere chiuso esplicitamente dall'utente. Ciò può essere visualizzato come errore (se scaduto) come avviso (se sta per scadere).

Notifica di scadenza nella scheda Integrità

Notifica di avviso all'apertura dell'avviso di stato

Notifica di errore durante la visualizzazione dell'avviso di stato

Soluzione 1 - Il certificato non è ancora scaduto (scenario ideale)

Questa è la situazione migliore perché, a seconda della scadenza del certificato, abbiamo ancora tempo. O adottiamo l'approccio completamente automatizzato (consigliato) che dipende dalla versione FMC o un approccio più manuale che richiede l'interazione TAC.

Approccio consigliato

Questa è la situazione in cui non si prevedono tempi di inattività e si prevede un minor numero di operazioni manuali in circostanze normali.

Prima di procedere, è necessario installare l'aggiornamento rapido per la versione in uso, come indicato di seguito. Il vantaggio è che tali aggiornamenti rapidi non richiedono il riavvio del FMC e quindi la potenziale interruzione della comunicazione con il tunnel quando il certificato è già scaduto. Gli aggiornamenti rapidi disponibili sono:

• 7.0.0 - 7.0.6 : Aggiornamento rapido FK - 7.0.6.99-9
• 7.1.x : nessuna versione fissa alla fine della manutenzione del software
• 7.2.0 - 7.2.9 : Aggiornamento rapido FZ - 7.2.9.99-4
• 7.3.x : Aggiornamento rapido - 7.3.1.99-4
• 7.4.0 - 7.4.2 : Aggiornamento rapido AO - 7.4.2.99-5
• 7.6.0 : Aggiornamento rapido B - 7.6.0.99-5

Una volta installato l'hotfix, il FMC contiene ora lo script generate_certs.pl che:

1. Rigenera la CA interna
2. Ricrea i certificati sftunnel firmati da questa nuova CA interna
3. Invia i nuovi certificati sftunnel e le nuove chiavi private ai rispettivi dispositivi FTD (quando il sftunnel è operativo)

Si raccomanda pertanto (se possibile) di:

1. Installare l'hotfix applicabile per la versione in uso
2. Eseguire un backup sul CCP
3. Convalida tutte le connessioni sftunnel correnti utilizzando lo script sftunnel_status.pl nel FMC (dalla modalità Expert)
4. Eseguire lo script dalla modalità Expert utilizzando generate_certs.pl
5. Esaminare il risultato per verificare se sono necessarie operazioni manuali (quando i dispositivi non sono collegati al CCP) [ulteriori informazioni]
6. Eseguire il file sftunnel_status.pl dalla console Gestione configurazione server per verificare che tutte le connessioni sftunnel funzionino correttamente

Script Generate_certs.pl

Nell'esempio riportato di seguito viene indicato che viene creato un file di log in /var/log/sf/sfca_generation.log, che indica di utilizzare sftunnel_status.pl, che indica l'ora di scadenza dell'autorità di certificazione interna e di eventuali errori. In questo caso, ad esempio, non è stato possibile inviare i certificati ai dispositivi BSNS-1120-1 e EMEA-FPR3110-08, come previsto perché lo sftunnel non era attivo per tali dispositivi.

Per correggere lo sftunnel per le connessioni non riuscite, eseguire la procedura seguente:

1. Dalla CLI di FMC, aprire il file FAILED_PUSH utilizzando cat /var/tmp/certs/1728303362/FAILED_PUSH (il valore numerico rappresenta l'ora univoca, quindi controllare l'output del comando precedente nel sistema) nel formato successivo: FTD_UUID NOME_FTD FTD_IP PERCORSO_ORIGINE SU FMC PERCORSO_DESTINAZIONE SU FTD
   
   PUSH_NON RIUSCITO
   
   
2. Trasferire i nuovi certificati (cacert.pem / sftunnel-key.pem / sftunnel-cert.pem) dal FMC ai dispositivi FTD
   ===Approccio automatico==
   
   L'installazione dell'aggiornamento rapido fornisce inoltre gli script copy_sftunnel_certs.py e copy_sftunnel_certs_jumpserver.py che automatizzano il trasferimento dei vari certificati ai sistemi per cui sftunnel non era attivo durante la rigenerazione dei certificati. Questa opzione può essere utilizzata anche per i sistemi con una connessione sftunnel interrotta perché il certificato è già scaduto.
   
   È possibile utilizzare lo script copy_sftunnel_certs.py quando il CCP stesso ha accesso SSH ai vari sistemi FTD. In caso contrario, è possibile scaricare lo script (/usr/local/sf/bin/copy_sftunnel_certs_jumpserver.py) dal CCP su un server di collegamento che disponga di accesso SSH ai CCP e ai dispositivi FTD ed eseguire lo script Python da tale server. Se anche questo non è possibile, consigliare di eseguire l'approccio manuale indicato di seguito. Negli esempi seguenti viene illustrato lo script copy_sftunnel_certs.py in uso, ma i passaggi sono gli stessi per lo script copy_sftunnel_certs_jumpserver.py.
   
   A. Creare un file CSV sul FMC (o sul server di collegamento) contenente le informazioni sul dispositivo (nome_dispositivo, indirizzo IP, nome_utente_amministratore, password_amministratore) usate per stabilire la connessione SSH.
   
   Quando si esegue questa operazione da un server remoto come un server di collegamento per il CCP primario, assicurarsi di aggiungere i dettagli del CCP primario come prima voce, seguita da tutti i CCP gestito e secondario. Quando si esegue questa operazione da un server remoto come un server di collegamento per un FMC secondario, assicurarsi di aggiungere i dettagli del FMC secondario come prima voce seguita da tutti i FTD gestiti.
   
   i. Creare un file utilizzando vi devices.csv.vi devices.csv
   
   ii. In questo modo si apre il file vuoto (non visualizzato) e si inseriscono i dettagli come mostrato dopo aver utilizzato i caratteri sulla tastiera per passare alla modalità INTERATTIVA (visibile nella parte inferiore dello schermo).
   esempio di devices.csv
   
   iii. Al termine, chiudere e salvare il file utilizzando ESC seguito da :wq e quindi da Invio.
   Salvare il file devices.csv
   
   B. Eseguire lo script (dalla directory principale utilizzando sudo) con copy_sftunnel_certs.py devices.csv e viene visualizzato il risultato. Qui mostra che il certificato per FTDv è stato inserito correttamente e che per BSNS-1120-1 non poteva effettuare la connessione SSH al dispositivo.
   
   copy_sftunnel_certs.py dispositivi.csv
   
   ===Approccio manuale==
   
   
   1. Stampa (cat) l'output di ciascuno dei file di ciascun FTD interessato (cacert.pem / sftunnel-key.pem (non visualizzato completamente per motivi di sicurezza) / sftunnel-cert.pem) sulla CLI di FMC copiando il percorso del file dall'output precedente (file FAILED_PUSH).
      
      cacert.pem
      sftunnel-key.pem
      sftunnel-cert.pem
   2. Aprire la CLI FTD di ciascun FTD in modalità Expert con privilegi root tramite sudo su e rinnovare i certificati con la procedura successiva.
      1. Individuare la posizione visualizzata nella luce blu chiara dell'output FAILED_PUSH (cd/var/sf/peers/cdb123c8-4347-11ef-aca1-f3aa241412a1 ad esempio, ma questa è diversa per ogni FTD).
      2. Eseguire il backup dei file esistenti.
         

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

         
         Esegui backup dei certificati correnti
      3. Svuotare i file in modo che sia possibile scrivere nuovo contenuto al loro interno.
         

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

         
         Contenuto vuoto dei file di certificato esistenti
      4. Scrivere il nuovo contenuto (dall'output FMC) in ciascuno dei file singolarmente utilizzando vi cacert.pem / vi sftunnel-cert.pem / vi sftunnel-key.pem (comando separato per file - gli screenshot mostrano questo solo per cacert.pem ma devono essere ripetuti per sftunnel-cert.pem e sftunnel-key.pem).vi cacert.pem
         1. Premere i per passare alla modalità interattiva (dopo l'immissione del comando vi viene visualizzato un file vuoto).
         2. Copiare e incollare l'intero contenuto (inclusi —BEGIN CERTIFICATE— e —END CERTIFICATE—) nel file.
            Copiare il contenuto in vi (modalità INSERT)
         3. Chiudere e scrivere nel file con ESC seguito da :wq e quindi immettere.
            ESC seguito da :wq per scrivere nel file
      5. Verificare che le autorizzazioni corrette (chmod 644) e i proprietari (chown root:root) siano impostati per ogni file utilizzando ls -hal. L'impostazione è corretta quando si aggiorna il file esistente.
         Tutti i file di certificato aggiornati con i proprietari e le autorizzazioni corretti
         
         
   3. Riavviare il sftunnel su ciascun FTD in cui il sftunnel non era operativo per rendere effettive le modifiche nel certificato con il comando pmtool restartbyid sftunnel
      
      pmtool restartbyid sftunnel
      
      
3. Verificare che tutti i FTD siano collegati correttamente utilizzando l'output sftunnel_status.pl

Soluzione 2 - Il certificato è già scaduto

In questa situazione, abbiamo due diversi scenari. Tutte le connessioni sftunnel sono ancora operative oppure non sono più (o sono parziali).

FTD ancora connessi tramite sftunnel

È possibile applicare la stessa procedura indicata nella sezione Certificato non ancora scaduto (scenario ideale) - Metodo consigliato.

Tuttavia, NON aggiornare o riavviare il FMC (o qualsiasi FTD) in questa situazione in quanto disconnette tutte le connessioni sftunnel e dobbiamo eseguire manualmente tutti gli aggiornamenti dei certificati su ogni FTD. L'unica eccezione è rappresentata dalle versioni degli aggiornamenti rapidi elencate, che non richiedono il riavvio del FMC.

Le gallerie restano collegate e i certificati sono sostituiti su ciascuno FTD. Nel caso in cui alcuni certificati non possano essere compilati, viene richiesto se si sono verificati errori ed è necessario adottare l'approccio manuale indicato in precedenza nella sezione precedente.

FTD non più connessi tramite sftunnel

Approccio consigliato

È possibile applicare la stessa procedura indicata nella sezione Certificato non ancora scaduto (scenario ideale) - Metodo consigliato. In questo scenario, il nuovo certificato verrà generato nel FMC ma non potrà essere copiato nei dispositivi perché il tunnel è già inattivo. Questo processo può essere automatizzato con gli script copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py

Se tutti i dispositivi FTD sono scollegati dal CCP, è possibile aggiornare il CCP in questa situazione in quanto non ha alcun impatto sulle connessioni del tunnel. Se si dispone ancora di alcuni dispositivi connessi tramite sftunnel, tenere presente che l'aggiornamento della console Gestione configurazione FMC chiude tutte le connessioni sftunnel e che tali dispositivi non vengono visualizzati di nuovo a causa del certificato scaduto. Il vantaggio di questo aggiornamento è che fornisce una buona guida sui file di certificato che devono essere trasferiti a ciascuno degli FTD.

Approccio manuale

In questo caso, è possibile eseguire lo script generate_certs.pl dal FMC che genera i nuovi certificati, ma è comunque necessario eseguirne il push manualmente in ciascun dispositivo FTD. A seconda della quantità di dispositivi, questa operazione è fattibile o può essere noiosa. Tuttavia, quando si utilizzano gli script copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py, questa operazione è altamente automatizzata.