Vernieuwing FMC Sftunnel CA-certificaat voor FTD-connectiviteit

Inleiding

Dit document beschrijft de verlenging van het certificaat van de Firepower Management Center (FMC)-certificeringsinstantie (CA) in relatie tot de connectiviteit van Firepower Threat Defense (FTD).

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

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

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

FMC en FTD communiceren met elkaar over een tunnel (Sourcefire tunnel). Deze communicatie maakt gebruik van certificaten om het gesprek veilig te maken tijdens een TLS-sessie. Meer informatie over de tunnel en hoe deze tot stand komt, is te vinden op deze link.

Uit de packet capture kun je opmaken dat de FMC (10.48.79.232 in dit voorbeeld) en FTD (10.48.79.23) certificaten met elkaar uitwisselen. Ze doen dit om te valideren dat ze met het juiste apparaat praten en er geen afluisterpraktijken of Man-In-The-Middle (MITM) -aanval zijn. De communicatie wordt versleuteld met behulp van die certificaten en alleen de partij die de bijbehorende privésleutel voor dat certificaat heeft, kan deze opnieuw decoderen.

Certificate_exchange_server_cert

Certificate_exchange_client_cert

U kunt zien dat de certificaten zijn ondertekend door dezelfde InternalCA (Issuer) Certificate Authority (CA) die is ingesteld op het FMC-systeem. De configuratie is gedefinieerd in het FMC op /etc/sf/sftunnel.conf bestand dat zoiets bevat als:

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

Dit geeft de CA aan die wordt gebruikt om alle certificaten voor sftunnel te ondertekenen (zowel het FTD als het FMC) en het certificaat dat door het FMC wordt gebruikt om naar alle FTD's te sturen. Dit certificaat is ondertekend door de InternalCA.

Wanneer FTD zich registreert bij het FMC, creëert het FMC ook een certificaat om naar het FTD-apparaat te duwen dat wordt gebruikt voor de verdere communicatie over de tunnel. Dit certificaat is ook ondertekend door hetzelfde certificaat van de interne CA. Op FMC kunt u dat certificaat (en privésleutel) vinden onder / var / sf / peers /<UUID-FTD-device> en mogelijk onder certs_pushed map en wordt sftunnel-cert.pem genoemd (sftunnel-key.pem voor privésleutel). Op FTD kun je die vinden onder /var/sf/peers/<UUID-FMC-device> met dezelfde naamgevingsconventie.

Elk certificaat heeft echter ook een geldigheidsduur voor veiligheidsdoeleinden. Bij het inspecteren van het InternalCA-certificaat kunnen we ook de geldigheidsperiode zien die 10 jaar is voor de FMC InternalCA, zoals blijkt uit de pakketopname.

FMC-InternalCA_validity

Probleem

Het FMC InternalCA certificaat is slechts 10 jaar geldig. Na de vervaldatum vertrouwt het externe systeem dit certificaat niet meer (evenals de door het ondertekende certificaten) en dit leidt tot problemen met de communicatie tussen FTD- en FMC-apparaten (en ook FMC HA-communicatie). Dit betekent ook dat verschillende belangrijke functionaliteiten zoals verbindingsgebeurtenissen, malware-opzoeken, op identiteit gebaseerde regels, beleidsimplementaties en vele andere dingen niet werken.

De apparaten worden wel weergegeven als uitgeschakeld op de FMC-gebruikersinterface onder het tabblad Apparaten > Apparaatbeheer wanneer de sftunnel niet is aangesloten. Het probleem dat betrekking heeft op deze vervaldatum wordt bijgehouden op Cisco bug ID CSCwd08098. Houd er echter rekening mee dat alle systemen worden beïnvloed, zelfs wanneer u een vaste release van het defect uitvoert. Meer informatie over deze oplossing vindt u in de sectie Oplossing.

Gehandicapte apparaten

De FMC vernieuwt de CA niet automatisch en publiceert de certificaten niet opnieuw naar de FTD-apparaten. En er is ook geen FMC-gezondheidswaarschuwing die aangeeft dat het certificaat verloopt. Cisco bug ID CSCwd08448 wordt in dit opzicht gevolgd om in de toekomst een gezondheidswaarschuwing op de FMC UI te geven.

