Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Zertifikatsentzug

Digitale Zertifikate haben ein Ablaufdatum, aber vor dem Ablauf ist ein Zertifikat möglicherweise aus verschiedenen Gründen nicht mehr gültig. Sie können Zertifikatsperrungen und -validierungen lokal verwalten und auf eine Certificate Authority (CA) Certificate Revocation List (CRL) verweisen.

Grundlegendes zu Online-Zertifikatstatusprotokollen und Zertifikatssperrlisten

OCSP wird verwendet, um den Sperrstatus von X509-Zertifikaten zu überprüfen. OCSP stellt den Sperrstatus für Zertifikate in Echtzeit bereit und ist in zeitkritischen Situationen wie Banktransaktionen und Aktientransaktionen nützlich.

Der Sperrstatus eines Zertifikats wird überprüft, indem eine Anfrage an einen OCSP-Server gesendet wird, der sich außerhalb einer Firewall der SRX-Serie befindet. Basierend auf der Antwort des Servers wird die VPN-Verbindung zugelassen oder verweigert. OCSP-Antworten werden auf den Firewalls der SRX-Serie nicht zwischengespeichert.

Der OCSP-Server kann die Zertifizierungsstelle sein , die ein Zertifikat ausstellen, oder ein autorisierter Responder. Der Speicherort des OCSP-Servers kann manuell konfiguriert oder aus dem zertifikat extrahiert werden, das überprüft wird. Anfragen werden zuerst an OCSP-Serverstandorte gesendet, die manuell in CA-Profilen mit der ocsp url Anweisung auf Hierarchieebene [edit security pki ca-profile profile-name revocation-check] konfiguriert werden. Für jedes CA-Profil können bis zu zwei Standorte konfiguriert werden. Wenn der erste konfigurierte OCSP-Server nicht erreichbar ist, wird die Anfrage an den zweiten OCSP-Server gesendet. Wenn der zweite OCSP-Server nicht erreichbar ist, wird die Anforderung an den Speicherort im AuthorityInfoAccess-Erweiterungsfeld des Zertifikats gesendet. Die use-ocsp Option muss auch konfiguriert werden, da die Zertifikatsperrliste (Certificate Revocation List, CRL) die Standardprüfungsmethode ist.

Firewalls der SRX-Serie akzeptieren nur unterzeichnete OCSP-Antworten von der CA oder autorisierten Responder. Die empfangene Antwort wird mit vertrauenswürdigen Zertifikaten validiert. Die Antwort wird wie folgt validiert:

  1. Das CA-Zertifikat, das für das konfigurierte Ca-Profil registriert ist, wird zur Validierung der Antwort verwendet.

  2. Die OCSP-Antwort kann ein Zertifikat zur Validierung der OCSP-Antwort enthalten. Das erhaltene Zertifikat muss von einem CA-Zertifikat signiert werden, das bei der Firewall der SRX-Serie registriert ist. Nachdem das empfangene Zertifikat durch das CA-Zertifikat validiert wurde, wird es zur Validierung der OCSP-Antwort verwendet.

