Erneuerung des FMC-Sftunnel-CA-Zertifikats für FTD-Konnektivität

Einleitung

Dieses Dokument beschreibt die Verlängerung des Zertifikats der FirePOWER Management Center (FMC) Sftunnel Certificate Authority (CA) in Verbindung mit der FirePOWER Threat Defense (FTD)-Verbindung.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• FirePOWER Threat Defence
• FirePOWER Management Center
• Public Key Infrastructure (PKI)

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

FMC und FTD kommunizieren über Sftunnel (Sourcefire-Tunnel) miteinander. Diese Kommunikation verwendet Zertifikate, um die Kommunikation über eine TLS-Sitzung sicher zu machen. Mehr Informationen über den Sftunnel und wie er sich etabliert, finden Sie unter diesem Link.

Aus der Paketerfassung geht hervor, dass das FMC (in diesem Beispiel 10.48.79.232) und FTD (10.48.79.23) Zertifikate miteinander austauschen. Dabei wird überprüft, ob die Kommunikation mit dem richtigen Gerät erfolgt und ob ein Lauschangriff oder Man-In-The-Middle-Angriff (MITM) nicht stattfindet. Die Kommunikation wird mit diesen Zertifikaten verschlüsselt, und nur der Teilnehmer, dem der private Schlüssel für das Zertifikat zugeordnet ist, kann das Zertifikat erneut entschlüsseln.

Zertifikat_Austausch_Server_Zertifikat

Zertifikataustausch_Clientzertifikat

Sie können sehen, dass die Zertifikate von derselben Zertifizierungsstelle (Certificate Authority, CA) der internen Zertifizierungsstelle (Issuer) signiert werden, die auf dem FMC-System eingerichtet ist. Die Konfiguration wird im FMC in der Datei /etc/sf/sftunnel.conf definiert, die Folgendes enthält:

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

Dies gibt die Zertifizierungsstelle an, die zum Signieren aller Zertifikate für Sftunnel (FTD und FMC) verwendet wird, sowie das Zertifikat, das vom FMC zum Senden an alle FTDs verwendet wird. Dieses Zertifikat wird von der InternalCA signiert.

Wenn sich FTD beim FMC registriert, erstellt das FMC auch ein Zertifikat, um das FTD-Gerät zu senden, das für die weitere Kommunikation auf dem Sftunnel verwendet wird. Dieses Zertifikat wird ebenfalls vom gleichen internen Zertifizierungsstellenzertifikat signiert. Auf FMC finden Sie dieses Zertifikat (und den privaten Schlüssel) unter /var/sf/peers/<UUID-FTD-device> und möglicherweise unter dem Ordner certs_push. und heißt sftunnel-cert.pem (sftunnel-key.pem für den privaten Schlüssel). Auf FTD finden Sie diese unter /var/sf/peers/<UUID-FMC-device> mit derselben Namenskonvention.

Jedes Zertifikat hat jedoch auch eine Gültigkeitsdauer für Sicherheitszwecke. Bei der Überprüfung des InternalCA-Zertifikats wird auch die Gültigkeitsdauer angezeigt, die 10 Jahre für die FMC InternalCA beträgt, wie aus der Paketerfassung ersichtlich.

FMC-InternalCA_Gültigkeit

Problem

Das FMC InternalCA-Zertifikat ist nur 10 Jahre gültig. Nach Ablauf der Ablaufzeit vertraut das Remote-System diesem Zertifikat (sowie von ihm signierten Zertifikaten) nicht mehr und dies führt zu Problemen bei der Sftunnel-Kommunikation zwischen FTD- und FMC-Geräten. Dies bedeutet auch, dass einige wichtige Funktionen wie Verbindungsereignisse, Malware-Suchen, identitätsbasierte Regeln, Richtlinienbereitstellungen und viele andere Dinge nicht funktionieren.

Die Geräte werden auf der FMC-Benutzeroberfläche auf der Registerkarte Devices (Geräte) > Device Management (Geräteverwaltung) als deaktiviert angezeigt, wenn der Sftunnel nicht verbunden ist. Das Problem, das mit diesem Ablauf zusammenhängt, wird unter der Cisco Bug-ID CSCwd08098 nachverfolgt. Beachten Sie, dass alle Systeme betroffen sind, auch wenn Sie eine feste Version des Fehlers ausführen. Weitere Informationen zu diesem Fix finden Sie im Lösungsabschnitt.

