Neuausstellung der selbstsignierten Stammzertifizierungsstelle ohne Ungültigmachung der von ihr signierten Zertifikate

Ich habe eine selbstsignierte Stammzertifizierungsstelle für einige interne Dienste in unserem Unternehmen erstellt, die ich selbst konfiguriert habe (meistens über HTTPS bereitgestellt). Dann habe ich Zertifikate für diese Dienste erstellt, die mit dieser Zertifizierungsstelle signiert wurden.

Jetzt möchte ich der Stammzertifizierungsstelle eine x509-Erweiterung (CRL-Verteilungspunkt) hinzufügen, ohne vorhandene Serverzertifikate ungültig zu machen, die von dieser Zertifizierungsstelle ausgestellt wurden. Ist das möglich?

Mein Bauchgefühl ist "Ja", da nach meinem Verständnis der Zugriff auf den entsprechenden privaten Schlüssel notwendig und ausreichend ist, um "die volle Autorität" über die Zertifikatidentität zu erlangen. Das heißt, es sei denn, es wird eine Art Nonce zusammen mit dem öffentlichen Schlüssel in das Zertifikat aufgenommen, wenn es generiert wird (wahrscheinlich).

Ich bin noch ziemlich neu in der Verwaltung von SSL-Zertifikaten, aber ich (glaube ich) verstehe die Grundlagen der Standard-Vertrauenskette. Ich bin auch mit der grundlegenden Verwendung anderer PKI-Krypto vertraut: Ich verwalte SSH-Schlüssel und verwende GPG zum Signieren und Verschlüsseln. Ich habe Informatik studiert, obwohl ich nur ein Autodidakt in Kryptographie bin.

Ich habe nie eine CSR für das ursprüngliche IIRC erstellt (ich denke, es war die direkte Ausgabe von openssl req -new -x509). Ich habe natürlich immer noch den privaten Schlüssel der ursprünglichen Zertifizierungsstelle, und mit ihm konnte ich das ursprüngliche Zertifikat in eine Zertifikatsignierungsanforderung "umkehren": openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key

Ich hatte gehofft, dies würde die oben erwähnte Nonce effektiv "extrahieren" und es mir ermöglichen, das Zertifikat neu zu erstellen, diesmal jedoch mit einem crlDistributionPointsFeld, und folglich würden alle Zertifikate, die mit der ursprünglichen Zertifizierungsstelle signiert wurden, mit Ausnahme der neuen Zertifizierungsstelle weiterhin validiert Diese Clients würden meine (derzeit leere) CRL-Datei von der im Feld angegebenen HTTP-URL abrufen.

Also habe ich eine Erweiterungskonfigurationsdatei erstellt ext.conf:

[ cert_ext ] 
subjectKeyIdentifier=hash
crlDistributionPoints=URI:http://security.mycompany.co.za/root.crl

Und ich habe die neue Version der Stammzertifizierungsstelle aus der CSR generiert:

openssl x509 -extfile ./ext.conf -extensions cert_ext -req -signkey private/MyCA.key -in MyCA.csr -out MyNewCA.pem

Nun, wenn ich das Zertifikat mit ansehe openssl x509 -text -in MyNewCA.pem | less

Ich kann den CRL-Erweiterungsteil sehen:

X509v3 extensions:
    X509v3 Subject Key Identifier: 
        82:D0:01:03:49:FF:30:16:FA:DC:0A:1E:C1:8C:3D:66:A1:78:FF:F8
    X509v3 CRL Distribution Points: 

        Full Name:
          URI:http://security.mycompany.co.za/root.crl`

Aber leider! Meine zuvor signierten Zertifikate sind nicht mehr gegen dieses gültig:

openssl verify -verbose -CAfile MyCA.pem git.pem 
git.pem: OK

openssl verify -verbose -CAfile MyNewCA.pem git.pem 
git.pem: <redacted DN>
error 20 at 0 depth lookup:unable to get local issuer certificate

Meistens suche ich nach mehr Einblick, wie Zertifikate funktionieren und warum. Aber ich würde auch eine Lösung für das Problem begrüßen, das zu diesem Problem geführt hat. Hier sind auch einige Hintergrundinformationen.