Die Antwort vom OCSP-Server kann von verschiedenen CAs signiert werden. Die folgenden Szenarien werden unterstützt:

  • Der CA-Server, der das Endentitätszertifikat für ein Gerät aus ausgestellt hat, signiert auch die OCSP-Sperrstatusantwort. Die Firewall der SRX-Serie überprüft die OCSP-Antwortsignatur mithilfe des CA-Zertifikats, das bei der Firewall der SRX-Serie registriert ist. Nachdem die OCSP-Antwort validiert wurde, wird der Status der Zertifikatssperrung überprüft.

  • Ein autorisierter Responder unterzeichnet die OCSP-Sperrstatusantwort. Das Zertifikat für den autorisierten Responder und das Endentitätszertifikat, das überprüft wird, müssen von derselben Zertifizierungsstelle ausgestellt werden. Der autorisierte Responder wird zuerst mit dem CA-Zertifikat überprüft, das bei der Firewall der SRX-Serie registriert ist. Die OCSP-Antwort wird mithilfe des CA-Zertifikats des Responders validiert. Die Firewall der SRX-Serie verwendet dann die OCSP-Antwort, um den Sperrstatus des Endentitätszertifikats zu überprüfen.

  • Es gibt unterschiedliche CA-Signer für das Endentitätszertifikat, das überprüft wird, und die OCSP-Antwort. Die OCSP-Antwort wird von einer Zertifizierungsstelle in der Zertifikatskette für das geprüfte Endentitätszertifikat signiert. (Alle Peers, die an einer IKE-Aushandlung teilnehmen, müssen mindestens eine gemeinsame vertrauenswürdige Zertifizierungsstelle in ihren jeweiligen Zertifikatsketten haben.) Die CA des OCSP-Responders wird mithilfe einer Zertifizierungsstelle in der Zertifikatskette überprüft. Nach der Validierung des Antwort-CA-Zertifikats wird die OCSP-Antwort mithilfe des CA-Zertifikats des Responders validiert.

Um Replay-Angriffe zu verhindern, kann eine Nonce-Payload in einer OCSP-Anfrage gesendet werden. Nicht-Payloads werden standardmäßig gesendet, es sei denn, sie sind explizit deaktiviert. Wenn sie aktiviert ist, erwartet die Firewall der SRX-Serie, dass die OCSP-Antwort eine Nicht-Nutzdaten enthält, andernfalls schlägt die Sperrprüfung fehl. Wenn OCSP Responders nicht mit einer Nonce-Payload reagieren können, muss die Nonce-Payload auf der Firewall der SRX-Serie deaktiviert werden.

Im normalen Geschäftsbetrieb werden Zertifikate aus verschiedenen Gründen widerrufen. Sie können ein Zertifikat widerrufen, wenn Sie z. B. den Verdacht haben, dass es kompromittiert wurde, oder wenn ein Zertifikatsinhaber das Unternehmen verlässt.

Sie können zertifikatssperren und -validierungen auf zwei Arten verwalten:

  • Lokal: Dies ist eine begrenzte Lösung.

  • Durch Verweisen auf eine Certificate Authority (CA) Certificate Revocation List (CRL) – Sie können automatisch online auf die CRL zugreifen, in den von Ihnen angegebenen Intervallen oder in dem von der Zertifizierungsstelle festgelegten Standardintervall.

In Phase-1-Verhandlungen überprüft die Firewall der SRX-Serie das EE-Zertifikat, das der Peer während eines IKE-Austauschs erhalten hat, und verwendet die CRL, um sicherzustellen, dass das EE-Zertifikat nicht von seiner Zertifizierungsstelle widerrufen wird.

Wenn eine CRL nicht auf dem Gerät geladen wird und der Peer-Zertifikatsausgeber eine vertrauenswürdige Zertifizierungsstelle ist,

  1. Junos OS ruft die CRL über die konfigurierten LDAP- oder HTTP-CRL-Speicherorte (d. h. die CRL Distribution Points (CDP)) ab, wenn sie im CA-Profil definiert sind.
  2. Wenn die CRL-Verteilungspunkte nicht im CA-Profil konfiguriert sind, verwendet das Gerät die CDP-Erweiterung in einem Zertifikat, das von der Zertifizierungsstelle ausgestellt wurde (falls vorhanden). Bei dem von der Zertifizierungsstelle ausgestellten Zertifikat kann es sich um ein Zertifikat sein, das vom Administrator registriert wurde oder während der Phase-1-Aushandlung erhalten wurde.