Deaktivierte Geräte

Das FMC aktualisiert die Zertifizierungsstelle nicht automatisch und veröffentlicht die Zertifikate nicht erneut auf den FTD-Geräten. Außerdem gibt es keinen FMC-Integritätsalarm, der anzeigt, dass das Zertifikat abläuft. Die Cisco Bug-ID CSCwd08448 wird in dieser Hinsicht nachverfolgt, um eine Statuswarnung für die FMC-Benutzeroberfläche bereitzustellen.

Was geschieht nach dem Ablaufdatum?

Anfänglich passiert nichts und die sftunnel Kommunikationskanäle laufen weiter wie bisher. Wenn jedoch die Sftunnel-Kommunikation zwischen FMC- und FTD-Geräten unterbrochen wird und versucht wird, die Verbindung wiederherzustellen, schlägt sie fehl, und Sie können Protokollzeilen in der Protokolldatei beobachten, die auf das Ablaufdatum des Zertifikats hinweisen.

Protokollzeilen vom FTD-Gerät aus /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

Protokollzeilen von FMC-Gerät aus /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

Die Sftunnel-Kommunikation kann aus verschiedenen Gründen unterbrochen werden:

• Kommunikationsverlust aufgrund von Verlust der Netzwerkverbindung (möglicherweise nur vorübergehend)
• Neustart von FTD oder FMC
  • Erwartete: Manueller Neustart, Upgrades, manueller Neustart des Sftunnel-Prozesses auf FMC oder FTD (z. B. durch pmtool restartbyid sftunnel)
  • Unerwartete: Rückverfolgung, Stromausfall

Da es so viele Möglichkeiten gibt, die die sftunnel-Kommunikation unterbrechen können, ist es sehr ratsam, die Situation so schnell wie möglich zu korrigieren, auch wenn derzeit alle FTD-Geräte trotz abgelaufenem Zertifikat ordnungsgemäß angeschlossen sind.

Wie kann ich schnell überprüfen, ob das Zertifikat abgelaufen ist oder wann es abläuft?

Am einfachsten ist es, diese Befehle in der FMC SSH-Sitzung auszuführen:

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

Hier sehen Sie die Validity-Elemente des Zertifikats. Wichtigster Teil ist hier das "notAfter", welches zeigt, dass das Zertifikat hier bis zum 5. Oktober 2034 gültig ist.

NichtNach

Wenn Sie die Ausführung eines einzelnen Befehls vorziehen, der Ihnen sofort die Anzahl der Tage anzeigt, für die das Zertifikat noch gültig ist, können Sie Folgendes verwenden:

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

Ein Beispiel für eine Konfiguration, bei der das Zertifikat noch mehrere Jahre gültig ist, wird angezeigt.

Zertifikat_Ablauf_Validierung_Befehl

Wie werde ich in Zukunft über ein bevorstehendes Ablaufdatum des Zertifikats informiert?

Nach den letzten VDB-Updates (399 oder höher) werden Sie automatisch benachrichtigt, wenn Ihr Zertifikat innerhalb von 90 Tagen abläuft. Sie müssen dies daher nicht manuell nachverfolgen, da Sie kurz vor Ablauf der Frist benachrichtigt werden. Diese werden dann auf der FMC-Webseite in zwei Formen angezeigt. Beide Möglichkeiten finden Sie auf der Seite mit den Feldhinweisen.

Die erste Methode wird über die Registerkarte Task ausgeführt. Diese Nachricht ist klebrig und für den Benutzer verfügbar, es sei denn, sie wird explizit geschlossen. Das Benachrichtigungs-Popup wird ebenfalls angezeigt und steht zur Verfügung, bis es vom Benutzer explizit geschlossen wird. Es wird immer als Fehler angezeigt.

Ablaufbenachrichtigung auf Registerkarte "Vorgang"

Die zweite Methode ist der Integritätsalarm. Dies wird auf der Registerkarte "Status" angezeigt, ist jedoch nicht haftbar und wird ersetzt oder entfernt, wenn der Integritätsmonitor ausgeführt wird, der standardmäßig alle 5 Minuten ausgeführt wird. Es wird auch ein Benachrichtigungs-Popup angezeigt, das vom Benutzer explizit geschlossen werden muss. Dies kann sowohl als Fehler (wenn abgelaufen) als Warnung (wenn abläuft) angezeigt werden.

