Problem

Fehlermeldung

Die folgende Meldung wird den Anwendern angezeigt. Im Browser ist weder ein Zertifikat sichtbar noch eine Fehlermeldung zu Zertifikaten ersichtlich, was darauf hindeutet, dass die Verbindung bereits vorher abbricht. Auffällig ist, dass nicht alle Webseiten betroffen sind und auch nicht alle Browser-Varianten. Der Edge-Browser in der aktuellen Version zeigt dieses Problem nicht, ebenso wenig ein älterer Firefox. Aktualisierte Versionen verschiedener Browser führen jedoch zu dem beschriebenen Fehler.

Betroffene Browser

Fortinet hat derweil eine Liste betroffener Browser veröffentlicht. Diese lassen sich wie folgt zusammenfassen.

• Google Chrome 131
• Firefox 132
• Microsoft Edge 131.0.2903.48 (Stable)

Ursache

Der Auslöser für dieses Problem hängt mit der Einführung von Modular-Lattice Key Encapsulation Mechanism (ML-KEM) für den post-quantenfähigen TLS-Schlüsselaustausch zusammen. Diese Methode hat kürzlich X25519Kyber768 für hybriden post-quantenfähigen Schlüsselaustausch in Chromium-basierten Browsern ersetzt. Das Problem wird derzeit bei Fortinet im Case #1097642 untersucht.

SSL-Inspection in den UTM/NGFW-Modes

Fortinet hat angekündigt, an Lösungen innerhalb der IPS-Engine (Versionen 7.0 bis 7.6) zu arbeiten, was darauf hindeutet, dass der Support für die ML-KEM-Methode derzeit speziell in der IPS-Engine problematisch ist. Ein von Fortinet empfohlener Workaround besteht darin, auf den Proxy-Modus umzuschalten, da in diesem Modus die Entschlüsselung außerhalb der IPS-Engine stattfindet.

Dies ist eine gute Gelegenheit, die Unterschiede zwischen den verschiedenen Betriebsmodi der SSL-Inspection zu beleuchten. Hierzu führe ich aus den Herstellerdokumenten die Flow-Diagramme auf und verweise den jeweiligen Anwendungspunkt der SSL-Inspection und IPS-Engine.

Lösungen

Fortinet bietet mehrere Workarounds für das beschriebene Problem an. In meinem Blog möchte ich mich jedoch auf die FortiGate-basierten Lösungen konzentrieren, da diese aus meiner Sicht einfacher umzusetzen sind und keine Änderungen an Browsern oder Betriebssystemen erfordern. Der Fokus liegt darauf, praktikable Lösungen direkt auf der Firewall-Ebene anzuwenden, um die Sicherheit und Funktionalität so effizient wie möglich sicherzustellen.

Inspection-Mode auf Proxy-based umstellen

Das aus meiner Sicht einfachste und effektivste Verfahren zur Lösung des Problems ist die Umstellung des Modus auf Proxy-based. Der Fehler tritt ausschließlich in Kombination mit Flow-based-Policies und aktivierter SSL-Deep-Inspection auf. Durch die Umstellung auf den Proxy-Modus bleibt die Prüfung der SSL-Verbindung vollständig erhalten, ohne dass Ausnahmen definiert werden müssen.

Zusätzlich bietet der Proxy-Modus potenzielle Vorteile, da er die gründlichste Inspektion für UTM- und NGFW-Funktionen ermöglicht. Insbesondere bei Richtlinien, die den Schutz vor bösartigen Inhalten gewährleisten sollen, wird grundsätzlich empfohlen, den Proxy-Modus einzusetzen. Er sorgt für eine umfassendere Sicherheitskontrolle und reduziert das Risiko, dass Bedrohungen unbemerkt bleiben.

SSL-Inspection-Ausnahme festlegen