Wie ich in dieses Chaos geraten bin: HTTPS für interne Dienste funktioniert hervorragend, sobald meine Zertifizierungsstelle über den Explorer RMB → Install Certificate GUI unter Windows oder /usr/local/share/ca-certificatesgefolgt von update-ca-certificatesDebian und Ubuntu installiert wurde . Aber ich bin kürzlich auf eine Ausnahme gestoßen: Git unter Windows, insbesondere wenn es installiert wurde, um Windows Secure Channel als SSL-Backend zu verwenden. Was anscheinend standardmäßig darauf besteht, dass in SSL-Zertifikaten ein CRL-Feld vorhanden sein muss.

Ich denke, es ist wirklich ein Windows Secure Channel-Problem, da die Fehlermeldung, auf die ich immer wieder stoße, vollständig Microsoft-spezifisch zu sein scheint: fatal: unable to access 'https://[email protected]/gitblit/r/secret_project.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.

Wenn ich Git mit OpenSSL installiere und meine Zertifizierungsstelle manuell mit der Datei verknüpfe, auf die git.http.sslcainfo verweist, funktioniert dies, aber ich befürchte, dass meine Benutzer dazu neigen, die Überprüfung der SSL-Identität nicht durchzuführen, wenn sie der Meinung sind, dass dieser Vorgang aufwändiger ist als Klicken Sie sich durch die GUI des "einfachen" Windows-Zertifikatinstallationsprogramms.

Zwei Zertifikate gelten als gleich, solange der Betreff und der öffentliche Schlüssel der Zertifikate übereinstimmen.

Daher müssen Sie lediglich die Schlüssel wiederverwenden und sicherstellen, dass der Antragstellername im neuen Zertifikat mit dem alten übereinstimmt. Danach können Sie alle anderen Felder und / oder Erweiterungen ändern, und das resultierende Zertifikat wird als dasselbe betrachtet.

Erstellen Sie beispielsweise Ihre OpenSSL-Konfigurationsdatei:

[ req ]

prompt             = no
string_mask        = default
distinguished_name = x509_distinguished_name
x509_extensions     = x509_ext

[ x509_distinguished_name ]

# Note that the following are in 'reverse order' to what you'd expect to see.
# Adjust for your setup:

countryName = za
organizationName = My Company
organizationalUnitName = Security
commonName = My Root CA

[ x509_ext ]

basicConstraints = critical,CA:true
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash
crlDistributionPoints = URI:http://security.mycompany.co.za/root.crl

und speichern Sie es als z rootca.cnf. Stellen Sie sicher, dass die Elemente von [req_distinguished_name]mit denen in Ihrem ursprünglichen Stammzertifizierungsstellenzertifikat identisch sind (dies ist der identische Teil des Betreffnamens).

Führen Sie als Nächstes Folgendes aus:

openssl req -new -x509 -key rootca.key -out MyNewCA.pem -config rootca.cnf

Wo rootca.keyist der private Schlüssel, der im ursprünglichen Zertifikat verwendet wird (dies ist der identische Teil des öffentlichen / privaten Schlüssels).

Dadurch entsteht MyNewCA.pem, was Sie überprüfen können mit:

$ openssl x509 -noout -text -in MyNewCA.pem