Ablaufbenachrichtigung auf der Registerkarte "Status"

Warnmeldung bei Warnmeldung

Fehlerbenachrichtigung bei Systemwarnung wird angezeigt

Lösung 1 - Zertifikat ist noch nicht abgelaufen (ideales Szenario)

Dies ist die beste Situation, da wir dann je nach Ablauf des Zertifikats noch Zeit haben. Entweder verfolgen wir den vollständig automatisierten Ansatz (empfohlen), der von der FMC-Version abhängt, oder wir verfolgen einen manuelleren Ansatz, der eine Interaktion mit dem TAC erfordert.

Empfohlener Ansatz

Dies ist die Situation, in der unter normalen Umständen keine Ausfallzeiten und ein geringster manueller Arbeitsaufwand zu erwarten sind.

Bevor Sie fortfahren, müssen Sie den Hotfix für Ihre spezielle Version wie hier aufgeführt installieren. Der Vorteil dabei ist, dass diese Hotfixes keinen Neustart des FMC und damit keine potenzielle unterbrochene Sftunnel-Kommunikation erfordern, wenn das Zertifikat bereits abgelaufen ist. Folgende Hotfixes stehen zur Verfügung:

• 7.0.0 - 7.0.6 : Hotfix FK - 7.0.6.99-9
• 7.1.x: keine feste Version als Ende der Softwarewartung
• 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: Hotfix B - 7.6.0.99-5

Nach der Installation des Hotfix enthält das FMC nun das Skript generate_certs.pl, das:

1. Regeneriert die interne Zertifizierungsstelle
2. Erstellt die von dieser neuen internen CA signierten Sftunnel-Zertifikate neu
3. Übergibt die neuen Sftunnel-Zertifikate und privaten Schlüssel an die entsprechenden FTD-Geräte (wenn der Sftunnel betriebsbereit ist)

Daher wird (wenn möglich) empfohlen:

1. Installieren Sie den entsprechenden Hotfix für Ihren Versionszug
2. Sicherung auf dem FMC durchführen
3. Validieren Sie alle aktuellen sftunnel-Verbindungen mit dem Skript sftunnel_status.pl auf dem FMC (aus dem Expert-Modus).
4. Das Skript im Expertenmodus mit generate_certs.pl ausführen
5. Überprüfen Sie das Ergebnis, um festzustellen, ob manuelle Vorgänge erforderlich sind (wenn die Geräte nicht mit dem FMC verbunden sind) [weiter unten erläutert].
6. Führen Sie sftunnel_status.pl vom FMC aus, um zu überprüfen, ob alle Sftunnel-Verbindungen ordnungsgemäß ausgeführt werden.

Generate_certs.pl-Skript

Im Beispiel hier sehen Sie, dass es eine Protokolldatei auf /var/log/sf/sfca_generation.log erstellt, angibt, sftunnel_status.pl zu verwenden, die Ablaufzeit auf der InternalCA angibt und angibt, ob Fehler aufgetreten sind. In diesem Fall konnten die Zertifikate beispielsweise nicht an das Gerät BSNS-1120-1 und EMEA-FPR3110-08 übertragen werden. Dies ist zu erwarten, da der Sftunnel für diese Geräte ausgefallen war.

Um den Sftunnel für die fehlerhaften Verbindungen zu korrigieren, führen Sie die folgenden Schritte aus:

1. Öffnen Sie in der FMC-CLI die Datei FAILED_PUSH mit cat /var/tmp/certs/1728303362/FAILED_PUSH (der Wert für die Zahl steht für die Unix-Zeit, überprüfen Sie also die Ausgabe des vorherigen Befehls in Ihrem System), die das nächste Format hat: FTD_UUID FTD_NAME FTD_IP QUELLE_PFAD_ON_FMC ZIELPFAD_ON_FTD
   
   FEHLGESCHLAGENER_PUSH
   
   
