Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Zertifikatsvalidierung

Verstehen der digitalen Zertifikatsvalidierung

Während der IKE-Aushandlung validiert der PKI-Daemon auf einem Gerät der SRX-Serie X509-Zertifikate, die von VPN-Peers empfangen wurden. Die durchgeführte Zertifikatsvalidierung ist in RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)-Profil angegeben. Grundlegende Zertifikats- und Zertifikatskettenvalidierungen umfassen signatur- und datumsvalidierung sowie Widerrufsprüfungen. In diesem Thema werden zusätzliche digitale Zertifikatsvalidierungen beschrieben, die vom PKI-Daemon durchgeführt werden.

Validierung von Richtlinien

X509-Zertifikate können optionale Felder zur Richtlinienvalidierung enthalten. Wenn ein Feld zur Richtlinienvalidierung vorhanden ist, wird die Richtlinienvalidierung für die gesamte Zertifikatskette durchgeführt, einschließlich der Zertifikate für end entity (EE) und Intermediate Certificate Authority (CA). Die Richtlinienvalidierung gilt nicht für das Stammzertifikat. Die Richtlinienvalidierung stellt sicher, dass die EE- und Intermediate CA-Zertifikate über eine gemeinsame Richtlinie verfügen. Wenn für die Validierung der Zertifikatskette keine gemeinsame Richtlinie vorhanden ist, schlägt die Zertifikatsvalidierung fehl.

Vor der Richtlinienvalidierung muss eine Zertifikatskette aufgebaut werden, die das selbstsignierte Stammzertifikat, intermediate CA-Zertifikate und das EE-Zertifikat enthält. Die Richtlinienvalidierung beginnt mit dem zwischengeschalteten CA-Zertifikat, das vom selbst signierten Stammzertifikat ausgestellt wird, und wird durch das EE-Zertifikat fortgesetzt.

Für die Richtlinienvalidierung werden die folgenden optionalen Zertifikatsfelder verwendet:

  • policy-oids

  • requireExplicitPolicy

  • skipCerts

Diese Felder werden in den folgenden Abschnitten beschrieben.

Auf Geräten der SRX-Serie konfigurierte Richtlinien-OIDs

In einigen Situationen könnte es wünschenswert sein, nur Zertifikate mit bekannten Policy Object Identifiers (OIDs) von Peers zu akzeptieren. Diese optionale Konfiguration ermöglicht die Validierung des Zertifikats nur dann, wenn die vom Peer empfangene Zertifikatskette mindestens eine Richtlinien-OID enthält, die auf dem Gerät der SRX-Serie konfiguriert ist.

Auf dem Gerät der SRX-Serie werden Richtlinien-OIDs in einer IKE-Richtlinie mit der policy-oids Konfigurationsanweisung auf der [edit security ike policy policy-name certificate] Hierarchieebene konfiguriert. Sie können bis zu fünf Richtlinien-OIDs konfigurieren. Damit das Zertifikat eines Peers erfolgreich validiert werden kann, muss die Zertifikatskette des Peers mindestens eine der auf dem Gerät der SRX-Serie konfigurierten Richtlinien-OIDs enthalten. Beachten Sie, dass das policy-oids Feld in einem Zertifikat optional ist. Wenn Sie Richtlinien-OIDs auf dem Gerät der SRX-Serie konfigurieren, die Zertifikatskette des Peers jedoch keine Richtlinien-OIDs enthält, schlägt die Zertifikatsvalidierung fehl.

Keine Richtlinien-OIDs auf Geräten der SRX-Serie konfiguriert

Wenn auf dem Gerät der SRX-Serie keine Richtlinien-OID konfiguriert ist, wird die Richtlinienvalidierung bei Auftreten des requireExplicitPolicy Feldes in der Zertifikatskette gestartet. Ein Zertifikat kann eine oder mehrere Zertifikatsrichtlinien-OIDs enthalten. Damit die Richtlinienvalidierung erfolgreich ist, muss eine gemeinsame Richtlinien-OID in der Zertifikatskette vorhanden sein.

Abbildung 1 zeigt eine Zertifikatskette, die aus Zertifikaten für eine Root-CA, drei Intermediate-CAs und einem EE besteht. Das CA-Zertifikat für Int-CA-2 enthält das Feld. Daher beginnt die requireExplicitPolicy Richtlinienvalidierung mit Int-CA-2 und wird bis EE-1 fortgesetzt. Das Zertifikat für Int-CA-2 enthält Richtlinien-OIDs P1, P2 und P3. Das Zertifikat für Int-CA-3 enthält Richtlinien-OIDs P2, P3 und P4. Das Zertifikat für EE-1 enthält Richtlinien-OIDs P2 und P5. Da die Richtlinie OID P2 gemeinsam mit den zu validierenden Zertifikaten ist, ist die Richtlinienvalidierung erfolgreich.