Certificate:
Data:
    Version: 3 (0x2)
    Serial Number: 17564687072266118846 (0xf3c24dd49d5166be)
Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=za, O=My Company, OU=Security, CN=My Root CA
    Validity
        Not Before: Jul 15 05:05:54 2017 GMT
        Not After : Aug 14 05:05:54 2017 GMT
    Subject: C=za, O=My Company, OU=Security, CN=My Root CA
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:c8:3d:32:8a:56:31:f6:27:1a:ce:9e:b2:1d:fb:
                ce:9f:ce:5b:42:25:aa:fe:8b:f4:34:32:ac:b3:02:
                50:71:f8:c3:43:0c:c7:2c:9f:fe:48:1b:c6:c0:e7:
                d6:44:a9:e7:d7:a0:7e:58:f4:b6:38:61:7e:d0:af:
                0f:56:21:e7:49:7a:66:13:f5:7a:fe:3d:ab:65:f8:
                01:eb:52:a7:3b:ae:a0:cf:50:57:b9:e0:09:0b:1f:
                90:14:fb:18:56:1d:57:99:a9:76:a2:63:d1:c2:d3:
                a3:f4:3a:ff:91:0d:ee:8d:44:13:58:00:09:93:da:
                e8:6a:fd:64:5f:c3:42:8e:2a:49:6e:0d:73:b7:b9:
                d4:6c:c6:ce:30:c5:82:24:a5:00:37:17:a0:1d:f1:
                c9:e9:e3:18:48:22:4f:33:96:a7:3c:a9:31:f1:3f:
                14:40:6a:74:e8:78:82:45:04:d4:4b:56:0b:cd:be:
                48:8d:03:fb:39:70:0b:91:99:70:06:bd:5e:8b:f2:
                d1:f4:6f:fc:ce:e7:f8:3c:0a:20:ea:35:b8:5f:2f:
                ee:8d:ff:d3:93:85:6b:fb:71:db:1b:e6:e9:1d:a7:
                f8:e4:ae:f4:71:fe:35:a7:89:24:af:69:a4:34:3b:
                14:66:05:02:5e:2a:1d:ac:e0:d2:48:6c:13:4e:75:
                58:93
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Basic Constraints: critical
            CA:TRUE
        X509v3 Key Usage: critical
            Certificate Sign, CRL Sign
        X509v3 Subject Key Identifier: 
            3B:45:93:3A:2A:BC:39:29:36:13:6C:BD:B6:B4:31:C7:E7:BB:32:73
        X509v3 CRL Distribution Points: 

            Full Name:
              URI:http://security.mycompany.co.za/root.crl

Signature Algorithm: sha256WithRSAEncryption
     4d:96:d4:03:4f:e3:7c:26:be:59:f8:23:87:60:f7:4c:d3:a1:
     1c:77:a1:14:e3:e7:da:c8:2a:a3:1b:06:2a:4d:55:1c:83:26:
     73:46:0d:8a:e4:b7:d1:1e:38:cc:78:90:00:01:b3:8e:f9:3c:
     62:be:04:09:90:4e:22:87:b1:aa:bd:f9:73:bd:a7:76:ad:d5:
     ae:2d:7a:1c:1e:1a:67:c8:57:4c:f9:6d:8b:62:d6:e5:ea:e0:
     40:5c:12:28:7e:ea:f0:0c:d6:cd:f4:1d:d5:56:09:ad:43:b4:
     eb:8c:68:ce:56:a2:a8:ae:a4:d5:35:bb:58:b8:ed:82:82:b5:
     ef:cb:e2:6d:76:61:ed:ee:a5:1f:68:95:07:ed:5b:f0:65:92:
     d2:dc:1d:c6:fa:7f:e0:c9:38:c2:c6:6f:03:38:e7:3a:b0:24:
     06:e0:bc:07:dd:e7:a0:dc:74:09:e5:37:7b:66:e1:6f:47:4c:
     71:ff:02:48:7f:d4:4f:ce:cb:91:e9:ee:cd:b6:f1:0a:03:19:
     3e:19:05:7d:8f:48:e7:f1:cc:07:37:3d:91:3c:6f:54:71:3c:
     a2:6c:55:c3:03:c1:7f:eb:9e:70:f1:8f:a1:fb:62:33:8b:86:
     2c:79:bc:76:e2:01:9a:68:df:af:40:a1:b2:9c:f6:a1:e1:6e:
     2a:dd:1a:d6

Verwenden Sie dieses neue Zertifikat anstelle des Originals.

Sie können andere Felder und Erweiterungen ändern, z. B. den Gültigkeitszeitraum des Zertifikats. Beachten Sie jedoch, dass Sie für das Zertifikat der Stammzertifizierungsstelle keine Einschränkungen (außer basicConstraints = critical,CA:true) haben sollten .

Nach weiteren Überlegungen kann Ihr Problem einfach darauf zurückzuführen sein, dass Ihr Ersatzzertifikat für die Stammzertifizierungsstelle nicht über die basicConstraintund möglicherweise die keyUsageErweiterungen verfügt. Es kann sinnvoll sein, diese beiden Erweiterungen zu Ihrer ext.confersten hinzuzufügen und das resultierende neue Stammzertifizierungsstellenzertifikat mit der von -x509toreqIhnen angegebenen Methode zu testen .