Wenn das EE-Zertifikat nicht von einer Stammzertifizierungsstelle ausgestellt wird, durchlaufen die Zertifikate jeder Zwischenzertifizierungsstelle dieselbe Überprüfung und Sperrprüfung. Die CRL der Stammzertifizierungsstelle wird verwendet, um zu überprüfen, ob das von der Stammzertifizierungsstelle ausgestellte Zertifikat widerrufen wurde. Wenn das CDP im Stammprofil der CA nicht konfiguriert ist, verwendet das Gerät die CDP-Erweiterung im Zertifikat, das von der Zertifizierungsstelle ausgestellt wurde (falls vorhanden).

Die CRL Distribution Point Extension (.cdp) in einem X509-Zertifikat kann entweder zu einer HTTP-URL oder einer LDAP-URL hinzugefügt werden.

Wenn das Zertifikat keine Erweiterung des Zertifikatsverteilungspunkts enthält und Sie die CRL nicht automatisch über LDAP (Lightweight Directory Access Protocol) oder Hypertext Transfer Protocol (HTTP) abrufen können, können Sie eine CRL manuell abrufen und in das Gerät laden.

Lokale Zertifikate werden anhand der Zertifikatssperrliste (Certificate Revocation List, CRL) validiert, selbst wenn die CRL-Prüfung deaktiviert ist. Dies kann gestoppt werden, indem Sie die CRL-Prüfung über die PKI-Konfiguration (Public Key Infrastructure) deaktivieren. Wenn die CRL-Prüfung deaktiviert ist, validiert die PKI das lokale Zertifikat nicht für CRL.

Vergleich von Online-Zertifikatsstatusprotokoll und Zertifikatssperrliste

Online Certificate Status Protocol (OCSP) und Certificate Revocation List (CRL) können beide verwendet werden, um den Sperrstatus eines Zertifikats zu überprüfen. Jede Methode hat Vor- und Nachteile.

  • OCSP stellt den Zertifikatsstatus in Echtzeit bereit, während CRL zwischengespeicherte Daten verwendet. Für zeitkritische Anwendungen ist OCSP der bevorzugte Ansatz.

  • Die CRL-Prüfung ist schneller, da nach dem Zertifikatsstatus auf Informationen gesucht wird, die auf dem VPN-Gerät zwischengespeichert werden. OCSP benötigt Zeit, um den Sperrstatus von einem externen Server zu erhalten.

  • CRL erfordert zusätzlichen Speicher zum Speichern der Sperrliste, die von einem CRL-Server empfangen wird. OCSP benötigt keinen zusätzlichen Speicher, um den Sperrstatus von Zertifikaten zu speichern.

  • OCSP erfordert, dass der OCSP-Server jederzeit verfügbar ist. CRL kann zwischengespeicherte Daten verwenden, um den Sperrstatus von Zertifikaten zu überprüfen, wenn der Server nicht erreichbar ist.

Auf den Firewalls der MX- und SRX-Serie ist CRL die Standardmethode zur Überprüfung des Sperrstatus eines Zertifikats.

Beispiel: Manuelles Laden einer CRL auf das Gerät

In diesem Beispiel wird gezeigt, wie Sie eine CRL manuell auf das Gerät laden.

Anforderungen

Bevor Sie beginnen:

  1. Generieren Sie ein öffentliches und ein privates Schlüsselpaar. Siehe Selbstsignierte digitale Zertifikate.

  2. Generieren Sie eine Zertifikatsanforderung. Siehe Beispiel: Manuelles Generieren eines CSR für das lokale Zertifikat und Senden an den CA-Server.

  3. Konfigurieren Sie ein Zertifizierungsstellenprofil (CA). Siehe Beispiel: Konfigurieren eines CA-Profils.

  4. Laden Sie Ihr Zertifikat auf das Gerät. Siehe Beispiel: Manuelles Laden von CA und lokalen Zertifikaten.

Überblick

Sie können eine CRL manuell laden oder das Gerät automatisch laden lassen, wenn Sie die Gültigkeit des Zertifikats überprüfen. Um eine CRL manuell zu laden, erhalten Sie die CRL von einer Zertifizierungsstelle und übertragen sie auf das Gerät (z. B. über FTP).