Fortinet schlägt als zweite Variante vor, eine Ausnahme für die betroffenen oder relevanten Webseiten im SSL-Inspection-Profil einzurichten. Dadurch wird die SSL-Inspection für diese Seiten komplett deaktiviert, selbst wenn die zugehörige Firewall-Regel diese Funktion ursprünglich verlangt. Diese Methode kann jedoch zu einem erhöhten administrativen Aufwand führen, da kontinuierlich Anpassungen erforderlich sind, bis ein langfristiger Fix von Fortinet bereitgestellt wird.

SSL-Inspection abschalten

Anstatt für einzelne Webseiten nun Ausnahmen zu definieren oder den Inspektionsmodus auf Proxy-based umzustellen, besteht auch die Möglichkeit, die SSL-Inspektion vollständig zu deaktivieren oder auf das Verfahren der einfachen Zertifikatsüberprüfung (Certificate Inspection) umzustellen. Diese Ansätze verringern jedoch das allgemeine Sicherheitsniveau erheblich. Daher sollten sie nur in gut begründeten Ausnahmefällen in Betracht gezogen werden, da es sicherere und effektivere Alternativen gibt.

Quellen

• ERR_SSL_PROTOCOL_ERROR when using Flow-based Deep Inspection due to ML-KEM post-quantum TLS key exchange
• Google Online Security Blog: A new path for Kyber on the web
• UTM/NGFW packet flow: flow-based inspection | Fortinet Document Library
• Inspection mode feature comparison | Fortinet Document Library
• Exempting applications/domains/websites from SSL Inspection | Fortinet Community

Der Beitrag FortiGate – ERR_SSL_PROTOCOL_ERROR nach Browser-Updates mit aktiver SSL-Deep-Inspection erschien zuerst auf Maximilian Krieg.

Fortinet FortiGate

Die FortiGate-Firewall ist ein Next Generation Firewall (NGWF), die von Fortinet entwickelt wurde. Sie bietet umfassenden Schutz für Netzwerke, indem sie den Datenverkehr überwacht, analysiert und steuert.

Allgemein

• Network Interface Card NIC commands
• How to clear interface counters from CLI

FortiOS 6.4

• FortiOS v6.4 Cheatsheet | Tech Blog (boll.ch)
• FortiOS v6.4 CLI reference | Fortinet Document Library

FortiOS 7.0

• FortiOS v7.0 Cheatsheet | Tech Blog (boll.ch)
• FortiOS v7.0 CLI reference | Fortinet Document Library

FortiOS 7.2

• FortiOS v7.2 Cheatsheet | Tech Blog (boll.ch)
• FortiOS v7.2 CLI reference | Fortinet Document Library

FortiOS 7.4

• FortiOS v7.4 Cheatsheet | Tech Blog (boll.ch)
• FortiOS v7.4 CLI reference | Fortinet Document Library
• FortiOS v7.4 CLI troubleshooting cheat sheet | Fortinet Document Library

FortiOS 7.6

• FortiOS v7.6 CheatSheet | Tech Blog (boll.ch)
• FortiOS v7.6 CLI reference | Fortinet Document Library

Fortinet FortiAnalyzer

Der FortiAnalyzer ist eine leistungsstarke Plattform für Protokollverwaltung, Analysen und Berichterstattung. Er bietet Organisationen eine einzige Konsole zur Verwaltung, Automatisierung, Orchestrierung und Reaktion.

FortiAnalyzer 6.4

• FortiAnalyzer v6.4 Cheatsheet | Tech Blog (boll.ch)
• FortiAnalyzer v6.4 | Fortinet Document Library

FortiAnalyzer 7.0

• FortiAnalyzer v7.0 Cheatsheet | Tech Blog (boll.ch)
• FortiAnalyzer v7.0 CLI reference | Fortinet Document Library

FortiAnalyzer 7.2

• FortiAnalyzer v7.2 CLI reference | Fortinet Document Library

FortiAnalyzer 7.4

• FortiAnalyzer v7.4 CLI reference | Fortinet Document Library

Fortinet FortiManager