2. Übertragung der neuen Zertifikate (cacert.pem / sftunnel-key.pem / sftunnel-cert.pem) vom FMC auf die FTD-Geräte
   ===Automatischer Ansatz===
   
   Die Hotfix-Installation stellt außerdem die Skripte copy_sftunnel_certs.py und copy_sftunnel_certs_jumpserver.py bereit, die die Übertragung der verschiedenen Zertifikate auf Systeme automatisieren, für die der Sftunnel nicht aktiv war, während die Zertifikate neu generiert wurden. Dies kann auch für Systeme verwendet werden, bei denen die Verbindung zum SFTP-Tunnel unterbrochen wurde, da das Zertifikat bereits abgelaufen ist.
   
   Sie können das Skript copy_sftunnel_certs.py verwenden, wenn das FMC selbst SSH-Zugriff auf die verschiedenen FTD-Systeme hat. Ist dies nicht der Fall, können Sie das Skript (/usr/local/sf/bin/copy_sftunnel_certs_jumpserver.py) vom FMC auf einen Jump-Server herunterladen, der SSH-Zugriff auf die FMC(s) und FTD-Geräte hat, und von dort aus das Python-Skript ausführen. Wenn dies ebenfalls nicht möglich ist, schlagen Sie vor, den als Nächstes dargestellten manuellen Ansatz auszuführen. In den folgenden Beispielen wird das verwendete Skript copy_sftunnel_certs.py dargestellt. Die Schritte sind jedoch für das Skript copy_sftunnel_certs_jumpserver.py identisch.
   
   A. Erstellen Sie eine CSV-Datei auf dem FMC (oder Jump-Server), die die Geräteinformationen (Gerätename, IP-Adresse, admin_username, admin_password) enthält, die für die Herstellung der SSH-Verbindung verwendet werden.
   
   Wenn Sie dies von einem Remote-Server ausführen, z. B. einem Jump-Server für das primäre FMC, stellen Sie sicher, dass Sie die primären FMC-Details als ersten Eintrag gefolgt von allen verwalteten FTD- und sekundären FMC-Daten hinzufügen. Wenn Sie dies von einem Remote-Server aus ausführen, z. B. einem Jump-Server für das sekundäre FMC, stellen Sie sicher, dass Sie die Details des sekundären FMC als ersten Eintrag gefolgt von allen verwalteten FTD hinzufügen.
   
   i. Erstellen Sie eine Datei mit vi devices.csv.vi devices.csv
   
   ii) Dies öffnet die leere Datei (nicht abgebildet) und Sie füllen die Details aus, wie dargestellt, nachdem Sie i Buchstabe auf der Tastatur verwenden, um in den INTERAKTIVEN Modus zu wechseln (siehe unten auf dem Bildschirm).
   devices.csv Beispiel
   
   iii. Wenn Sie fertig sind, schließen und speichern Sie die Datei mit ESC gefolgt von :wq und dann Enter.
   Speichern Sie die Geräte.csv
   
   B. Führen Sie das Skript (von root mit sudo) mit copy_sftunnel_certs.py devices.csv und es zeigt Ihnen das Ergebnis. Hier wird angezeigt, dass das Zertifikat korrekt an FTDv weitergeleitet wurde und dass BSNS-1120-1 die SSH-Verbindung zum Gerät nicht herstellen konnte.
   
   copy_sftunnel_certs.py devices.csv
   
   ===Manueller Ansatz===
   
   
   1. Drucken (cat) Sie die Ausgabe jeder Datei für jede betroffene FTD (cacert.pem / sftunnel-key.pem (nicht vollständig aus Sicherheitsgründen dargestellt) / sftunnel-cert.pem) auf der FMC-CLI, indem Sie den Dateispeicherort aus der vorherigen Ausgabe (FAILED_PUSH-Datei) kopieren.
      
      cacert.pem
      sftunnel-key.pem
      sftunnel-cert.pem
   2. Öffnen Sie die FTD-CLI der jeweiligen FTD im Expertenmodus mit Root-Berechtigungen über sudo su, und erneuern Sie die Zertifikate mit dem nächsten Verfahren.
      1. Navigieren Sie zu dem Ort, der an dem hellblauen Markierungszeichen aus der Ausgabe FAILED_PUSH angezeigt wird (cd/var/sf/peers/cdb123c8-4347-11ef-aca1-f3aa241412a1, hier zum Beispiel, aber dies ist für jede FTD anders).
      2. Sichern der vorhandenen Dateien
         

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

         
         Sicherungen der aktuellen Zertifikate übernehmen
      3. Leere die Dateien, damit wir neue Inhalte schreiben können.
         

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

         
         Leerer Inhalt von vorhandenen Zertifikatsdateien
      4. Schreiben Sie den neuen Inhalt (aus der FMC-Ausgabe) in jede der Dateien einzeln mit vi cacert.pem / vi sftunnel-cert.pem / vi sftunnel-key.pem (separater Befehl pro Datei - Screenshots zeigen dies nur für cacert.pem, muss aber für sftunnel-cert.pem und sftunnel-key.pem wiederholt werden).vi cacert.pem
         1. Drücken Sie i, um in den interaktiven Modus zu wechseln (nachdem der Befehl vi eingegeben wurde und eine leere Datei angezeigt wird).
         2. Kopieren Sie den gesamten Inhalt (einschließlich -----BEGIN CERTIFICATE----- und -----END CERTIFICATE-----) in die Datei.
            Inhalt in vi kopieren (INSERT-Modus)
         3. Schließen Sie die Datei, und schreiben Sie sie mit ESC, gefolgt von :wq, und geben Sie dann ein.
            ESC gefolgt von :wq zum Schreiben in eine Datei
      5. Überprüfen Sie, ob die richtigen Berechtigungen (chmod 644) und Besitzer (chown root:root) für jede der Dateien mit ls -hal gesetzt sind. Dies ist richtig gesetzt, wenn wir die vorhandene Datei aktualisieren.
         Alle Zertifikatsdateien wurden mit Rechteinhabern und Berechtigungen aktualisiert.
         
         
   3. Starten Sie den Sftunnel auf jedem FTD neu, wenn der Sftunnel nicht betriebsbereit war, damit die Änderungen im Zertifikat mit dem Befehl wirksam werden. pmtool restartbyid sftunnel
      
      pmtool restartbyid sftunnel
      
      