Abbildung 1: Richtlinienvalidierung mit requireExplicitPolicy FieldRichtlinienvalidierung mit requireExplicitPolicy Field

Das optionale skipCerts Feld in einem CA-Intermediate-Zertifikat gibt die Anzahl der Zertifikate an, einschließlich des aktuellen CA-Zertifikats, die von der Richtlinienvalidierung ausgeschlossen werden sollen. Wenn skipCerts 0 ist, beginnt die Richtlinienvalidierung vom aktuellen Zertifikat. Wenn skipCerts 1 ist, wird das aktuelle Zertifikat von der Richtlinienvalidierung ausgeschlossen. Der Wert des skipCerts Feldes wird in jedem CA-Intermediate-Zertifikat geprüft. Wenn ein skipCerts Wert aufgetreten ist, der niedriger ist als die aktuelle Anzahl der ausgeschlossenen Zertifikate, wird der niedrigere skipCerts Wert verwendet.

Abbildung 2 zeigt eine Zertifikatskette, die aus einer Root-CA, vier Zwischen-CAs und einem EE besteht. Der skipCerts Wert in Int-CA-1 ist 12, wodurch 12 Zertifikate, einschließlich des Zertifikats für Int-CA-1, ausgelassen werden. Der skipCerts Wert wird jedoch in jedem zwischengeschalteten CA-Zertifikat in der Kette geprüft. Der skipCerts Wert in Int-CA-2 ist 2 und liegt unter 12. Jetzt werden 2 Zertifikate übersprungen. Der skipCerts Wert in Int-CA-4 ist 5, was größer als 2 ist, daher wird der Wert Int-CA-4 skipCerts ignoriert.

Abbildung 2: Richtlinienvalidierung mit skipCerts FieldRichtlinienvalidierung mit skipCerts Field

Wenn Richtlinien-OIDs auf dem Gerät der SRX-Serie konfiguriert werden, werden die Zertifikatsfelder requireExplicitPolicyskipCerts ignoriert.

Validierung der Pfadlänge

Die Zertifikatsvalidierung kann eine Zertifikatskette beinhalten, die eine Stamm-CA, eine oder mehrere optionale Intermediate CAs und ein EE-Zertifikat umfasst. Je nach Implementierungsszenario kann die Anzahl der Zwischen-CAs wachsen. Die Pfadlängenvalidierung bietet einen Mechanismus zur Begrenzung der Anzahl der an der Zertifikatsvalidierung beteiligten Zwischenzertifikate. path-length ist ein optionales Feld in einem X509-Zertifikat. Der Wert von path-length gibt die Anzahl der nicht selbst signierten Intermediate CA-Zertifikate an, die für die Zertifikatsvalidierung zulässig sind. Das letzte Zertifikat, im Allgemeinen das EE-Zertifikat, ist nicht in der Pfadbegrenzung enthalten. Wenn das Root-Zertifikat einen path-length Wert von 0 enthält, sind keine Intermediate CA-Zertifikate zulässig. Wenn der path-length Wert 1 ist, kann es 0 oder 1 Intermediate CA-Zertifikate geben.

path-length können in mehreren CA-Zertifikaten in der Zertifikatskette vorhanden sein. Die Pfadlängenvalidierung beginnt immer mit dem selbst signierten Stammzertifikat. Die Pfadbegrenzung wird bei jedem Zwischenzertifikat in der Kette um 1 dekrementiert. Wenn ein Intermediate-Zertifikat einen path-length Wert kleiner als die aktuelle Pfadgrenze enthält, wird die neue Obergrenze erzwungen. Wenn der path-length Wert hingegen größer als die grenze des aktuellen Pfads ist, wird er ignoriert.

Abbildung 3 zeigt eine Zertifikatskette, die aus einer Stamm-CA, vier Intermediate-CAs und einem EE besteht. Der path-length Wert in Root-CA beträgt 10, daher beträgt die anfängliche Pfadgrenze für nicht selbstsignierte Intermediate CA-Zertifikate, die für die Zertifikatsvalidierung zugelassen sind, 10. Bei Int-CA-1 beträgt die Pfadbegrenzung 10-1 oder 9. Der path-length Wert in Int-CA-1 ist 4, was kleiner als die Pfadgrenze von 9 ist, sodass die neue Pfadgrenze 4 wird. Bei Int-CA-2 beträgt die Pfadbegrenzung 4-1 oder 3. Der path-length Wert in Int-CA-2 ist 5, was größer als die Pfadgrenze von 3 ist, daher wird er ignoriert. Bei Int-CA-3 beträgt die Pfadbegrenzung 3-1 oder 2. Der path-length Wert in Int-CA-3 ist 20, was größer als die Pfadgrenze von 2 ist, daher wird er auch ignoriert.