Wat gebeurt er na de vervaldatum?

In eerste instantie gebeurt er niets en blijven de sftunnelcommunicatiekanalen werken zoals voorheen. Wanneer de sftunnelcommunicatie tussen FMC- en FTD-apparaten echter wordt verbroken en deze probeert de verbinding opnieuw tot stand te brengen, mislukt deze en kunt u logboeklijnen in het berichtenlogbestand waarnemen die wijzen op het verlopen van het certificaat. Merk op dat de sftunnelcommunicatie (gebruikt voor High-Availability (HA)-synchronisatie) tussen primaire en secundaire FMC mogelijk ook wordt beïnvloed zoals beschreven in deze sectie.

Loglijnen van FTD-apparaat van /ngfw/var/log/berichten:

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

Loglijnen van FMC-apparaat van /var/log/berichten:

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

De stunnel-communicatie kan om verschillende redenen worden verbroken:

• Communicatieverlies door verlies van netwerkconnectiviteit (mogelijk slechts tijdelijk)
• Opnieuw opstarten van FTD of FMC
  • Verwachte: handmatige reboot, upgrades, handmatige herstart van sftunnelproces op FMC of FTD (bijvoorbeeld door pmtool restart byid sftunnel)
  • Onverwachte: tracebacks, stroomuitval

Omdat er zoveel mogelijkheden zijn die de sftunnelcommunicatie kunnen doorbreken, is het sterk aan te raden om zo snel mogelijk te corrigeren op de situatie, zelfs wanneer momenteel alle FTD-apparaten goed zijn aangesloten ondanks het verlopen certificaat.

Hoe snel te controleren of het certificaat is verlopen of wanneer het verloopt?

De eenvoudigste manier is om deze opdrachten uit te voeren op de FMC SSH-sessie:

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

Dit toont u de geldigheidselementen van het certificaat. Het belangrijkste relevante deel hier is de "notAfter" waaruit blijkt dat het certificaat hier geldig is tot 5 oktober 2034.

Niet daarna

Als u de voorkeur geeft aan een enkele opdracht die u onmiddellijk het aantal dagen geeft waarvoor het certificaat nog steeds geldig is, kunt u dit gebruiken:

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

Een voorbeeld van een setup waarbij het certificaat nog meerdere jaren geldig is wordt getoond.

Certificate_expiry_validation_command

Hoe word ik in de toekomst op de hoogte gebracht van een aanstaande vervaldatum van het certificaat?

Bij recente VDB-updates (399 of hoger) wordt u automatisch gewaarschuwd wanneer uw certificaat binnen 90 dagen verloopt. Daarom hoeft u dit zelf niet handmatig bij te houden, omdat u wordt gewaarschuwd wanneer u dicht bij de vervaltijd bent. Dit verschijnt vervolgens op de FMC-webpagina in twee vormen. Beide manieren verwijzen naar de veldmeldingspagina.

De eerste methode is via het tabblad Taak. Dit bericht is plakkerig en beschikbaar voor de gebruiker, tenzij uitdrukkelijk gesloten. Het pop-upbericht verschijnt ook en is beschikbaar totdat het expliciet door de gebruiker wordt gesloten. Het wordt altijd weergegeven als een fout.

Melding over verlopen op het tabblad Taak

De tweede methode is via gezondheidswaarschuwing. Dit wordt weergegeven op het tabblad Gezondheid, maar is niet kleverig en vervangt of verwijdert de monitor wanneer deze wordt uitgevoerd, wat standaard elke 5 minuten gebeurt. Het toont ook een pop-upmelding die expliciet door de gebruiker moet worden gesloten. Dit kan zowel verschijnen als fout (wanneer verlopen) als waarschuwing (wanneer verloopt).

Melding bij verstrijken op tabblad Gezondheid

Waarschuwingsbericht op pop-upvenster Gezondheidswaarschuwing

Foutmelding in pop-upvenster Gezondheidswaarschuwing

