Grundlegendes zur Validierung digitaler Zertifikate
In Junos OS Version 16.1R3 unterstützen Geräte der MX-Serie die Validierung digitaler Zertifikate. Während der IKE-Aushandlung validiert der PKI-Daemon auf einem Gerät der MX-Serie X509-Zertifikate, die von VPN-Peers erhalten wurden. Die durchgeführte Zertifikatsprüfung wird im 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 Sperrprüfungen. In diesem Thema werden zusätzliche digitale Zertifikatvalidierungen beschrieben, die vom PKI-Daemon durchgeführt werden.
Richtlinienvalidierung
X509-Zertifikate können optionale Richtlinienvalidierungsfelder enthalten. Wenn ein Richtlinienvalidierungsfeld 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 ist nicht auf das Stammzertifikat anwendbar. Die Richtlinienvalidierung stellt sicher, dass die EE- und Zwischenzertifizierungszertifikate über eine gemeinsame Richtlinie verfügen. Wenn keine gemeinsame Richtlinie für die zu validierte Zertifikatskette vorhanden ist, schlägt die Zertifikatsprüfung fehl.
Vor der Richtlinienvalidierung muss eine Zertifikatskette erstellt werden, die das selbstsignierte Stammzertifikat, zwischengeschaltete CA-Zertifikate und EE-Zertifikat enthält. Die Richtlinienvalidierung beginnt mit dem zwischengeschalteten CA-Zertifikat, das vom selbstsignierten Stammzertifikat ausgestellt wird, und wird über das EE-Zertifikat fortgesetzt.
Die folgenden optionalen Zertifikatsfelder werden für die Richtlinienvalidierung verwendet:
Policy-oids
erfordernExplicitPolicy
skipCerts
Diese Felder werden in den folgenden Abschnitten beschrieben.
- Auf Geräten der MX-Serie konfigurierte Richtlinien-OIDs
- Keine Richtlinien-OIDs auf Geräten der MX-Serie konfiguriert
Auf Geräten der MX-Serie konfigurierte Richtlinien-OIDs
In einigen Fällen kann es wünschenswert sein, Nur Zertifikate mit bekannten Policy Object Identifiers (OIDs) von Peers zu akzeptieren. Mit dieser optionalen Konfiguration kann die Zertifikatsprüfung nur erfolgreich sein, wenn die vom Peer empfangene Zertifikatskette mindestens eine Richtlinien-OID enthält, die auf dem Gerät der MX-Serie konfiguriert ist.
Auf dem Gerät der MX-Serie werden Richtlinien-OIDs in einer IKE-Richtlinie mit der policy-oids Konfigurationsaussage auf Der Hierarchieebene [edit security ike policy policy-name certificate] 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 Richtlinien-OIDs enthalten, die auf dem Gerät der MX-Serie konfiguriert sind. Beachten Sie, dass das Feld richtlinien-oids in einem Zertifikat optional ist. Wenn Sie Richtlinien-OIDs auf dem Gerät der MX-Serie konfigurieren, die Zertifikatskette des Peers jedoch keine Richtlinien-OIDs enthält, schlägt die Zertifikatsprüfung fehl.
Keine Richtlinien-OIDs auf Geräten der MX-Serie konfiguriert
Wenn auf dem Gerät der MX-Serie keine Richtlinien-OID konfiguriert ist, beginnt die Richtlinienvalidierung immer dann, wenn das Feld "RequireExplicitPolicy" in der Zertifikatskette auftritt. Ein Zertifikat kann einen oder mehrere Zertifikatsrichtlinien-OIDs enthalten. Damit die Richtlinienvalidierung erfolgreich ist, muss in der Zertifikatskette eine gemeinsame Richtlinien-OID vorhanden sein.
Abbildung 1 zeigt eine Zertifikatskette, die aus Zertifikaten für eine Stammzertifizierungsstelle, drei Zwischenzertifizierungsstellen und einer EE besteht. Das CA-Zertifikat für Int-CA-2 enthält das Feld "requireExplicitPolicy" . Daher beginnt die Richtlinienvalidierung mit Int-CA-2 und setzt sich durch EE-1 fort. 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 die Richtlinien-OIDs P2 und P5. Da die Richtlinie OID P2 den zu validierten Zertifikaten gemeinsam ist, ist die Richtlinienvalidierung erfolgreich.
Das optionale Feld skipCerts in einem zwischengeschalteten CA-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 mit dem aktuellen Zertifikat. Wenn skipCerts 1 ist, wird das aktuelle Zertifikat von der Richtlinienvalidierung ausgeschlossen. Der Wert des Feldes skipCerts wird in jedem zwischengeschalteten CA-Zertifikat geprüft. Wenn ein SkipCerts-Wert gefunden wird, der niedriger ist als die aktuelle Anzahl der zertifikate, die ausgeschlossen werden, wird der niedrigere skipCerts-Wert verwendet.
Abbildung 2 zeigt eine Zertifikatskette, die aus einer Stammzertifizierungsstelle, vier Zwischen-CAs und einer EE besteht. Der SkipCerts-Wert in Int-CA-1 ist 12, wodurch 12 Zertifikate, einschließlich des Zertifikats für Int-CA-1, übersprungen 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, was niedriger als 12 ist, sodass jetzt 2 Zertifikate übersprungen werden. Der SkipCerts-Wert in Int-CA-4 ist 5, was größer als 2 ist, sodass der Int-CA-4 skipCerts-Wert ignoriert wird.
skipCerts
Wenn Richtlinien-OIDs auf dem Gerät der MX-Serie konfiguriert sind, werden die ZertifikatsfelderexplicitPolicy und skipCerts ignoriert.
Pfadlängenvalidierung
Die Zertifikatsprüfung kann eine Zertifikatskette umfassen, die eine Stammzertifizierungsstelle, eine oder mehrere optionale Zwischenzertifizierungsstellen und ein EE-Zertifikat umfasst. Die Anzahl der zwischengeschalteten CAs kann je nach Bereitstellungsszenario wachsen. Die Pfadlängenvalidierung bietet einen Mechanismus, um die Anzahl der an der Zertifikatvalidierung beteiligten Zwischenzertifikate zu begrenzen. Pfadlänge ist ein optionales Feld in einem X509-Zertifikat. Der Wert der Pfadlänge gibt die Anzahl der nicht selbstsignierten Zwischenzertifikate an, die für die Zertifikatsprüfung zugelassen sind. Das letzte Zertifikat, in der Regel das EE-Zertifikat, ist nicht in der Pfadbeschränkung enthalten. Wenn das Stammzertifikat den Pfadlängenwert 0 enthält, sind keine zwischengeschalteten CA-Zertifikate zulässig. Wenn der Pfadlängenwert 1 ist, kann es 0 oder 1 Zwischenzertifikate geben.
Pfadlänge kann in mehreren CA-Zertifikaten in der Zertifikatskette vorhanden sein. Die Überprüfung der Pfadlänge beginnt immer mit dem selbstsignierten Stammzertifikat. Die Pfadgrenze wird bei jedem Zwischenzertifikat in der Kette um 1 dekrementiert. Wenn ein Zwischenzertifikat einen Pfadlängenwert unter dem aktuellen Pfadlimit enthält, wird die neue Begrenzung durchgesetzt. Wenn der Wert für die Pfadlänge größer als die aktuelle Pfadbeschränkung ist, wird er hingegen ignoriert.
Abbildung 3 zeigt eine Zertifikatskette, die aus einer Stammzertifizierungsstelle, vier Zwischen-CAs und einer EE besteht. Der Pfadlängenwert in Root-CA ist 10, daher ist die anfängliche Pfadgrenze für nicht selbstsignierte Zwischenzertifizierungszertifikate, die für die Zertifikatsprüfung zugelassen sind, 10. Bei Int-CA-1 beträgt die Pfadgrenze 10-1 oder 9. Der Pfadlängenwert in Int-CA-1 ist 4, was niedriger ist als die Pfadgrenze von 9, sodass die neue Pfadgrenze 4 wird. Bei Int-CA-2 beträgt die Pfadgrenze 4-1 oder 3. Der Pfadlängenwert in Int-CA-2 ist 5, was größer ist als die Pfadgrenze von 3, sodass er ignoriert wird. Bei Int-CA-3 beträgt die Pfadgrenze 3-1 oder 2. Der Pfadlängenwert in Int-CA-3 ist 20, was größer ist als die Pfadgrenze von 2, sodass er auch ignoriert wird.
Schlüsselnutzung
Das Feld für die Schlüsselverwendung in einem EE- oder CA-Zertifikat definiert den Zweck des im Zertifikat enthaltenen Schlüssels.
EE-Zertifikate
Bei EE-Zertifikaten wird das Zertifikat abgelehnt, wenn das Feld für die Schlüsselverwendung vorhanden ist, aber das Zertifikat keine digitalSignature - oder Nonrepudiation-Flags enthält. Wenn das Feld für die Schlüsselverwendung nicht vorhanden ist, wird die Schlüsselverwendung nicht überprüft.
CA-Zertifikate
Der Schlüssel kann 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 überprüft werden.
Validierung der Zertifikatssignatur
Das keyCertSign-Flag zeigt an, dass ein CA-Zertifikat für die Zertifikatsignaturvalidierung verwendet werden kann. Wenn dieses Flag nicht festgelegt ist, wird die Zertifikatsvalidierung beendet.
CRL-Signaturvalidierung
In Phase-1-Verhandlungen überprüfen die Teilnehmer die Zertifikatssperrliste (Certificate Revocation List, CRL), um zu sehen, ob zertifikate, die während eines IKE-Austauschs erhalten wurden, noch gültig sind. Die CRL wird regelmäßig für CA-Profile heruntergeladen, die mit CRL als Zertifikatssperrprüfung konfiguriert wurden. 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 mithilfe eines CA-Zertifikats 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.
Emittent und Distinguished Name Validierung
Die Signaturvalidierung wird für Zertifikate durchgeführt, die von einem Peer empfangen werden, sowie für die CRL-Datei, die von einem CA-Server heruntergeladen wurde. Die Signaturvalidierung umfasst das Suchen des CA-Zertifikats in einer CA-Datenbank basierend auf dem distinguished Name (DN) des Herausgebers im Zertifikat oder der überprüften CRL.
Abbildung 4 zeigt die Suche nach CA-Zertifikaten basierend auf dem Emittenten-DN. Im EE-Zertifikat lautet der Ausgeber-DN CA-1, was der Betreff-DN des zwischengeschalteten CA-Zertifikats in der Kette ist. Im zwischengeschalteten CA-Zertifikat ist der Emittent-DN CA-Root, der Betreff-DN des selbstsignierten Root-CA-Zertifikats in der Kette. In der CRL ist der Emittent-DN CA-Root, der Betreff-DN des selbstsignierten Root-CA-Zertifikats.
Die Suche nach dem Emittenten- oder Betreff-DN muss den folgenden Regeln für Attributwerte folgen:
Attributwerte, die in verschiedenen ASN.1-Typen (z. B. PrintableString und BMPString) codiert sind, werden angenommen, dass sie unterschiedliche Zeichenfolgen darstellen.
Attributwerte, die in PrintableString-Typen codiert sind, unterscheiden nicht von Groß-/Kleinschreibung. Diese Attributwerte werden verglichen, nachdem führende und nachlaufende Leerzeichen entfernt und interne Teilzeichenfolgen eines oder mehrerer aufeinanderfolgender Leerzeichen in ein einziges Leerzeichen konvertiert wurden.
Attributwerte, die in anderen Typen als PrintableString codiert sind, müssen großgeschrieben werden.