3. Überprüfen Sie jetzt mit der Ausgabe von sftunnel_status.pl, ob alle FTDs korrekt angeschlossen sind.

Lösung 2 - Zertifikat ist bereits abgelaufen

In dieser Situation haben wir zwei verschiedene Szenarien. Entweder sind alle Tunnelverbindungen noch nicht (oder nur teilweise) funktionsfähig.

FTDs weiterhin über Sftunnel verbunden

Wir können das gleiche Verfahren anwenden, wie im Zertifikat angegeben ist noch nicht abgelaufen (ideales Szenario) - Empfohlener Ansatz Abschnitt.

Führen Sie in diesem Fall jedoch KEIN Upgrade oder Neustart des FMC (oder eines FTD) durch, da es die Verbindung mit allen Sftunnel-Verbindungen unterbricht und alle Zertifikats-Updates manuell auf jedem FTD ausgeführt werden müssen. Die einzige Ausnahme sind die aufgeführten Hotfix-Versionen, da sie keinen Neustart des FMC erfordern.

Die Tunnel bleiben verbunden und die Zertifikate werden auf jedem FTD ersetzt. Falls einige Zertifikate nicht ausgefüllt werden können, werden die fehlerhaften Zertifikate angezeigt, und Sie müssen den manuellen Ansatz wie im vorherigen Abschnitt beschrieben anwenden.

FTDs nicht mehr über Sftunnel verbunden

Empfohlener Ansatz

Wir können das gleiche Verfahren anwenden, wie im Zertifikat angegeben ist noch nicht abgelaufen (ideales Szenario) - Empfohlener Ansatz Abschnitt. In diesem Szenario wird das neue Zertifikat auf dem FMC generiert, kann jedoch nicht auf die Geräte kopiert werden, da der Tunnel bereits ausgefallen ist. Dieser Prozess kann mit den Skripten copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py automatisiert werden.

Wenn alle FTD-Geräte vom FMC getrennt sind, können wir das FMC in diesem Fall aktualisieren, da dies keine Auswirkungen auf die Softunnel-Verbindungen hat. Wenn Sie noch einige Geräte über sftunnel verbunden haben, dann beachten Sie, dass das Upgrade des FMC alle sftunnel-Verbindungen schließt und sie nicht wieder kommen, weil das Zertifikat abgelaufen ist. Der Vorteil des Upgrades besteht darin, dass es Ihnen eine gute Anleitung für die Zertifikatsdateien bietet, die auf die einzelnen FTDs übertragen werden müssen.

Manueller Ansatz

In dieser Situation können Sie dann das Skript generate_certs.pl vom FMC ausführen, das die neuen Zertifikate generiert, Sie müssen sie jedoch manuell auf jedes FTD-Gerät übertragen. Je nach Anzahl der Geräte ist dies machbar oder kann eine mühsame Aufgabe sein. Bei Verwendung der Skripte copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py ist dies jedoch hochautomatisiert.