Verlenging van FMC Sftunnel CA-certificaat voor FTD-connectiviteit

Inleiding

In dit document wordt de verlenging beschreven van het certificaat van de Firepower Management Center (FMC) Sftunnel Certificate Authority (CA) in relatie tot de FTD-connectiviteit (Firepower Threat Defence).

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Firepower Threat Defence
• 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 via sftunnel (Sourcefire-tunnel). Deze communicatie maakt gebruik van certificaten om het gesprek veilig te maken via een TLS-sessie. Meer informatie over de sftunnel en hoe deze zich heeft gevestigd, vindt u op deze link.

Uit de pakketopname kunt u zien 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 controleren of ze met het juiste apparaat praten en er geen afluisterapparatuur of Man-In-The-Middle (MITM)-aanval is. De communicatie wordt versleuteld met die certificaten en alleen de partij die de bijbehorende privésleutel voor dat certificaat heeft, kan het opnieuw ontsleutelen.

Certificate_exchange_server_cert

Certificate_exchange_client_cert

U kunt zien dat de certificaten worden ondertekend door dezelfde Interne certificeringsinstantie (CA) die is ingesteld op het VCC. 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 voor de ondertekening van alle certificaten voor de sftunnel (zowel het FTD als het FMC) en het certificaat dat door het FMC wordt gebruikt om alle FTD’s toe te zenden. Dit certificaat is ondertekend door de Interne CA.

Wanneer het FTD zich bij het FMC registreert, stelt het FMC tevens een certificaat op om het FTD-apparaat te activeren dat wordt gebruikt voor de verdere communicatie over de sftunnel. Dit certificaat wordt ook ondertekend door hetzelfde interne CA-certificaat. Op FMC, kunt u dat certificaat (en privé sleutel) onder /var/sf/peers/<UUID-FTD-device> en mogelijk onder certs_pushed map vinden en heet sftunnel-cert.pem (sftunnel-key.pem voor private sleutel). Op FTD kunt u de bestanden onder /var/sf/peers/<UID-FMC-device> met dezelfde naamgevingsconventie vinden.

Elk certificaat heeft echter ook een geldigheidstermijn voor veiligheidsdoeleinden. Bij de inspectie van het certificaat van InternCA zien we ook de geldigheidsperiode van 10 jaar voor het VCC InternCA, zoals blijkt uit de pakketvastlegging.

FMC-InternalCA_validiteit

Probleem

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

De apparaten verschijnen niet als uitgeschakeld op de FMC UI onder het tabblad Apparaten > Apparaatbeheer wanneer de sftunnel niet is verbonden. Het probleem dat betrekking heeft op deze vervaldatum, wordt getraceerd op Cisco-fout-id CSC08098. Houd er echter rekening mee dat alle systemen getroffen zijn, zelfs wanneer u een vaste release van het defect uitvoert. Meer informatie over deze oplossing vindt u in het gedeelte Oplossing.

Uitgeschakelde apparaten

Het VCC vernieuwt de CA niet automatisch en geeft de certificaten opnieuw uit aan de FTD-apparatuur. Er is ook geen gezondheidswaarschuwing van het VCC waaruit blijkt dat het certificaat vervalt. Cisco bug-id CSCwd08448 wordt in dit opzicht gevolgd om in de toekomst een gezondheidswaarschuwing voor de FMC UI te geven.

Wat gebeurt er na de vervaldatum?

Aanvankelijk gebeurt er niets en de communicatiekanalen voor de veilige tunnel blijven functioneren zoals voorheen. Wanneer echter de sftunnelcommunicatie tussen FMC en FTD-apparaten wordt verbroken en de verbinding opnieuw tot stand wordt gebracht, is het mislukt en kunt u logregels waarnemen op het berichtenlogbestand dat naar het verlopen van het certificaat wijst. Merk op dat de sftunnelcommunicatie (gebruikt voor High-Availability (HA) sync) tussen primair en secundair VCC ook mogelijk wordt beïnvloed zoals beschreven in dit deel.

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

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 sftunnelcommunicatie kan om verschillende redenen worden verbroken:

• Communicatieverlies door verlies van netwerkconnectiviteit (potentieel slechts tijdelijk)
• Herstart van het FTD of het FMC
  • Verwachte: handmatige herstart, upgrades, handmatige herstart van sftunnelproces op FMC of FTD (bijvoorbeeld door pmtool restartbyid sftunnel)
  • Onverwachte: terugtracebacks, stroomuitval

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

Hoe om snel te verifiëren als het certificaat is verlopen of wanneer het verloopt?

De gemakkelijkste manier is om deze opdrachten uit te voeren in de SSH-sessie van het FMC:

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

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