In diesem Beispiel laden Sie ein CRL-Zertifikat, das aus dem Verzeichnis /var/tmp auf das Gerät aufgerufen wird revoke.crl . Das CA-Profil heißt ca-profile-ipsec. (Die maximale Dateigröße beträgt 5 MB.)

Wenn bereits eine CRL in das ca-profile geladen ist, muss der Befehl clear security pki crl ca-profile ca-profile-ipsec zuerst ausgeführt werden, um die alte CRL zu löschen.

Konfiguration

Verfahren

Schritt-für-Schritt-Verfahren

So laden Sie ein CRL-Zertifikat manuell:

  1. Laden Sie ein CRL-Zertifikat.

    Junos OS unterstützt das Laden von CA-Zertifikaten im Format X509, PKCS #7, DER oder PEM.

Überprüfung

Geben Sie den Befehl betriebsmodus ein, um zu überprüfen, ob die show security pki crl Konfiguration ordnungsgemäß funktioniert.

Grundlegendes zu dynamischem CRL-Download und -Überprüfung

Digitale Zertifikate werden für einen bestimmten Zeitraum ausgestellt und sind nach dem angegebenen Ablaufdatum ungültig. Eine Zertifizierungsstelle kann ein ausgestelltes Zertifikat widerrufen, indem es in einer Zertifikatssperrliste (Certificate Revocation List, CRL) aufgeführt wird. Während der Peer-Zertifikatsvalidierung wird der Sperrstatus eines Peer-Zertifikats überprüft, indem die CRL von einem CA-Server auf das lokale Gerät heruntergeladen wird.

Um die CRL-Prüfung für die Zertifikate zu erleichtern, wenn ein CA-Profil nicht konfiguriert ist, wird ein dynamisches CA-Profil erstellt. Auf dem lokalen Gerät im Format dynamic-nnnwird automatisch ein dynamisches CA-Profil erstellt.

Ein dynamisches CA-Profil:

  • Ermöglicht dem lokalen Gerät das Herunterladen der dynamischen CA und der dynamischen CRL (für entsprechende CA) gemäß dem lokalen Zertifikatsausgeber des Peers
  • Überprüft den Sperrstatus des Peer-Zertifikats

Ein VPN-Gerät überprüft das EE-Zertifikat eines Peers auf seinen Sperrstatus. Ein VPN-Gerät verwendet das von seinem Peer erhaltene Zertifikat, um Folgendes zu tun:

  • Extrahieren Sie die URL, um die CRL der CA dynamisch herunterzuladen.
  • Überprüfung des Sperrstatus des Peer-EE-Zertifikats

In Abbildung 1kann Host-A die von Host-B erhaltenen Sales-CA- und EE-Zertifikate verwenden, um die CRL for Sales-CA dynamisch herunterzuladen und den Sperrstatus des Host-B-Zertifikats zu überprüfen.

Abbildung 1: Mehrstufige Hierarchie für zertifikatsbasierte Authentifizierung Mehrstufige Hierarchie für zertifikatsbasierte Authentifizierung

Bei einzelnen Hierarchie-CA-Servern oder zertifizierungsstellenverkettten Zertifikaten werden das lokale EE-Zertifikat und das empfangene Peer-EE-Zertifikat vom gleichen CA-Server ausgestellt.

Im Folgenden sind einige der Firewall-Verhaltensweisen der SRX-Serie basierend auf verschiedenen Konfigurationen aufgeführt:

  • Wenn Sie eine Firewall der SRX-Serie mit einer trusted-ca oder trusted-ca-group konfiguriert haben, validiert oder vertraut das Gerät keine anderen CAs.
  • Wenn Sie ein CA-Profil mit einer Kette von CAs definiert haben, bei denen die Firewall der SRX-Serie nur der Stammzertifizierungsstelle vertraut und der Peer über ein Zertifikat verfügt, das von einer Sub-CA mit diesem Root signiert wurde, werden dem Gerät dynamische CA und CRL hinzugefügt.

