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://angery@git.mycompany.co.za/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.
-x509toreqalle eindeutigen Informationen von der vorhandenen Stammzertifizierungsstelle wiederhergestellt werden, aber entweder nicht oder es stimmt etwas nicht mit meinem Prozess von dort.
req -new -x509und x509 -req -signkeybeide setzen die Seriennummer des selbstsignierten Zertifikats standardmäßig auf eine Zufallszahl (obwohl dies überschrieben werden kann), was effektiv eine Nonce ist. Wenn Ihr untergeordnetes Zertifikat (oder eines davon) AuthorityKeyIdentifier enthält, indem Sie die Option 'issuer + serial' verwenden (anstelle oder zusätzlich zur Option 'keyid'). Dies ist der Fall, wenn Sie cadie vorgelagerte Standardkonfigurationsdatei verwenden müssen die neue Wurzel mit der gleichen Seriennummer wie die alte erstellen; verwenden -set_serial. ...