Niet meer na

Als u wilt dat er één opdracht wordt uitgevoerd die u onmiddellijk de hoeveelheid dagen geeft waarvoor het certificaat nog 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

Er wordt een voorbeeld getoond van een installatie waarbij het certificaat nog meerdere jaren geldig is.

Certificaat_expiratie_opdracht

Hoe krijg ik in de toekomst bericht over een aanstaande certificaatvervaldatum?

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

De eerste methode is via het tabblad Taak. Dit bericht is plakkerig en beschikbaar voor de gebruiker tenzij expliciet gesloten. Het melding pop-up verschijnt ook en is beschikbaar tot expliciet gesloten door de gebruiker. Het verschijnt altijd als een fout.

Melding bij afloop van taak tabblad

De tweede methode is via Health Alert. Dit verschijnt in het tabblad Gezondheid, maar dit is niet kleverig en vervangt of verwijdert als de gezondheidsmonitor wordt uitgevoerd, wat standaard elke 5 minuten is. Het toont ook een melding pop-up die expliciet door de gebruiker moet worden gesloten. Dit kan zowel als fout (wanneer verlopen) als waarschuwing (wanneer het verlopen is) weergeven.

Bericht bij verlopen op het tabblad Gezondheid

Waarschuwingsmelding bij pop-up van gezondheidswaarschuwing

Foutmelding bij pop-up van gezondheidswaarschuwing

Oplossing 1 - Het certificaat is nog niet verlopen (ideaal scenario)

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

Aanbevolen aanpak

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