Der FortiManager ist eine zentrale Plattform zur Verwaltung von Fortinet-Geräten und Richtlinien in verschiedenen Umgebungen. Er ermöglicht die zentrale Administration von unter anderem FortiGate-Firewalls, FortiAnalyzer, FortiSwitches, FortiAPs und FortiExtender-Geräten.

FortiManager 6.4

• FortiManager v6.4 CLI reference | Fortinet Document Library

FortiManager 7.0

• FortiManager v7.0 Cheatsheet | Tech Blog (boll.ch)
• FortiManager v7.0 CLI reference | Fortinet Document Library

FortiManager 7.2

• FortiManager v7.2 CLI reference | Fortinet Document Library

FortiManager 7.4

• FortiManager v7.4 CLI reference | Fortinet Document Library

Der Beitrag Fortinet – Cheatsheets für CLI-Befehle erschien zuerst auf Maximilian Krieg.

Die globalen Einstellungen betreffen die Admin-Oberfläche. Wir haben hier zuvor manuelle Parameter gesetzt für die TLS-Mindeststandards, wechseln nun jedoch auf den Strong-Crypto-Befehl. Das Verbot von RSA-Chiffren ist zwar implizit durch die anderen Parameter gegeben, wurde jedoch bei einem Audit als wünschenswert festgelegt und wird daher beibehalten. Ebenfalls werden mehrere Hash-Verfahren deaktiviert, um das unsichere AES-128-CBC abzuschalten. Wie in einem Technical Tip beschrieben, kann AES-128-CBC nicht selbst deaktiviert werden, weshalb ein Workaround über die Hash-Verfahren genutzt werden kann. Einen exklusiven Umstieg auf TLS 1.3, welches die unsicheren Chiffren nicht mehr unterstützt, haben wir auch diskutiert, jedoch noch nicht ins Auge gefasst.

config system global
    set strong-crypto enable
    set ssl-static-key-ciphers disable
    set admin-https-ssl-banned-cipher RSA SHA1 SHA256 SHA384
    set dh-params 8192
end

Wenn die starke Verschlüsselung (Strong-Crypto) aktiviert ist, sind nur noch TLS 1.2 und TLS 1.3 zulässig. Der Strong-Crypto-Befehl hat jedoch keine Auswirkung auf die SSL-VPN-Verschlüsselungsstufe oder -Chiffren. Für die SSL-VPN-Einstellungen setzen wir daher TLS 1.2 als Mindeststandard und verbieten die gleichen Chiffren wie zuvor. Über den Algorith-High-Befehl werden ebenfalls ältere und unsichere Chiffren verboten.

config vpn ssl setting
    set algorithm high
    set ssl-min-proto-ver tls1-2
    set banned-cipher RSA SHA1 SHA256 SHA384
end

Abschließend kontrollieren wir mithilfe von Qualys den neuen Status und führen einen erneuten Scan durch. Es ergibt sich nun eine Bewertung mit A+ mit voller Bewertung in drei Kategorien.

Quellen

• Technical Tip: Disable AES CBC ciphers for SSL VPN and Admin GUI (HTTPS) Access
• Technical Tip: Cipher suites offered by FortiGate
• Hardening | FortiGate / FortiOS 7.4.0 | Fortinet Document Library
• FortiGate encryption algorithm cipher suites | FortiGate / FortiOS 7.4.2 | Fortinet Document Library
• BSI-TR-02102.pdf (bund.de)

Der Beitrag Fortinet – Chiffren für SSL VPN und Admin GUI härten erschien zuerst auf Maximilian Krieg.

Analyse

Zunächst unterziehen wir die letzten Ereignisse im Zusammenhang mit dem betroffenen Zertifikat einer sorgfältigen Prüfung, um mögliche weiterführende Hinweise zu identifizieren.

diagnose sys acme status-full <Certificate’s CN domain>