Tabelle 1 bietet nur wenige Beispielszenarien, in denen keine dynamische CA oder CRL erstellt wird:

Tabelle 1: Beispielszenarien

Szenario

Zustand

Beispielszenario 1

Im CA-Profil haben Sie eine vertrauenswürdige Zertifizierungsstelle für ca-profile-name definiert, und Sie erhalten eine Verbindung von einem Gerät, das über ein von einer anderen Zertifizierungsstelle signiertes Zertifikat verfügt, das in Ihrem CA-Profil nicht als vertrauenswürdige CA definiert wurde.

Beispielszenario 2

Sie haben ein CA-Profil mit einer Kette von CAs definiert, bei denen die Firewall der SRX-Serie nur einer Unter-CA vertraut, und der Peer hat ein Zertifikat, das von einer Ebene über dieser Unter-CA signiert ist.

Um dynamische CA-Profile zu aktivieren, müssen Sie die revocation-check crl Option für ein Root-CA-Profil auf der Hierarchieebene [edit security pki ca-profile profile-name] konfigurieren.

Die Sperrprüfungseigenschaften eines Root-CA-Profils werden für dynamische CA-Profile übernommen. In Abbildung 1ermöglicht die CA-Profilkonfiguration auf Host-A für Root-CA dynamische CA-Profile, wie in der folgenden Ausgabe dargestellt:

Auf Host-A für Sales-CA wird ein dynamisches CA-Profil erstellt. Die Sperrprüfung wird für das dynamische Vertriebs-CA-Profil von Root-CA geerbt.

Wenn die revocation-check disable Anweisung in einem Root-CA-Profil konfiguriert ist, werden keine dynamischen CA-Profile erstellt, und der dynamische Download und die Überprüfung der CRL werden nicht durchgeführt.

Die Daten für CRLs, die von dynamischen CA-Profilen heruntergeladen wurden, werden mit dem show security pki crl Befehl genauso angezeigt wie CRLs, die von konfigurierten CA-Profilen heruntergeladen werden. Die CRL aus einem dynamischen CA-Profil wird in regelmäßigen Abständen aktualisiert, ebenso wie die CRL für CA-Profile, die im Gerät konfiguriert sind. Das Peer-CA-Zertifikat ist auch für die Signaturvalidierung der CRL erforderlich, die vom CA-Server heruntergeladen wurde.

Das CA-Zertifikat ist erforderlich, um die CRL zu validieren, die von einem CA-Server erhalten wurde. Daher wird das von einem Peer erhaltene CA-Zertifikat auf dem lokalen Gerät gespeichert. Das vom Peer erhaltene CA-Zertifikat wird verwendet, um die CRL und das ausgestellte Zertifikat zu validieren. Da das empfangene CA-Zertifikat nicht von einem Administrator registriert wird, ist das Ergebnis einer erfolgreichen Zertifikatsprüfung erst dann aussagekräftig, wenn die gesamte Zertifikatskette bis zur Stammzertifizierungsstelle verifiziert ist. Das Zertifikat der Stammzertifizierungsstelle muss von einem Administrator registriert werden.

Beispiel: Konfigurieren eines Zertifizierungsstellenprofils mit CRL-Standorten

In diesem Beispiel wird gezeigt, wie Sie ein Zertifizierungsstellenprofil mit CRL-Speicherorten konfigurieren.

Anforderungen

Bevor Sie beginnen:

  1. Generieren Sie ein Schlüsselpaar im Gerät. Weitere Informationen finden Sie unter Digitale Zertifikate.

  2. Erstellen Sie ein CA-Profil oder Profile mit informationen, die für eine ZERTIFIZIERUNGsstelle spezifische Informationen enthalten. Siehe Beispiel: Konfigurieren eines CA-Profils.

  3. Holen Sie sich ein persönliches Zertifikat von der CA. Siehe Beispiel: Manuelles Generieren eines CSR für das lokale Zertifikat und Senden an den CA-Server.

  4. Laden Sie das Zertifikat auf das Gerät. Siehe Beispiel: Manuelles Laden von CA und lokalen Zertifikaten.

  5. Konfigurieren Sie die automatische erneute Registrierung. Siehe Beispiel: Konfigurieren der SecurID-Benutzerauthentifizierung.

  6. Laden Sie bei Bedarf die CRL des Zertifikats auf das Gerät. Siehe Beispiel: Manuelles Laden einer CRL auf das Gerät.