Alvorens verder te gaan, moet u de hotfix voor uw bepaalde versie installeren zoals hier vermeld. Het voordeel is dat deze hotfixes geen reboot van het VCC en dus potentiële kapotte sftunnelcommunicatie vereisen wanneer het certificaat al is verlopen. De beschikbare hotfixes (downloadlinks zijn voor virtueel FMC, voor hardware FMC kijk op de geschikte 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 softwareonderhoud
• 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 het FMC nu het script generation_certs.pl dat:

1. Hiermee wordt de interne CA hersteld
2. Herstelt de sftunnelcertificaten die zijn ondertekend door dit nieuwe InternalCA
3. Duw de nieuwe certificaten voor sftunnels en privésleutels over naar de respectieve FTD-apparaten (en eventueel het secundaire FMC) (wanneer de sftunnel operationeel is)

Daarom wordt aanbevolen (indien mogelijk):

1. Installeer de toepasselijke hotfix voor uw versietrain
2. Maak een back-up op het VCC
3. Valideer alle huidige Sftunnelverbindingen met behulp van het script sftunnel_status.pl in het VCC (van expert mode)
4. Draai het script vanuit de expert mode met generation_certs.pl
5. Inspecteer het resultaat om te valideren of handmatige handelingen nodig zijn (wanneer de apparatuur niet met het VCC is verbonden) [zie verder hieronder]
6. Voer sftunnel_status.pl uit vanuit het VCC om te controleren of alle sftunnelverbindingen goed lopen

Generate_certs.pl script

In het voorbeeld hier ziet u dat het maakt een logbestand op /var/log/sf/sfca_generation.log, geeft aan sftunnel_status.pl te gebruiken, geeft de verlooptijd aan op de InternalCA en geeft aan of er fouten zijn opgetreden. Hier is het er bijvoorbeeld niet in geslaagd om de certificaten over te brengen naar apparaat BSNS-1120-1 en EMEA-FPR3110-08, wat wordt verwacht omdat de sftunnelbuis was neergehaald voor die apparaten.

U voert de volgende stappen uit om de tunnel voor de mislukte verbindingen te corrigeren:

1. Open op FMC CLI het bestand MISLUKTE_PUSH met cat /var/tmp/certs/1728303362/FAIL_PUSH (number value vertegenwoordigt unix time, dus controleer de uitvoer van de vorige opdracht in uw systeem) die het volgende formaat heeft: FTD_UID FTD_NAME FTD_IP SOURCE_PATH_ON_FMC DESTINY_PATH_ON_FTD
   
   MISLUKTE_DRUK
   
   
2. Overdracht van die nieuwe certificaten (cacert.pem / sftunnel-key.pem / sftunnel-cert.pem) van het FMC 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 omhoog was terwijl de certificaten werden geregenereerd. Dit kan ook worden gebruikt voor systemen die een verbroken verbinding hadden omdat het certificaat al was verlopen.
   
   U kunt het script copy_sftunnel_certs.py gebruiken wanneer het VCC zelf SSH-toegang heeft tot de verschillende FTD-systemen (en mogelijk het secundaire FMC, indien van toepassing). Als dat niet het geval is, kunt u het script (/usr/local/sf/bin/copy_sftunnel_certs_jumpserver.py) van het FMC downloaden naar een springserver die SSH-toegang heeft tot zowel het FMC (de FMC's) als de FTD-apparaten en het Python-script vanaf daar uitvoeren. Als dat ook niet mogelijk is, stel dan voor om de handmatige benadering uit te voeren die hieronder wordt getoond. De volgende voorbeelden tonen het script copy_sftunnel_certs.py dat gebruikt wordt, maar de stappen zijn hetzelfde voor het script copy_sftunnel_certs_jumpserver.py.
   
   A. Maak een CSV-bestand op het FMC (of springserver) dat de apparaatinfo bevat (device_name, IP-adres, admin_username, admin_password) die gebruikt wordt om de SSH-verbinding te maken.
   
   Wanneer u dit uitvoert vanaf een externe server zoals een springserver voor Primary FMC, zorg er dan voor dat u de primaire FMC-gegevens toevoegt als de eerste vermelding, gevolgd door alle beheerde FTD en secundaire FMC. Wanneer u dit uitvoert vanaf een externe server zoals een springserver voor secundair FMC, zorg er dan voor dat u de secundaire FMC-gegevens toevoegt als de eerste vermelding gevolgd door alle beheerde FTD. Meer informatie over de certificaten in FMC HA vindt u in deze sectie.
   
   i. Maak een bestand met vi devices.csv.vi-apparaten.csv
   
   ii. Hiermee wordt het lege bestand geopend (niet weergegeven) en u vult de details in zoals weergegeven nadat u in de letter op het toetsenbord hebt gebruikt om naar de INTERACTIEVE modus te gaan (zie onder op het scherm).
   devices.csv voorbeeld
   
   iii. Als u klaar bent, sluit u het bestand en slaat u het op met behulp van ESC gevolgd door :wq en vervolgens ENTER.
   De apparaten opslaan.csv
   
   B. Start het script (vanaf root met behulp van sudo) met copy_sftunnel_certs.py devices.csv en het toont je het resultaat. Hier toont het aan dat het certificaat naar FTDv correct werd geduwd en dat voor BSNS-1120-1 het de verbinding van SSH met het apparaat niet kon maken.
   
   copy_sftunnel_certs.py devices.csv
   
   ===Handmatige nadering===
   
   
   1. Print (cat) de uitvoer van elk van de bestanden voor elk FTD (of secundair FMC in HA) beïnvloed (cacert.pem / sftunnel-key.pem (niet volledig getoond voor veiligheidsdoeleinden) / sftunnel-cert.pem) op de FMC CLI door de bestandsplaats van vorige uitvoer te kopiëren (ERROR_PUSH-bestand).
      
      cacert.pem
      sftunnel-key.pem
      sftunnel-cert.pem
   2. Open FTD (of secundair FMC wanneer in FMC HA) CLI van elk respectieve FTD op deskundige wijze met wortelvoorrechten door sudo su en vernieuw de certificaten met de volgende procedure.
      1. Blader naar de locatie op het lichtblauwe hoogtepunt van DE OUTPUT VAN FAILLIET_PUSH (cd/var/sf/peers/cdb123c8-4347-11ef-aca1-f3a241412a1 hier bijvoorbeeld, maar dit is anders voor elke FTD).
      2. Maak een back-up van de 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 een back-up van de huidige certificaten
      3. Leeg de bestanden zodat we nieuwe inhoud in ze 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 deze om in de interactieve modus te gaan (nadat de vi-opdracht is ingevoerd en u een leeg bestand ziet).
         2. Kopieer de gehele inhoud (inclusief -----BEGIN CERTIFICAAT----- en -----END CERTIFICAAT-----) in het bestand.
            Kopieert inhoud in vi (INSERT mode).
         3. Sluit het bestand en schrijf naar het bestand met ESC gevolgd door :wq en voer het vervolgens in.
            ESC gevolgd door :wq om naar bestand te schrijven
      1. Bevestig dat de juiste rechten (chmod 644) en eigenaars (chown root:root) zijn ingesteld voor elk van de bestanden met ls -hal. Dit is correct ingesteld eigenlijk wanneer we het bestaande bestand updaten.
         Alle certificaatbestanden bijgewerkt met de juiste eigenaars en machtigingen
         
         
   3. Start de sftunnel opnieuw op elk FTD (of secundair FMC wanneer in FMC HA) waar de sftunnel niet operationeel was voor de wijzigingen in het certificaat die van kracht worden met het commando pmtool restartbyid-sftunnel
      
      pmtool restartbyid-sftunnel
      
      
3. Controleer of alle FTD’s (en secundaire FMC’s) nu correct zijn aangesloten met behulp van sftunnel_status.pl-uitvoer

Oplossing 2 - Het certificaat is al verlopen

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

FTD's nog steeds verbonden via sftunnel

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

Verander of herstart het VCC (of een FTD) in deze situatie echter NIET omdat alle verbindingen met de sftunnels worden verbroken en we alle certificaatupdates handmatig moeten uitvoeren op elk FTD (en secundair FMC zoals behandeld in deze sectie). De enige uitzondering hierop zijn de vermelde Hotfix-releases, aangezien ze geen herstart van het VCC vereisen.

De tunnels blijven met elkaar verbonden en de certificaten worden vervangen op elk van de FTD’s (en secundair FMC wanneer in FMC HA). In het geval dat sommige certificaten niet worden ingevuld, wordt u gevraagd om de certificaten die niet zijn ingevuld en moet u de handmatige aanpak te volgen zoals eerder aangegeven in de vorige sectie.

FTD's niet meer verbonden via sftunnel

Aanbevolen aanpak

We kunnen dezelfde procedure toepassen als aangegeven in het certificaat is nog niet verlopen (ideaal scenario) - Aanbevolen aanpak sectie. In dit scenario wordt het nieuwe certificaat wel op het VCC gegenereerd, maar kan niet naar de apparatuur worden gekopieerd, aangezien de tunnel reeds is ingeklapt. Dit proces kan worden geautomatiseerd met de scripts copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py

Indien alle FTD-apparatuur wordt losgekoppeld van het FMC, kunnen we het FMC in deze situatie verbeteren, aangezien het geen invloed heeft op de verbindingen in de sftunnels. Als u nog steeds bepaalde apparaten hebt aangesloten door sftunnel, dan moet u zich ervan bewust zijn dat de upgrade van de FMC alle sftunnelverbindingen sluit en ze komen niet weer boven als gevolg van het verlopen certificaat. Het voordeel van de upgrade hier zou zijn dat het geeft u een goede leidraad over de certificaatbestanden die moeten worden overgedragen naar elk van de FTD's (en secundair FMC wanneer in FMC HA).

Handmatige nadering

In deze situatie kunt u het script generation_certs.pl uitvoeren vanuit het VCC dat de nieuwe certificaten genereert, maar u moet ze nog steeds handmatig doordrukken naar elk FTD (en secundair FMC zoals behandeld in deze paragraaf) apparaat. Afhankelijk van de hoeveelheid apparaten, is dit doenbaar of kan een vervelende taak zijn. Bij gebruik van de scripts copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py is dit echter sterk geautomatiseerd.

Bijlage

Certificaten gebruikt in FMC HA

De communicatie tussen primair en secundair FMC in high-Availability-paar gebeurt ook via de sftunnelverbinding, net als bij een FMC dat 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 het belangrijkste VCC dat optreedt als beheerder van het secundaire VCC. Op deze manier is het secundaire VCC als een FTD-apparaat vanuit het perspectief van het primaire VCC. Daarom ziet u alleen het certificaat op het secundaire VCC en niet op de bestanden op het primaire VCC op de map /var/sf/peers/.

Vaak is uw secundaire VCC op een later tijdstip dan uw primaire VCC gecreëerd en kan de interne VCC dus nog geldig zijn en nog niet verlopen, in tegenstelling tot uw primaire VCC. Daarom zou een handmatige switch van het actieve VCC een mogelijkheid kunnen zijn om de gevolgen te minimaliseren in die situaties waarin het secundaire VCC nog steeds over een geldig certificaat zou beschikken en daarmee dus nog vrije tunnelcommunicatie met alle FTD’s zou hebben. Dit zou u dan nog steeds in staat stellen om configuraties in te zetten, terwijl in de tussentijd ook de oplossing of update op het certificaat van het primaire VCC wordt voorbereid. De communicatie tussen beide VCC-voorzieningen kon echter ook worden verbroken wanneer de tunnel was gesloopt na het verstrijken van het certificaat van het eerste VCC.

Tijdens het vernieuwingsproces van de certificaten zijn er twee verschillende scenario’s:

1. Primair certificaat van CCA van het VCC is verlopen: Aangezien het secundaire VCC als een VHZ wordt beschouwd ten opzichte van het primaire VCC, moet de verlenging van het certificaat de bijgewerkte certificaten die op het primaire VCC zijn opgesteld, niet alleen naar de FTD-apparatuur, maar ook naar het secundaire VCC sturen.

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