In diesem Kontext fällt auf, dass seit der Ausstellung beziehungsweise dem letzten Erneuerungsvorgang keine relevanten Ereignisse aufgezeichnet wurden. Ebenfalls interessant ist, dass der Error-Counter den Wert 0 aufweist. Die Ausgabe wurde selbstverständlich aus Gründen der Vertraulichkeit durch die Anpassung von Geräte- und Kundennamen modifiziert.

FGT # diagnose sys acme status-full fgt.customer.com
{
  "name": "fgt.customer.com",
  "finished": true,
  "notified": false,
  "last-run": "Tue, 24 Oct 2023 11:07:21 GMT",
  "valid-from": "Tue, 24 Oct 2023 10:07:29 GMT",
  "errors": 0,
  "last": {
    "status": 0,
    "detail": "The certificate for the managed domain has been renewed successfully and can be used (valid since Tue, 24 Oct 2023 10:07:29 GMT). A graceful server restart now is recommended.",
    "valid-from": "Tue, 24 Oct 2023 10:07:29 GMT"
  },
  "log": {
    "entries": [
      {
        "when": "Tue, 24 Oct 2023 11:07:31 GMT",
        "type": "message-renewed"
      },
      {
        "when": "Tue, 24 Oct 2023 11:07:31 GMT",
        "type": "finished"
      },

Im folgenden Schritt überprüfen wir, ob eine erfolgreiche PING-Kommunikation mit den für das Erneuerungsvorhaben zuständigen LetsEncrypt-Servern möglich ist. Ebenfalls prüfen wir die korrekte Funktionalität der Namensauflösung auf der Firewall, die für diesen Zweck erforderlich ist.

execute ping acme-v02.api.letsencrypt.org
PING 172.65.32.248 (172.65.32.248): 56 data bytes
64 bytes from 172.65.32.248: icmp_seq=0 ttl=255 time=22.3 ms
64 bytes from 172.65.32.248: icmp_seq=1 ttl=255 time=22.2 ms
64 bytes from 172.65.32.248: icmp_seq=2 ttl=255 time=22.2 ms
64 bytes from 172.65.32.248: icmp_seq=3 ttl=255 time=22.2 ms
64 bytes from 172.65.32.248: icmp_seq=4 ttl=255 time=22.2 ms
--- 172.65.32.248 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 22.2/22.2/22.3 ms

Sowohl die Namensauflösung als auch die Erreichbarkeit sind gewährleistet. Daher führen wir eine erneute Überprüfung des Status des ACME-Clients durch und stellen bei genauer Inspektion fest, dass überhaupt kein Interface definiert ist.

FGT # get system acme status
Listening on interfaces:        None
ACME certificates registered:   1
ACME challenge type:            http-01

Wir gleichen dies erneut mit der Konfiguration ab, und die Überprüfung bestätigt die fehlerhafte Konfiguration.

FGT # config system acme
FGT (acme) # show
config system acme
    config accounts
        edit "ACME-.letsencrypt.org-0000"
            set status "valid"
            set ca_url "https://acme-v02.api.letsencrypt.org/directory"
            set email "mail@customer.com"
        next
    end
end

Auch hier erkennen wir, dass kein Interface konfiguriert ist, über das der ACME-Client die Zertifikatsvalidierung durchführen soll. Zur Fehlerbehebung setzen wir daher das entsprechende Interface im ACME-Client.

FGT # config system acme
FGT (acme) # set interface wan
FGT (acme) # end

Renewal-Prozess

Nachdem wir das Renewal manuell initiiert haben, überprüfen wir den Status des Zertifikats erneut mithilfe des Diagnose-Befehls. Der folgende Auszug veranschaulicht den vollständigen und korrekten Zertifizierungsdialog.

FGT # diagnose sys acme status-full fgt.customer.com
{
  "name": "fgt.customer.com",
  "finished": true,
  "notified": false,
  "next-run": "Wed, 27 Dec 2023 08:54:24 GMT",
  "last-run": "Tue, 26 Dec 2023 09:54:20 GMT",
  "valid-from": "Wed, 27 Dec 2023 08:54:24 GMT",
  "errors": 0,
  "last": {
    "status": 0,
    "detail": "The certificate for the managed domain has been renewed successfully and can be used from Wed, 27 Dec 2023 08:54:24 GMT on.",
    "valid-from": "Wed, 27 Dec 2023 08:54:24 GMT"
  },
  "log": {
    "entries": [
      {
        "when": "Tue, 26 Dec 2023 09:54:26 GMT",
        "type": "finished"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:26 GMT",
        "type": "progress",
        "detail": "The certificate for the managed domain has been renewed successfully and can be used from Wed, 27 Dec 2023 08:54:24 GMT on."
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:25 GMT",
        "type": "progress",
        "detail": "Retrieving certificate chain for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:25 GMT",
        "type": "progress",
        "detail": "Waiting for finalized order to become valid"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:24 GMT",
        "type": "progress",
        "detail": "Submitting CSR to CA for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:24 GMT",
        "type": "progress",
        "detail": "Creating CSR for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:24 GMT",
        "type": "progress",
        "detail": "Finalizing order for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:23 GMT",
        "type": "progress",
        "detail": "Waiting for order to become ready"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:23 GMT",
        "type": "progress",
        "detail": "Monitoring challenge status for fgt.customer.com: domain authorization for fgt.customer.com is valid"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:23 GMT",
        "type": "progress",
        "detail": "Monitoring challenge status for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:22 GMT",
        "type": "progress",
        "detail": "Starting challenges for domains"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:22 GMT",
        "type": "progress",
        "detail": "Loaded order from staging"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:21 GMT",
        "type": "progress",
        "detail": "Selecting account to use for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:21 GMT",
        "type": "progress",
        "detail": "Driving ACME protocol for renewal of fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:20 GMT",
        "type": "progress",
        "detail": "Contacting ACME server for fgt.customer.com at https://acme-v02.api.letsencrypt.org/directory"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:20 GMT",
        "type": "progress",
        "detail": "Assessing current status"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:20 GMT",
        "type": "progress",
        "detail": "Checking staging area"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:20 GMT",
        "type": "progress",
        "detail": "Monitoring challenge status for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:20 GMT",
        "type": "starting"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:19 GMT",
        "type": "progress",
        "detail": "Monitoring challenge status for fgt.customer.com: domain authorization for fgt.customer.com is valid"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:19 GMT",
        "type": "progress",
        "detail": "Monitoring challenge status for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:18 GMT",
        "type": "progress",
        "detail": "Setting up challenge 'http-01' for domain fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:18 GMT",
        "type": "progress",
        "detail": "Starting challenges for domains"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:17 GMT",
        "type": "progress",
        "detail": "Creating new order"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:16 GMT",
        "type": "progress",
        "detail": "Selecting account to use for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:16 GMT",
        "type": "progress",
        "detail": "Driving ACME protocol for renewal of fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:16 GMT",
        "type": "progress",
        "detail": "Resetting staging for fgt.customer.com"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:15 GMT",
        "type": "progress",
        "detail": "Contacting ACME server for fgt.customer.com at https://acme-v02.api.letsencrypt.org/directory"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:15 GMT",
        "type": "progress",
        "detail": "Assessing current status"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:15 GMT",
        "type": "progress",
        "detail": "Resetting staging area"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:15 GMT",
        "type": "progress",
        "detail": "Checking staging area"
      },
      {
        "when": "Tue, 26 Dec 2023 09:54:15 GMT",
        "type": "starting"
      }
    ]
  }
}

Das Zertifikat ist somit erfolgreich neu verifiziert und ausgestellt worden. Es ist jedoch zu beachten, dass das Startdatum des neuen Zertifikats nicht sofort wirksam wird, sondern erst im Rahmen des nächsten Durchlaufs des ACME-Clients übernommen wird. Die relevanten Termine sind im Header des Auszugs angegeben.

• last-run: Tue, 26 Dec 2023 09:54:20 GMT
• next-run: Wed, 27 Dec 2023 08:54:24 GMT
• valid-from: Wed, 27 Dec 2023 08:54:24 GMT

Daher überprüfen wir am 27. Dezember 2023 den Status des Zertifikats auf der FortiGate. Durch das Aufrufen der durch dieses Zertifikat geschützten Inhalte bestätigen wir, dass nun das korrekte Zertifikat verwendet wird. Es ist jedoch zu beachten, dass die Zeitzone GMT verwendet wird.

Weitere Ursachen

Während meiner Recherche und Analyse identifizierte ich die folgenden Fehlerquellen als häufige Ursachen:

1. Falsche Konfiguration des ACME-Clients oder fehlende Definition von Interfaces.
   • Überprüfen Sie die Einstellungen des ACME-Clients und stellen Sie sicher, dass die relevanten Interfaces ordnungsgemäß konfiguriert sind.
2. Fehlende oder nicht funktionierende DNS-Server.
   • Prüfen Sie, ob DNS-Server der FortiGate korrekt konfiguriert sind und Namensauflösung möglich ist.
3. Probleme mit der Certificate Authority (CA) von LetsEncrypt und der Vertrauensstellung der FortiGate.
   • Stellen Sie sicher, dass die FortiGate das CA-Zertifikat von LetsEncrypt korrekt vertraut.
4. Explizite Verbote durch Local-In-Policy für Verbindungen zu Port 80/443.
   • Überprüfen Sie die Local-In-Policy, um sicherzustellen, dass keine Einschränkungen für die Kommunikation zu Port 80/443 bestehen.
5. Konflikte mit anderen Diensten auf Port 443, wie SSL-VPN, Virtual Server oder Virtual IP.
   • Stellen Sie sicher, dass keine Konflikte mit anderen Diensten auf demselben Port bestehen.
6. Vorhandensein von Proxy- und Firewall-Diensten vor der FortiGate mit restriktiven Regelwerken.
   • Überprüfen Sie die Konfiguration von Proxy- und Firewall-Diensten vor der FortiGate auf mögliche Restriktionen in deren Regelwerken.
7. Firmware-Bugs, insbesondere in Version 7.2.3 mit Problemen bei mehreren hinterlegten Interfaces.
   • Überprüfen Sie, ob bekannte Bugs in der Firmware, insbesondere in der Version 7.2.3, vorliegen und ggf. auf eine aktualisierte Firmware-Version upgraden.
8. Generelle Bugs in der eingesetzten Firmware.
   • Konsultieren Sie die Release Notes der Firmware, um festzustellen, ob bekannte Bugs existieren und prüfen Sie gegebenenfalls auf verfügbare Updates.

Quellen

• https://community.fortinet.com/t5/FortiGate/Technical-Tip-Expiring-Let-s-Encrypt-Certificates/ta-p/198419
• https://letsencrypt.org/docs/allow-port-80/
• https://blog.pingus.de/2022/01/28/enable-lets-encrypt-certificate-on-ssl-vpn-enabled-fortigate-interface/
• https://blog.andreas-schreiner.de/2021/08/31/lets-encrypt-zertifikat-fuer-fortigate-ssl-vpn-vips-und-web-ui/

Der Beitrag Fortinet – LetsEncrypt-Zertifikat erneuert sich nicht erschien zuerst auf Maximilian Krieg.

Monitoring-Schwellwerte

Dem Monitoring-Team stellen wir folgende Schwellwerte als Empfehlung für sämtliche LetsEncrypt-Zertifikate des Kunden, unabhängig davon welches System sie präsentiert oder verlängert, zur Verfügung:

• Warnung – Ab 28 bis 30 Tagen
• Fehler – Ab 5 bis 7 Tagen

Erst bei Eintreten des Fehlerzustands im Monitoring-System sollte ein Ticket erzeugt werden. 5 bis 7 Tage sollten genug Zeit sein den Prozess manuell zu starten oder in die Fehleranalyse zu gehen, warum der Automated Certificate Management Environment (ACME)-Client das Zertifikat nicht korrekt innerhalb des Standard-Intervalls erneuert hat. Standardmäßig hat ein LetsEncrypt-Zertifikat eine Laufzeit von 90 Tagen und erst ab 60 Tagen ist es eigentlich zum Renewal vorgesehen. Mehr Informationen hierzu findet man in der ACME Renewal Information (ARI).

Die oben genannte Werte sind bereits individuell angepasst auf die Konfiguration der Kunden-spezifischen Umgebung. Ebenfalls denkbar wären folgende, allgemeinen Schellwerte, wenn nur einmal am Tag eine Prüfung der Laufzeiten erfolgt:

• Warnung – Ab 30 Tagen
• Fehler – Ab 28 Tagen

Renewal-Prozess

Die FortiGate-Firewalls sehen im Standard vor, dass ein Zertifikat 30 Tage vor Ablauf den Renewal-Prozess initiieren.

config vpn certificate local
    edit <ACME_certificate_name>
        set acme-renew-window 30
    end

Über folgende Befehle kann man dann ein Zertifikat manuell, auch vor den 30 Tagen, erneuern.

ACME-Status prüfen:

get system acme status
get system acme acc-details

Zertifikate erneuern:

diagnose sys acme regenerate-client-config
diagnose sys acme restart

2-3 Minuten warten, danach neue Laufzeiten je Zertifikat kontrollieren:

get vpn certificate local details <Local certificate name>
diagnose sys acme status-full <Certificate’s CN domain>

Quellen

• Improving Resiliency and Reliability for Let’s Encrypt with ARI – Let’s Encrypt (letsencrypt.org)
• Troubleshooting Tip: Let’s Encrypt certificate did… – Fortinet Community
• draft-ietf-acme-ari-02 – Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension

Der Beitrag Fortinet – LetsEncrypt-Zertifikate manuell erneuern erschien zuerst auf Maximilian Krieg.

Umgebung

Die Infrastruktur besteht aus zwei autarken FortiGate-Clustern, einem Cisco ISE-Cluster mit zwei Nodes sowie einem Entrust Identity Essentials-Cluster aus zwei Servern. Alle Systeme sind auf zwei getrennte Rechenzentren verteilt. Die folgende Darstellung ist stark vereinfacht und bezieht sich darauf, welches System jeweils den primären Zugriffsweg darstellt. Die Cisco ISE Nodes und die Entrust-Server sind zwar geclustert, aber haben eigene IP-Adressen und lassen sich eigenständig ansprechen. Über Prioritäten beziehungsweise Sequenzreihenfolgen werden die Primär- und Sekundärsysteme festgelegt.

Bei einer Anmeldung für das RAVPN sendet das jeweilige FortiGate Cluster einen RADIUS-Access-Request zur primären Cisco ISE. Diese leiten es ihrerseits die Anfrage weiter an die Entrust-Server, welche dann nach korrekter AD-Authentifizierung den Code versendet.

Analyse und Anpassung

Im Troubleshooting-Prozess wird nun geprüft, ob zunächst die Firewall-Regeln zwischen allen Systemen korrekt aufgebaut sind und die Kommunikationswege jeweils zugelassen sind. Dies gilt auch für die Cluster-interne Kommunikation, da hier die Cluster in jeweils Standort-spezifischen Subnetzen stehen und das Forwarding über die Firewalls erfolgt. Hier kann kein Fehler festgestellt werden.

Da die Anmeldungen, egal ob an das VPN-Gateway im Datacenter A und Datacenter B an der primären Cisco ISE ankommen und protokolliert werden, können die beiden Firewall-Cluster aus der Fehlerbetrachtung ausgeschlossen werden. Ebenfalls werden die Cisco ISE unter den RADIUS-Servers als erreichbar gemeldet.

Wir ändern unseren Fokus nun daher auf die Cisco ISE. Ein früherer Ausfalltest der ISE zeigt, dass auch hier kein Unterschied darin besteht, welche Cisco ISE der aktive Node ist. Beide Cisco ISE sind hinsichtlich der RADIUS-Einstellungen identisch respektive synchronisiert zum Zeitpunkt der Fehleranalyse.

Wir sehen jedoch im Firewall-Log sowie im Live Capture, dass keine RADIUS-Requests von der Cisco ISE zum sekundären Entrust-Server erfolgen. Wir prüfen daher nun die Einstellungen auf der Cisco ISE im Detail. Hier gibt es bereits erste Auffälligkeiten, denn der sekundäre Entrust-Server taucht in keiner der RADIUS-Konfigurationen auf. Wir korrigieren dies und fügen ihn als External RADIUS Server hinzu und nehmen in auch gleich in die RADIUS Server Sequences auf.

Zuletzt ergänzen wir den sekundären Entrust-Server noch in den External Identity Sources in den RADIUS Tokens als Secondary Server, da hier der primäre Entrust-Server auch hinterlegt ist. An dieser Stelle sei angemerkt, dass die Shared Secrets an beiden Stellen nochmals mit den dokumentierten Werten kontrolliert sind und übereinstimmen.

Ab jetzt sehen wir auch Netzwerkverbindungen zum sekundären Server. Diese werden jedoch negativ mit einem Reject von dem Server beantwortet.

Wir gehen daher nun zuletzt auf die beiden Entrust-Server und kontrollieren hier die Konfiguration im Entrust Identity Essentials – Configuration Tool. Hier gleichen wir die Einstellungen ab. Parallel prüfen wir das Windows Event Log, da hier Ereignisse zum Windows NPS-Dienst und Entrust protokolliert werden. Sicherheitshalber prüfen wir auch, ob die beiden Cisco ISE als RADIUS-Clients im Windows NPS hinterlegt sind und die korrekten Shared Secrets verwendet werden. Die NPS-Einstellungen sind jedoch unauffällig.

Wir stellen allerdings fest, dass der zweite Entrust-Server exklusiv den primären Entrust-Server als Authentication backed service host referenziert. Der primäre Entrust-Server verweist ebenfalls exklusiv auf sich selbst. Aus diesem Grund können auch Codes versendet werden, wenn wir der Cisco ISE die Verbindung zum primären Entrust-Server verbieten, aber die Kommunikation zwischen den Entrust-Servern noch zulassen. Wir nehmen daher beide Server in die Konfiguration des jeweils anderen Servers auf und stellen ein, dass jeder der Server sich selbst mit höchster Priorität verwendet.

Wir wiederholen nun die Tests in verschiedenen Konstellationen, diese verlaufen nun positiv und der Code wird versendet. Der Ausfalltest kann nun erfolgreich abgeschlossen werden.

Zusammenfassung

Zusammenfassend sind nun folgende Schritte erfolgt:

1. FortiGate-Firewalls
   • Kontrolle der Firewall-Regeln
   • Kontrolle der VPN- und RADIUS-Einstellungen
2. Cisco ISE
   • Kontrolle des ISE-Cluster-Status
   • Kontrolle der RADIUS-Konfiguration
   • Anlage des sekundären Entrust-Servers in der ISE an mehreren Stellen
   • Kontrolle des Shared Secrets auf Korrektheit
3. Entrust-Server
   • Kontrolle Windows NPS-Dienst und Shared Secrets auf Korrektheit
   • Kontrolle Windows Event Log auf beiden Entrust-Servern
   • Kontrolle Entrust-Konfiguration auf beiden Entrust-Servern
   • Anlage des sekundären Entrust-Servers im Configuration Tool

Der Beitrag Entrust Identity Essentials – Failover auf zweiten Member im Cluster schlägt fehl erschien zuerst auf Maximilian Krieg.