Abbildung 3: Validierung der PfadlängeValidierung der Pfadlänge

Wichtige Nutzung

Das Schlüsselverwendungsfeld in einem EE- oder CA-Zertifikat definiert den Zweck des im Zertifikat enthaltenen Schlüssels.

  • Bei EE-Zertifikaten wird das Zertifikat abgelehnt, wenn das Schlüsselnutzungsfeld vorhanden ist, das Zertifikat jedoch keine Flags enthält digitalSignature oder nonrepudiation enthält. Wenn das Schlüsselverwendungsfeld nicht vorhanden ist, wird die Schlüsselverwendung nicht geprüft.

  • Für CA-Zertifikate kann der Schlüssel für die Zertifikats- oder CRL-Signaturvalidierung verwendet werden. Da der PKI-Daemon sowohl für die X509-Zertifikatvalidierung als auch für CRL-Downloads verantwortlich ist, muss die Schlüsselverwendung vor der Validierung des Zertifikats oder der CRL geprüft werden.

    In der Zertifikatsignaturvalidierung gibt das keyCertSign Flag an, dass ein CA-Zertifikat für die Validierung der Zertifikatsignatur verwendet werden kann. Wenn dieses Flag nicht festgelegt ist, wird die Zertifikatvalidierung beendet.

    In Phase 1-Verhandlungen über die CRL-Signaturvalidierung überprüfen die Teilnehmer die Zertifikats-Widerrufsliste (CRL), um zu sehen, ob die während eines IKE-Austauschs erhaltenen Zertifikate weiterhin gültig sind. Die CRL wird regelmäßig für mit CRL konfigurierte CA-Profile als Zertifikats-Widerrufsprüfung heruntergeladen. Heruntergeladene CRL-Dateien müssen überprüft werden, bevor sie auf das Gerät heruntergeladen werden. Einer der Überprüfungsschritte besteht darin, die CRL-Signatur mit einem CA-Zertifikat zu validieren. Die heruntergeladene CRL ist mit dem privaten Schlüssel des CA-Zertifikats signiert und muss mit dem öffentlichen Schlüssel des CA-Zertifikats überprüft werden, der auf dem Gerät gespeichert ist. Das Schlüsselverwendungsfeld im CA-Zertifikat muss das CRLSign Flag enthalten, um die heruntergeladene CRL zu überprüfen. Wenn dieses Flag nicht vorhanden ist, wird die CRL verworfen.

Emittenten und Betreff: Distinguished Name Validation (Emittent und Betreff: Distinguished Name Validation)

Die Signaturvalidierung wird für Zertifikate durchgeführt, die von einem Peer empfangen wurden, sowie für die CRL-Datei, die von einem CA-Server heruntergeladen wird. Bei der Signaturvalidierung wird das CA-Zertifikat in einer CA-Datenbank nach dem distinguished Name des Emittenten (Distinguished Name, DN) im Zertifikat oder der zu überprüfenden CRL gesucht.

Abbildung 4 zeigt die Suche nach CA-Zertifikaten basierend auf dem Emittenten DN. Im EE-Zertifikat ist der EE-Anbieter CA-1, d. h. das DN des mittleren CA-Zertifikats in der Kette. Im Mittleren CA-Zertifikat ist der Emittent DN CA-Root, d. h. das Betreff-DN des selbstsignierte Root-CA-Zertifikats in der Kette. In der CRL ist der Emittent DN CA-Root, d. h. das Betreff-DN des selbstsignierte Root-CA-Zertifikats.

Abbildung 4: Emittenten- und Betreff-DN-ValidierungEmittenten- und Betreff-DN-Validierung

Die Suche nach dem Emittenten oder Betreff-DN muss diesen Regeln für Attributwerte folgen:

  • Attributwerte, die in verschiedenen ASN.1-Typen codiert wurden (z. B. PrintableString und BMPString), werden als unterschiedliche Zeichenfolgen angenommen.

  • Attributwerte, die in PrintableString-Typen codiert wurden, haben keine Groß-/Kleinschreibung. Diese Attributwerte werden verglichen, nachdem führende und trailing-Leerzeichen entfernt und interne Teilzeichenfolgen eines oder mehrerer aufeinanderfolgender Leerzeichen in ein einzelnes Leerzeichen konvertiert wurden.

  • Attributwerte, die in anderen Typen als PrintableString codiert werden, sind groß- und kleinschreibungsempfindlich.

