it-swarm.com.de

Stammzertifizierungsstelle mit erweiterten Schlüsselnutzungsfeldern

Ich habe kürzlich damit begonnen, den AWS Certificate Manager zu verwenden, um kostenlose TLS-Zertifikate für meinen Load Balancer zu erhalten. Bei der Überprüfung der Zertifikatkette habe ich festgestellt, dass die Stammzertifizierungsstelle der Starfield Class 2-Zertifizierungsstelle die folgenden erweiterten Schlüsselverwendungswerte aufweist:

  • SSL-Client
  • SSL-Server
  • Netscape SSL-Server
  • S/MIME-Signatur
  • S/MIME-Verschlüsselung
  • CRL-Signatur
  • Jeder Zweck
  • OCSP-Helfer
  • Zeitstempelsignatur

Anschließend habe ich den Store für vertrauenswürdige Stammzertifizierungsstellen auf einem Windows-Laptop geöffnet und mir mehrere Stammzertifizierungsstellen angesehen. Es stellt sich heraus, dass viele von ihnen dieselben oder sehr ähnliche EKU-Werte haben. Ich verstehe, warum CRL und OCSP vorhanden sind (obwohl ich mir vorstellen würde, dass die Wurzel offline gehalten wird, was OCSP etwas schwieriger machen würde), aber warum die anderen? Bedeutet dies, dass die Zertifizierungsstelle neben der Ausstellung von Zertifikaten auch Code signieren, S/MIME-Funktionen ausführen usw. kann? Oder bedeutet das Vorhandensein dieser Werte, dass Zertifikate, die von dieser Stammzertifizierungsstelle abstammen, höchstens für diese EKU-Werte verwendet werden können?

Ich habe den Abschnitt Extended Key Usage von RFC 5280 kurz überflogen und das einzige, was ich zu diesem Thema gesehen habe, war Folgendes:

Im Allgemeinen wird diese Erweiterung nur in Endentitätszertifikaten angezeigt.

Um meine Fragen zusammenzufassen:

  1. Gibt das Platzieren dieser EKU-Werte im Stammzertifizierungsstellenzertifikat an, dass die von diesem Stamm absteigenden Endentitätszertifikate höchstens diese EKU-Werte haben können?
  2. Wenn nein zu 1, warum sind diese Werte in mehreren Stammzertifizierungsstellen vorhanden? Ist es so, dass diese Zertifizierungsstellen auch für diese Zwecke verwendet werden können? Wenn ja, warum sollte man das tun, anstatt ein End-Entity-Zertifikat mit diesen EKUs auszustellen?
3
Hmmmmm

Der Grund, warum Sie sehen, dass die Liste ExtendedKeyUsage einfach auf die Anwendung zurückzuführen ist, die von der in Ihrer Frage verlinkten Website verwendet wird, um die Textdarstellung des Zertifikats zu sichern.

Wenn Sie sich die Seite noch einmal ansehen, sehen Sie eine Base-64-codierte Darstellung des Zertifikats. Kopieren Sie es, fügen Sie es in eine Datei ein und speichern Sie es. Speichern Sie die Textdarstellung des Zertifikats mit OpenSSL, und Sie sehen einfach Folgendes.

Hinweis: Wenn Sie Windows ausführen, speichern Sie es mit einem .cer oder .crt Erweiterung und doppelklicken Sie darauf. Windows zeigt das Zertifikat in einer GUI mit ähnlichen Informationen an.

$ openssl x509 -noout -text -in StarField.cer
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Validity
            Not Before: Jun 29 17:39:16 2004 GMT
            Not After : Jun 29 17:39:16 2034 GMT
        Subject: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:32:c8:fe:e9:71:a6:04:85:ad:0c:11:64:df:
                    ce:4d:ef:c8:03:18:87:3f:a1:ab:fb:3c:a6:9f:f0:
                    c3:a1:da:d4:d8:6e:2b:53:90:fb:24:a4:3e:84:f0:
                    9e:e8:5f:ec:e5:27:44:f5:28:a6:3f:7b:de:e0:2a:
                    f0:c8:af:53:2f:9e:ca:05:01:93:1e:8f:66:1c:39:
                    a7:4d:fa:5a:b6:73:04:25:66:eb:77:7f:e7:59:c6:
                    4a:99:25:14:54:eb:26:c7:f3:7f:19:d5:30:70:8f:
                    af:b0:46:2a:ff:ad:eb:29:ed:d7:9f:aa:04:87:a3:
                    d4:f9:89:a5:34:5f:db:43:91:82:36:d9:66:3c:b1:
                    b8:b9:82:fd:9c:3a:3e:10:c8:3b:ef:06:65:66:7a:
                    9b:19:18:3d:ff:71:51:3c:30:2e:5f:be:3d:77:73:
                    b2:5d:06:6c:c3:23:56:9a:2b:85:26:92:1c:a7:02:
                    b3:e4:3f:0d:af:08:79:82:b8:36:3d:ea:9c:d3:35:
                    b3:bc:69:ca:f5:cc:9d:e8:fd:64:8d:17:80:33:6e:
                    5e:4a:5d:99:c9:1e:87:b4:9d:1a:c0:d5:6e:13:35:
                    23:5e:df:9b:5f:3d:ef:d6:f7:76:c2:ea:3e:bb:78:
                    0d:1c:42:67:6b:04:d8:f8:d6:da:6f:8b:f2:44:a0:
                    01:ab
                Exponent: 3 (0x3)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
            X509v3 Authority Key Identifier: 
                keyid:BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
                DirName:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
                serial:00

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         05:9d:3f:88:9d:d1:c9:1a:55:a1:ac:69:f3:f3:59:da:9b:01:
         87:1a:4f:57:a9:a1:79:09:2a:db:f7:2f:b2:1e:cc:c7:5e:6a:
         d8:83:87:a1:97:ef:49:35:3e:77:06:41:58:62:bf:8e:58:b8:
         0a:67:3f:ec:b3:dd:21:66:1f:c9:54:fa:72:cc:3d:4c:40:d8:
         81:af:77:9e:83:7a:bb:a2:c7:f5:34:17:8e:d9:11:40:f4:fc:
         2c:2a:4d:15:7f:a7:62:5d:2e:25:d3:00:0b:20:1a:1d:68:f9:
         17:b8:f4:bd:8b:ed:28:59:dd:4d:16:8b:17:83:c8:b2:65:c7:
         2d:7a:a5:aa:bc:53:86:6d:dd:57:a4:ca:f8:20:41:0b:68:f0:
         f4:fb:74:be:56:5d:7a:79:f5:f9:1d:85:e3:2d:95:be:f5:71:
         90:43:cc:8d:1f:9a:00:0a:87:29:e9:55:22:58:00:23:ea:e3:
         12:43:29:5b:47:08:dd:8c:41:6a:65:06:a8:e5:21:aa:41:b4:
         95:21:95:b9:7d:d1:34:ab:13:d6:ad:bc:dc:e2:3d:39:cd:bd:
         3e:75:70:a1:18:59:03:c9:22:b4:8f:9c:d5:5e:2a:d7:a5:b6:
         d4:0a:6d:f8:b7:40:11:46:9a:1f:79:0e:62:bf:0f:97:ec:e0:
         2f:1f:17:94