Oplossing 1 - Certificaat is nog niet verlopen (ideaal scenario)

Dit is de beste situatie omdat we dan, afhankelijk van het verlopen van het certificaat, nog tijd hebben. Of we kiezen voor de volledig geautomatiseerde aanpak (aanbevolen) die afhankelijk is van de FMC-versie of we kiezen voor een meer handmatige aanpak waarvoor TAC-interactie vereist is.

Aanbevolen aanpak

Dit is de situatie waarin in normale omstandigheden geen downtime en de minste hoeveelheid handmatige handelingen wordt verwacht.

Voordat u doorgaat, moet u de hotfix voor uw specifieke versie installeren zoals hier vermeld. Het voordeel hiervan is dat deze hotfixes geen reboot van de FMC vereisen en dus mogelijk een verbroken sftunnelcommunicatie wanneer het certificaat al is verlopen. De beschikbare hotfixes (downloadkoppelingen zijn voor virtuele FMC, voor hardware kijkt FMC naar de juiste downloadpagina's voor de versies) zijn:

• 7.0.0 - 7.0.6: Hotfix FK - 7.0.6.99-9
• 7.1.x: geen vaste release als einde van software-onderhoud
• 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

Zodra de hotfix is geïnstalleerd, bevat de FMC nu het script generate_certs.pl dat:

1. Regenereert de interne CA
2. Herstelt de sftunnelcertificaten die zijn ondertekend door deze nieuwe InternalCA
3. Duwt de nieuwe sftunnelcertificaten en privésleutels over naar de respectieve FTD-apparaten (en secundaire FMC indien van toepassing) (wanneer de sftunnel operationeel is)

Opmerking: Het generate_certs.pl script controleert momenteel of kritieke bewerkingen worden uitgevoerd. Zo niet, dan loopt het niet.

Kritieke bewerkingen kunnen zijn: Smart agent niet geregistreerd of registratie aan de gang, back-up-/hersteltaak aan de gang, SRU-updatetaak aan de gang, VDB-updatetaak aan de gang, Domeintaak aan de gang, HA-bewerking aan de gang of upgrade wordt uitgevoerd.

Daarom kunt u dit script niet uitvoeren wanneer u alleen klassieke licenties op uw FMC gebruikt (of een van de vermelde bewerkingen moet eerst worden voltooid), in welk geval u contact moet opnemen met Cisco TAC om deze controle te omzeilen, de certificaten opnieuw te genereren en de bypass opnieuw ongedaan te maken.

Daarom wordt aanbevolen (indien mogelijk) om:

1. Installeer de toepasselijke hotfix voor uw versietrein
2. Maak een back-up op de FMC
3. Alle huidige sftunnel-verbindingen valideren met behulp van het script sftunnel_status.pl op de FMC (vanuit de expert-modus)
4. Voer het script uit vanuit de expertmodus met generate_certs.pl
5. Inspecteer het resultaat om te controleren of handmatige bewerkingen vereist zijn (wanneer apparaten niet op de VCC zijn aangesloten) [hieronder nader toegelicht]
6. Voer sftunnel_status.pl uit vanuit de FMC om te bevestigen dat alle sftunnel-verbindingen goed werken

Generate_certs.pl script

Opmerking: wanneer u FMC hebt die wordt uitgevoerd in High-Availability (HA), moet u de bewerking eerst uitvoeren op het primaire knooppunt en vervolgens op het secundaire knooppunt, omdat het die certificaten ook gebruikt om te communiceren tussen de FMC-knooppunten. De InternalCA op beide FMC-knooppunten is anders, dus ze hebben verschillende vervaltijden. Meer informatie over de certificaten vindt u in FMC HA op deze sectie.

In het voorbeeld hier zie je dat het een logbestand aanmaakt op /var/log/sf/sfca_generation.log, aangeeft sftunnel_status.pl te gebruiken, de vervaltijd op de InternalCA aangeeft en aangeeft voor eventuele fouten erop. Hier bijvoorbeeld slaagde het er niet in om de certificaten over te zetten naar het apparaat BSNS-1120-1 en EMEA-FPR3110-08, wat wordt verwacht omdat de sftunnel voor die apparaten was uitgeschakeld.

Om de tunnel voor de mislukte verbindingen te corrigeren, voert u de volgende stappen uit:

1. Open in de FMC CLI het bestand FAILED_PUSH met cat /var/tmp/certs/1728303362/FAILED_PUSH (de waarde van het getal staat voor de unix-tijd, dus controleer de uitvoer van de vorige opdracht in uw systeem) die de volgende indeling heeft: FTD_UUID FTD_NAME FTD_IP SOURCE_PATH_ON_FMC DESTINATION_PATH_ON_FTD
   
   MISLUKT_PUSH
   
   
2. Overdracht van die nieuwe certificaten (cacert.pem / sftunnel-key.pem / sftunnel-cert.pem) van het VCC naar de FTD-apparaten
   ===automatische nadering===
   
   De hotfix-installatie biedt ook de scripts copy_sftunnel_certs.py en copy_sftunnel_certs_jumpserver.py die de overdracht van de verschillende certificaten naar systemen automatiseren waarvoor de sftunnel niet is ingeschakeld terwijl de certificaten opnieuw zijn gegenereerd. Dit kan ook worden gebruikt voor systemen die een kapotte tunnel verbinding hadden omdat het certificaat al was verlopen.
   
   U kunt het script copy_sftunnel_certs.py gebruiken wanneer de FMC zelf SSH-toegang heeft tot de verschillende FTD-systemen (en mogelijk de secundaire FMC, indien van toepassing). Als dat niet het geval is, kunt u het script (/usr/local/sf/bin/copy_sftunnel_certs_jumpserver.py) downloaden van de FMC naar een springserver met SSH-toegang tot zowel de FMC(s) als FTD-apparaten en het Python-script vanaf daar uitvoeren. Als dat ook niet mogelijk is, stel dan voor om de volgende handmatige aanpak uit te voeren. De volgende voorbeelden tonen het script copy_sftunnel_certs.py dat wordt gebruikt, maar de stappen zijn hetzelfde voor het script copy_sftunnel_certs_jumpserver.py.
   
   A. Maak een CSV-bestand op de FMC (of de jumpserver) met de apparaatinformatie (device_name, IP-adres, admin_username, admin_password) die wordt gebruikt om de SSH-verbinding te maken.
   
   Wanneer u dit uitvoert vanaf een externe server, zoals een jumpserver voor primaire FMC, moet u de primaire FMC-gegevens toevoegen als de eerste vermelding, gevolgd door alle beheerde FTD en secundaire FMC. Wanneer u dit vanaf een externe server uitvoert, zoals een jumpserver voor secundaire FMC, moet u de secundaire FMC-gegevens toevoegen als de eerste vermelding, gevolgd door alle beheerde FTD. Meer informatie over de certificaten in FMC HA is te vinden in deze sectie.
   
   i. Een bestand maken met vi devices.csv.VI-apparaten.csv
   
   ii. Hiermee wordt het lege bestand geopend (niet weergegeven) en vult u de gegevens in zoals wordt weergegeven nadat u i letter op het toetsenbord hebt gebruikt om naar de INTERACTIEVE modus te gaan (te zien onder aan het scherm).
   Apparaten.csv voorbeeld
   
   iii. Als u klaar bent, sluit u het bestand en slaat u het op met ESC, gevolgd door :wq en vervolgens Enter.
   De apparaten opslaan.csv
   
   B. Voer het script uit (vanuit root met sudo) met copy_sftunnel_certs.py devices.csv en het toont u het resultaat. Hier blijkt dat het certificaat naar FTDv correct is gepusht en dat het voor BSNS-1120-1 de SSH-verbinding met het apparaat niet kon maken.
   
   copy_sftunnel_certs.py devices.csv
   
   ===Handmatige aanpak===
   
   
   1. Druk (cat) de uitvoer af van elk bestand voor elk FTD (of secundaire FMC in HA) dat is beïnvloed (cacert.pem / sftunnel-key.pem (niet volledig weergegeven voor beveiligingsdoeleinden) / sftunnel-cert.pem) op de FMC CLI door de bestandslocatie te kopiëren van de vorige uitvoer (FAILED_PUSH-bestand).
      
      cacert.pem
      sftunnel-key.pem
      SFTUNNEL-CERT.PEM
   2. Open FTD (of secundaire FMC wanneer in FMC HA) CLI van elke respectieve FTD in de expert-modus met root-bevoegdheden via sudo su en vernieuw de certificaten met de volgende procedure.
      1. Blader naar de locatie op het lichtblauwe hoogtepunt van FAILED_PUSH-uitvoer (cd/var/sf/peers/cdb123c8-4347-11ef-aca1-f3aa241412a1 hier bijvoorbeeld, maar dit is anders voor elke FTD).
      2. Maak back-ups van bestaande bestanden.
         

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

         
         Maak back-ups van de huidige certificaten
      3. Leeg de bestanden zodat we nieuwe inhoud erin kunnen schrijven.
         

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

         
         Lege inhoud van bestaande certificaatbestanden
      4. Schrijf de nieuwe inhoud (van FMC-uitvoer) in elk van de bestanden afzonderlijk met behulp van vi cacert.pem / vi sftunnel-cert.pem / vi sftunnel-key.pem (afzonderlijke opdracht per bestand - screenshots tonen dit alleen voor cacert.pem, maar moet worden herhaald voor sftunnel-cert.pem en sftunnel-key.pem).VI cacert.pem
         1. Druk op i om naar de interactieve modus te gaan (nadat de opdracht vi is ingevoerd en u een leeg bestand ziet).
         2. Kopieer en plak de volledige inhoud (inclusief -----BEGIN CERTIFICATE------ en ----END CERTIFICATE----) in het bestand.
            Inhoud kopiëren in vi (modus INVOEGEN)
         3. Sluit en schrijf naar het bestand met ESC gevolgd door :wq en voer vervolgens in.
            ESC gevolgd door :wq om naar bestand te schrijven
      1. Valideer dat de juiste rechten (chmod 644) en eigenaars (chown root:root) zijn ingesteld voor elk van de bestanden met behulp van ls -hal. Dit is correct ingesteld wanneer we het bestaande bestand bijwerken.
         Alle certificaatbestanden bijgewerkt met eigenaars van rechten en machtigingen
         
         
   3. Start de sftunnel opnieuw op elk FTD (of secundair FMC in FMC HA) waar de sftunnel niet operationeel was, zodat de wijzigingen in het certificaat van kracht worden met het commando PMTOOL Restarbyid SFTUNNEL
      
      PMTOOL Restarbyid SFTUNNEL
      
      
3. Valideren dat alle FTD's (en secundaire FMC's) nu correct zijn aangesloten met behulp van sftunnel_status.pl-uitvoer