Überblick

In diesem Beispiel bitten Sie das Gerät, die Gültigkeit des aufgerufenen my_profile CA-Profils zu überprüfen und die CRL von der URL http://abc/abc-crl.crl abzurufen, wenn eine CRL kein CA-Zertifikat begleitet und nicht auf das Gerät geladen wird.

Konfiguration

Verfahren

Schritt-für-Schritt-Verfahren

So konfigurieren Sie das Zertifikat mithilfe der CRL:

  1. Geben Sie das CA-Profil und die URL an.

  2. Wenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.

Überprüfung

Geben Sie den Befehl betriebsmodus ein, um zu überprüfen, ob die show security pki Konfiguration ordnungsgemäß funktioniert.

Beispiel: Überprüfung der Zertifikatsvalidität

In diesem Beispiel wird gezeigt, wie Sie die Gültigkeit eines Zertifikats überprüfen.

Anforderungen

Vor der Konfiguration dieser Funktion ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.

Überblick

In diesem Beispiel überprüfen Sie Zertifikate manuell, um herauszufinden, ob ein Zertifikat widerrufen wurde oder ob das zum Erstellen eines lokalen Zertifikats verwendete CA-Zertifikat auf dem Gerät nicht mehr vorhanden ist.

Wenn Sie Zertifikate manuell überprüfen, verwendet das Gerät das CA-Zertifikat (ca-cert) zur Überprüfung des lokalen Zertifikats ( local.cert). Wenn das lokale Zertifikat gültig ist und revocation-check wenn es im CA-Profil aktiviert ist, überprüft das Gerät, ob die CRL geladen und gültig ist. Wenn die CRL nicht geladen und gültig ist, lädt das Gerät die neue CRL herunter.

Für von einer CA ausgestellte Zertifikate oder CA-Zertifikate muss in der Gerätekonfiguration ein DNS konfiguriert werden. Das DNS muss in der Lage sein, den Host in der Verteilungs-CRL und in der CA Cert/Revocation List-URL in der ca-profile-Konfiguration aufzulösen. Darüber hinaus müssen Sie die Netzwerkverfügbarkeit für denselben Host haben, damit die Überprüfungen empfangen werden.

Konfiguration

Verfahren

Schritt-für-Schritt-Verfahren

So überprüfen Sie die Gültigkeit eines Zertifikats manuell:

  1. Überprüfen Sie die Gültigkeit eines lokalen Zertifikats.

  2. Überprüfen Sie die Gültigkeit eines CA-Zertifikats.

    Der zugehörige private Schlüssel und die Signatur werden ebenfalls überprüft.

Überprüfung

Geben Sie den Befehl ein, um zu überprüfen, ob die show security pki ca-profile Konfiguration ordnungsgemäß funktioniert.

Wenn anstelle einer positiven Überprüfung ein Fehler zurückgegeben wird, wird der Fehler in pkid protokolliert.

Löschen einer geladenen CRL (CLI-Prozedur)

Sie können eine geladene CRL löschen, wenn Sie sie nicht mehr zur Verwaltung von Zertifikatsperrungen und -validierungen verwenden müssen.

Verwenden Sie den folgenden Befehl, um eine Liste der geladenen Zertifikatssperren zu löschen:

Geben Sie ein CA-Profil an, um eine CRL zu löschen, die der vom Profil identifizierten Zertifizierungsstelle zugeordnet ist, oder all zum Löschen aller CRLs.