Dies ist zu erwarten - kein KeyUsage oder ExtendedKeyUsage

Ein Stammzertifizierungsstellenzertifikat sollte eigentlich keine Erweiterungen enthalten (außer optional SubjectKeyUsage und AuthorityKeyUsage, die zur Kettenbildung verwendet werden), da dies die Verwendbarkeit des Zertifikats während seiner gesamten Laufzeit einschränkt Lebenszeit. Solche Einschränkungen sollten auf der Ebene der untergeordneten Zertifizierungsstellen hinzugefügt werden.

Wie Sie in Ihrer Frage angegeben haben, gilt ExtendedKeyUsage für das jeweilige Zertifikat und nicht für die Kette (im Gegensatz zu Richtlinien- und Namensbeschränkungen).

3
garethTheRed

Gibt das Platzieren dieser EKU-Werte im Stammzertifizierungsstellenzertifikat an, dass die von diesem Stamm absteigenden Endentitätszertifikate höchstens diese EKU-Werte haben können?

das ist richtig. Die gültige EKU für ein bestimmtes Zertifikat ist (ungefähr) der Schnittpunkt der EKU-Erweiterungsbeschränkungen in der gesamten Zertifikatskette. Wenn ein CA-Zertifikat eine EKU-Erweiterung hat, die OID1 und OID2 enthält, kann es keine Zertifikate ausstellen, die für eine andere EKU-OID gültig sind.

Dies ist jedoch keine strenge Regel, sondern hängt von einer Clientanwendung ab, die die Zertifikatsüberprüfung durchführt. Um beispielsweise das OCSP-Signaturzertifikat zu validieren, reicht es aus, OCSP Signing (1.3.6.1.5.5.7.3.9) nur im Blattzertifikat (Signaturzertifikat) zu haben. Die gesamte Kette muss nicht gültig sein für OCSP Signing usage.

Wenn das ausgestellte Zertifikat eine andere EKU enthält OID] und die Clientanwendung fragt , ob das Zertifikat für die angegebene Verwendung gültig ist, verketten Sie das Zertifikat Die Engine berücksichtigt das für diese OID gültige Zertifikat nicht.

Update 26.09.2018:

die obige Anweisung ist nicht Teil von RFC. Tatsächlich beschränkt RFC CA nicht auf die Ausstellung von EKU.

Es geht nur um die Implementierung eines großen Anbieters. Systeme und Browser implementieren normalerweise den internen Zertifikatspeicher (Certificate Store, KeyChain, TrustStore usw.), und der Zertifikatspeicher implementiert mit dem Speicher verbundene Eigenschaften, bei denen Sie oder der Anbieter dem Zertifikat zusätzliche Attribute zuweisen können, ohne das Signaturzertifikat zu ändern. So werden EKU-Einschränkungen in Ihrem Beispielzertifikat behandelt. Wenn Sie das Zertifikat öffnen, finden Sie keine EKU-Erweiterung darin:

(enter image description here

Es enthält jedoch irgendwie Einschränkungen:

(enter image description here

Und so werden Einschränkungen über den Windows-Zertifikatspeicher festgelegt:

(enter image description here

Wie gesagt, die EKU-Validierung über die Kette ist anwendungsspezifisch. Wenn die Anwendung eine EKU-Validierung über die Kette anfordert und EKU nicht in jedem CA-Zertifikat im Pfad zulässig ist, schlägt die Validierung fehl. Wenn für die Anwendung eine bestimmte EKU nur im Blattzertifikat erforderlich ist und die angegebene EKU angezeigt wird, ist die Validierung erfolgreich.

p.s. Unter Windows müssen Sie OpenSSL nicht zum Speichern des Zertifikats verwenden, sondern können das integrierte Tool certutil.exe verwenden:

certutil -dump path\certfile.cer
2
Crypt32