Oplossing 2 - Certificaat is al verlopen

In deze situatie hebben we twee verschillende scenario's. Ofwel zijn alle stunnelverbindingen nog steeds operationeel of zijn ze niet meer (of gedeeltelijk).

FTD's nog steeds verbonden via een tunnel

We kunnen dezelfde procedure toepassen als aangegeven in het gedeelte Certificaat is nog niet verlopen (ideaal scenario) - Aanbevolen aanpak.

Echter, niet upgraden of opnieuw opstarten van de FMC (of een FTD) in deze situatie als het ontkoppelt alle van de tunnel verbindingen en we moeten handmatig uitvoeren van alle van de certificaat updates op elke FTD (en secundaire FMC zoals gedekt op deze sectie). De enige uitzondering hierop zijn de vermelde Hotfix-releases, omdat deze geen herstart van de FMC vereisen.

De tunnels blijven verbonden en de certificaten worden vervangen op elk van de FTD's (en secundaire FMC wanneer in FMC HA). In het geval dat sommige certificaten niet kunnen worden ingevuld, wordt u gevraagd welke niet zijn gelukt en moet u de handmatige aanpak volgen zoals eerder aangegeven in het vorige gedeelte.

FTD's niet meer aangesloten via sftunnel

Aanbevolen aanpak