Beispiel: Validierung digitaler Zertifikate durch Konfigurieren von Richtlinien-OIDs auf einem Gerät der SRX-Serie

In einigen Situationen könnte es wünschenswert sein, nur Zertifikate mit bekannten Policy Object Identifiers (OIDs) von Peers zu akzeptieren. Diese optionale Konfiguration ermöglicht die Validierung des Zertifikats nur dann, wenn die vom Peer empfangene Zertifikatskette mindestens eine Richtlinien-OID enthält, die auf dem Gerät der SRX-Serie konfiguriert ist. Dieses Beispiel zeigt, wie Sie Richtlinien-OIDs in der IKE-Richtlinie auf einem Gerät der SRX-Serie konfigurieren.

Sie müssen sicherstellen, dass mindestens eine der auf dem Gerät der SRX-Serie konfigurierten Richtlinien-OIDs in der Zertifikats- oder Zertifikatskette eines Peers enthalten ist. Beachten Sie, dass das policy-oids Feld in einem Peer-Zertifikat optional ist. Wenn Sie Richtlinien-OIDs in einer IKE-Richtlinie konfigurieren und die Zertifikatskette des Peers keine Richtlinien-OIDs enthält, schlägt die Zertifikatsvalidierung für den Peer fehl.

Anforderungen

Bevor Sie beginnen:

Überblick

Dieses Beispiel zeigt eine IKE-Richtlinienkonfiguration, in der Richtlinien-OIDs 2.16.840.1.101.3.1.48.2 und 5.16.40.1.101.3.1.55.2 angegeben werden. Die IKE-Richtlinie ike_cert_pol verweist auf den nicht angezeigten IKE-Vorschlag ike_cert_prop. Das lokale Zertifikat auf dem Gerät der SRX-Serie ist lc-igloo-root.

Konfiguration

Verfahren

CLI-Schnellkonfiguration

Um dieses Beispiel schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, ändern Sie alle Details, die für die Netzwerkkonfiguration erforderlich sind, kopieren Und fügen Sie die Befehle auf Hierarchieebene in die [edit] CLI ein und geben Sie dann aus dem Konfigurationsmodus ein commit .

Schritt-für-Schritt-Verfahren

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Anweisungen dazu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus im CLI-Benutzerhandbuch.

So konfigurieren Sie Richtlinien-OIDs für die Zertifikatsvalidierung:

  1. Konfiguration der IKE-Richtlinie:

Ergebnisse

Bestätigen Sie im Konfigurationsmodus Ihre Konfiguration, indem Sie den show security ike policy ike_cert_pol Befehl eingeben. Wenn die Ausgabe die beabsichtigte Konfiguration nicht anzeigt, wiederholen Sie die Anweisungen in diesem Beispiel, um die Konfiguration zu korrigieren.

Wenn Sie die Konfiguration des Geräts durchgeführt haben, geben Sie aus dem Konfigurationsmodus ein commit .

Überprüfung

Bestätigen Sie, dass die Konfiguration ordnungsgemäß funktioniert.

Verifizierung des CA-Zertifikats

Zweck

Zeigen Sie das auf dem Gerät konfigurierte CA-Zertifikat an.

Aktion

Geben Sie im Betriebsmodus den show security pki ca-certificate ca-profile ca-tmp Befehl ein.

Überprüfung der OID-Validierung von Richtlinien

Zweck

Wenn das Peer-Zertifikat erfolgreich validiert wurde, werden IKE- und IPsec-Sicherheitszuordnungen eingerichtet. Wenn die Validierung des Peer-Zertifikats fehlschlägt, wird keine IKE-Sicherheitsverbindung festgelegt.

Aktion

Geben Sie im Betriebsmodus die show security ike security-associations Befehle ein show security ipsec security-associations .

Bedeutung

Der show security ike security-associations Befehl listet alle aktiven IKE Phase 1-SAs auf. Wenn keine SAs aufgeführt sind, gab es ein Problem mit der Einrichtung von Phase 1. Überprüfen Sie in diesem Fall die PKID_CERT_POLICY_CHECK_FAIL Meldung in den Systemprotokollen. Diese Meldung zeigt an, dass die Zertifikatskette des Peers keine Richtlinien-OID enthält, die auf dem Gerät der SRX-Serie konfiguriert ist. Überprüfen Sie die policy-oids Werte in der Zertifikatskette des Peers mit den auf dem Gerät der SRX-Serie konfigurierten Werten.

Es kann auch sein, dass die Zertifikatskette des Peers keine policy-oids Felder enthält, die optionale Felder sind. Wenn dies der Fall ist, schlägt die Zertifikatsvalidierung fehl, wenn richtlinien-OIDs auf dem Gerät der SRX-Serie konfiguriert sind.