We kunnen dezelfde procedure toepassen als aangegeven in het gedeelte Certificaat is nog niet verlopen (ideaal scenario) - Aanbevolen aanpak. In dit scenario wordt het nieuwe certificaat gegenereerd op de FMC, maar kan het niet worden gekopieerd naar de apparaten omdat de tunnel al is uitgeschakeld. Dit proces kan worden geautomatiseerd met de scripts copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py

Als alle FTD-apparaten zijn losgekoppeld van de FMC, kunnen we de FMC in deze situatie upgraden omdat dit geen invloed heeft op de tunnelverbindingen. Als u nog steeds een aantal apparaten hebt aangesloten via sftunnel, moet u er rekening mee houden dat de upgrade van de FMC alle sftunnelverbindingen sluit en dat ze niet opnieuw verschijnen vanwege het verlopen certificaat. Het voordeel van de upgrade hier zou zijn dat het u een goede leidraad biedt voor de certificaatbestanden die moeten worden overgedragen aan elk van de FTD's (en secundaire FMC wanneer in FMC HA).

Handmatige nadering

In deze situatie kunt u vervolgens het script generate_certs.pl uitvoeren vanuit de FMC die de nieuwe certificaten genereert, maar u moet ze nog steeds handmatig naar elk van de FTD-apparaten (en secundaire FMC zoals beschreven in deze sectie) doorsturen. Afhankelijk van de hoeveelheid apparaten is dit uitvoerbaar of kan dit een vervelende taak zijn. Bij gebruik van de copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py scripts is dit echter sterk geautomatiseerd.

Bijlage

Certificaten gebruikt in FMC HA

De communicatie tussen primaire en secundaire FMC in een hoog beschikbaarheidspaar vindt ook plaats via de tunnel, vergelijkbaar met een FMC die communiceert naar de FTD-apparaten. De certificaatelementen (cacert.pem / sftunnel-cert.pem / sftunnel-key.pem) worden op dezelfde plaats in het VCC opgeslagen onder / var/sf/peers/<UUID-FMC>. Het is echter altijd de primaire FMC die optreedt als de manager van de secundaire FMC. Dus op deze manier is de secundaire FMC als een FTD-apparaat vanuit het perspectief van de primaire FMC. Daarom ziet u alleen het certificaat op de secundaire FMC en niet op de bestanden op de primaire FMC in de map /var/sf/peers/.

Vaak is uw secundaire FMC op een later tijdstip dan uw primaire FMC gemaakt en kan de interne CA dus nog steeds geldig zijn en nog niet verlopen zijn, in tegenstelling tot uw primaire FMC. Een handmatige switch van het actieve VCC zou daarom een mogelijkheid kunnen zijn om de impact tot een minimum te beperken in die situaties waarin het middelbaar VCC nog steeds over een geldig vaarbevoegdheidsbewijs zou beschikken en dus over de bijbehorende satellietcommunicatie met alle FTD's. Hierdoor kunt u dan nog steeds configuraties implementeren terwijl u in de tussentijd ook de fix of update op het certificaat van de primaire FMC voorbereidt. De communicatie tussen beide FMC-apparaten kon echter ook worden verbroken wanneer de tunnel werd afgebroken na het verlopen van het certificaat van de primaire FMC.

Bij het vernieuwen van de certificaten zijn er twee verschillende scenario’s:

1. Het primaire VCC-certificaat is verlopen: aangezien het secundaire VCC wordt gezien als een FTD voor het primaire VCC, moet de verlenging van het certificaat de bijgewerkte certificaten die op het primaire VCC zijn gemaakt, niet alleen naar de FTD-apparaten sturen, maar ook naar het secundaire VCC.

2. Het secundaire VCC-CA-certificaat is verlopen: in deze situatie zijn de enige updates van het certificaat die vereist zijn, die van de FTD-apparaten. Omdat de sftunnelcommunicatie tussen beide FMC's in HA gebaseerd is op het primaire FMC CA-certificaat.