Frage Ablauf und Erneuerung des Stammzertifikats der Zertifizierungsstelle


Im Jahr 2004 habe ich eine kleine Zertifizierungsstelle eingerichtet, die OpenSSL unter Linux und die einfachen Verwaltungsskripts von OpenVPN verwendet. In Übereinstimmung mit den Leitfäden, die ich zu dem Zeitpunkt gefunden habe, habe ich den Gültigkeitszeitraum für das Root-CA-Zertifikat auf 10 Jahre festgelegt. Seitdem habe ich viele Zertifikate für OpenVPN-Tunnel, Websites und E-Mail-Server unterschrieben, die alle ebenfalls eine Gültigkeitsdauer von 10 Jahren haben (das mag falsch gewesen sein, aber zu der Zeit wusste ich es nicht besser).

Ich habe viele Anleitungen zum Einrichten einer Zertifizierungsstelle gefunden, aber nur sehr wenige Informationen über die Verwaltung und insbesondere darüber, was zu tun ist, wenn das Stammzertifizierungsstellenzertifikat abläuft, was irgendwann 2014 passieren wird. Ich habe also Folgendes Fragen:

  • Werden die Zertifikate, deren Gültigkeitsdauer sich nach Ablauf des Root-CA-Zertifikats verlängert, ungültig, sobald diese abgelaufen sind, oder sind sie weiterhin gültig (weil sie während der Gültigkeitsdauer des CA-Zertifikats signiert wurden)?
  • Welche Vorgänge sind erforderlich, um das Zertifikat der Stammzertifizierungsstelle zu erneuern und einen reibungslosen Übergang während des Ablaufs sicherzustellen?
    • Kann ich das aktuelle Zertifikat der Stammzertifizierungsstelle irgendwie mit einer anderen Gültigkeitsdauer neu signieren und das neu signierte Zertifikat auf die Clients hochladen, damit die Clientzertifikate gültig bleiben?
    • Oder muss ich alle Clientzertifikate durch neue Zertifikate ersetzen, die von einem neuen Stammzertifizierungsstellenzertifikat signiert wurden?
  • Wann sollte das Root-CA-Zertifikat erneuert werden? Kurz vor Ablauf oder eine angemessene Zeit vor Ablauf?
  • Wenn die Erneuerung des Root-CA-Zertifikats zu einer wichtigen Aufgabe wird, was kann ich jetzt besser machen, um einen reibungsloseren Übergang bei der nächsten Erneuerung zu gewährleisten (abgesehen davon, dass der Gültigkeitszeitraum natürlich auf 100 Jahre festgelegt wird)?

Die Situation wird dadurch etwas komplizierter, dass mein einziger Zugriff auf einige Clients über einen OpenVPN-Tunnel erfolgt, der ein Zertifikat verwendet, das vom aktuellen CA-Zertifikat signiert ist. Wenn ich also alle Client-Zertifikate ersetzen muss, muss ich kopieren die neuen Dateien zum Client, starte den Tunnel neu, drücke die Daumen und hoffe, dass es danach kommt.


87
2017-08-30 08:34


Ursprung




Antworten:


Wenn Sie denselben privaten Schlüssel in Ihrer Stammzertifizierungsstelle beibehalten, können alle Zertifikate weiterhin erfolgreich für das neue Stammverzeichnis validiert werden. Alles, was von dir verlangt wird, ist, der neuen Wurzel zu vertrauen.

Die Zertifikatsignierungsbeziehung basiert auf einer Signatur aus dem privaten Schlüssel. das Beibehalten des gleichen privaten Schlüssels (und implizit des gleichen öffentlichen Schlüssels) beim Erzeugen eines neuen öffentlichen Zertifikats, mit einer neuen Gültigkeitsdauer und allen anderen neuen Attributen, die nach Bedarf geändert werden, hält die Vertrauensbeziehung aufrecht. CRLs können auch von dem alten Cert auf den neuen fortfahren, da sie wie Zertifikate durch den privaten Schlüssel signiert sind.


Also, lass es uns verifizieren!

Erstellen Sie eine Stammzertifizierungsstelle:

openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes

Erzeuge daraus ein Kind-Zertifikat:

openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr

Unterschreiben Sie das Kinder-Zertifikat:

openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr

Alles dort eingestellt, normale Zertifikatsbeziehung. Lassen Sie uns das Vertrauen überprüfen:

# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK

Ok, also, sagen wir mal, 10 Jahre sind vergangen. Lassen Sie uns ein neues öffentliches Zertifikat vom selben privaten Schlüssel erzeugen.

openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr

Und .. hat es funktioniert?

# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

Aber warum? Sie sind verschiedene Dateien, richtig?

# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

Ja, aber das bedeutet nicht, dass der neue öffentliche Schlüssel nicht kryptografisch mit der Signatur des Zertifikats übereinstimmt. Unterschiedliche Seriennummern, gleicher Modul:

# openssl x509 -noout -text -in origroot.pem
        Serial Number:
            c0:67:16:c0:8a:6b:59:1d
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
        Serial Number:
            9a:a4:7b:e9:2b:0e:2c:32
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d

Gehen wir ein wenig weiter, um zu überprüfen, ob es in der echten Zertifikatsvalidierung funktioniert.

Starten Sie eine Apache-Instanz und versuchen Sie es (debian-Dateistruktur, passen Sie sie nach Bedarf an):

# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

Wir setzen diese Direktiven auf a VirtualHost auf 443 zuhören - erinnern, die newroot.pem Stammzertifikat war nicht einmal vorhanden cert.pem wurde generiert und signiert.

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

Schauen wir uns an, wie openssl es sieht:

# openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)

Ok, und wie wäre es mit einem Browser, der MS Crypto API nutzt? Vertrauen Sie zuerst der Wurzel, dann ist alles gut, mit der Seriennummer der neuen Wurzel:

newroot

Und wir sollten auch weiterhin mit der alten Wurzel arbeiten. Schalte die Apache-Konfiguration um:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

Führen Sie einen vollständigen Neustart auf Apache durch, ein Neuladen wird die Zertifikate nicht richtig wechseln.

# openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)

Und mit dem MS-Crypto-API-Browser präsentiert Apache den alten Stamm, aber der neue Stamm befindet sich immer noch im vertrauenswürdigen Stammspeicher des Computers. Es findet es automatisch und validiert das Zertifikat gegen den vertrauenswürdigen (neuen) Stamm, obwohl Apache eine andere Kette (die alte Wurzel) darstellt. Nach dem Entfernen des neuen Stamms aus vertrauenswürdigen Stammverzeichnissen und dem Hinzufügen des ursprünglichen Stammzertifikats ist alles in Ordnung:

oldroot


So, das war es! Behalten Sie den gleichen privaten Schlüssel bei, wenn Sie ihn erneuern, tauschen Sie ihn in den neuen vertrauenswürdigen Stammordner ein, und zwar so ziemlich alles funktioniert einfach. Viel Glück!


124
2017-09-04 18:40



Wie auch immer, warum sollten Sie ein neues Root-Zertifikat erstellen, wenn Sie nur denselben privaten Schlüssel verwenden wollen? Wenn Sie dies immer und immer wieder tun, was ist dann der Sinn eines Ablaufdatums für das Zertifikat? Ich dachte, der Root-Ablauf würde verwendet, um Admins dazu zu zwingen, einen neueren (höchstwahrscheinlich stärkeren) privaten Schlüssel zu erstellen, der sicherer gegen die ständig vorrückenden Maschinen ist, die versuchen, die Schlüssel zu brechen. Ein 40-Bit-Schlüssel, der vor 20 Jahren hergestellt wurde, ist nicht sicher genug für - jvhashe
@jvhashe Wenn das Stammzertifikat nicht mehr kryptographisch stark genug ist, sollten Sie es unabhängig von seinem Ablaufdatum loswerden. Wenn du deine eigene Root generierst, hält dich nichts davon ab, sie vor hunderten von Jahren ablaufen zu lassen, wenn du nicht mehr auf dem Planeten bist. Der Ablauf ist für ein Stammzertifikat kaum relevant - und für ein untergeordnetes Zertifikat geht es beim Ablauf nicht wirklich um die kryptographische Stärke (fragen Sie die CAs, die im Oktober alle 1024-Bit-Zertifikate aufheben) - siehe Hier Für mehr Information. - Shane Madden♦
Zusätzlich zu dem oben genannten habe ich festgestellt, dass die Seriennummer für diese Methode identisch sein muss. - Scott Presnell
-set_serial 01 - WTF ??? SIE KÖNNEN KEINE SERIENNUMMERN WIEDER VERWENDEN. Hast du dich beraten? RFC 4158, Internet X.509 Öffentliche Schlüsselinfrastruktur: Zertifizierungspfadbildung? Oder erfindest du es einfach, während du weitergehst? Sie haben keine Ahnung von den Problemen, die Sie in Benutzeragenten verursachen, wenn sie den Pfadaufbau starten. - jww
@jww Hast du die Antwort gelesen? Das ist nur eine Demonstration der Tatsache, dass die Kryptographie funktioniert. Dieser Befehl erzeugt buchstäblich nur ein Test-Cert, das wir später überprüfen können, um die Beziehung zwischen dem alten und dem neuen Root-Cert zu testen. Wenn jemand ist Ich hoffe, dass etwas bricht, wenn sie diese Befehle direkt verwenden, und sie erkennen, dass sie auf den Kontext von etwas achten müssen, bevor sie es blindlings ausführen (oder davon fliegen, ob 01 ist eine akzeptable Serie in einem Labor). - Shane Madden♦


Ich habe festgestellt, dass CA-Erweiterungen im erneuerten Zertifikat des ursprünglichen CA-Schlüssels fehlen könnten. Dies funktionierte besser für mich (es schafft eine ./renewedselfsignedca.conf Wo v3 CA-Erweiterungen definiert sind, und ca.Key und ca.crt werden als der ursprüngliche CA-Schlüssel und das Zertifikat angesehen):

openssl x509 -x509toreq -in ca.crt -signkey ca.key -out renewedselfsignedca.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > renewedselfsignedca.conf
openssl x509 -req -days 1095 -in renewedselfsignedca.csr -signkey ca.key -out renewedselfsignedca.crt -extfile ./renewedselfsignedca.conf -extensions v3_ca

13
2018-04-22 10:31



Dies war eine äußerst hilfreiche Ergänzung. Die tatsächlich gültige Antwort führt für mich nicht zu einem ausreichend kompatiblen Zertifikat, wenn Sie an Ihrer ursprünglichen Wurzel etwa willkürliche Einstellungen vornehmen. - Theuni
Abgeordnet, sehr hilfreich. Ein weiterer Zusatz: Wie Scott Presnell in den Kommentaren zur angenommenen Antwort, musste ich auch die hexadezimale Seriennummer des erneuerten Zertifikats manuell angeben, so dass es mit dem alten übereinstimmte. Das bedeutete hinzufügen -set_serial 0xdeadbeefabba (nicht die echte Seriennummer nein :)) zum letzteren x509 Befehl. Erst dann haben meine Client-Zertifikate erfolgreich gegen das erneuerte CA-Zertifikat verifiziert. - JK Laiho
Diese Methode ist einfacher, da sie dieselben Informationen enthält wie das vorherige Zertifikat. - lepe
Ich habe ein Skript für diese Lösung plus -set_serial erstellt - siehe meine Antwort - Wolfgang Fahl
Diese Antwort ersparte mir eine Menge Arbeit, nachdem ich fast einen Tag mit einem Problem verbracht hatte, das das erforderte, war ich kurz davor, aufzugeben, dafür gebe ich dir meinen Hut! - Onitlikesonic


Grundlegender Modus zum Erweitern des gültigen Zeitraums von root (Sie benötigen den öffentlichen X.509 und den zugehörigen privaten Schlüssel):

Generieren Sie den CSR aus dem öffentlichen X.509 und dem privaten Schlüssel:

openssl x509 -x509toreq -in XXX.crt -signkey XXX.key -out XXX.csr

Signieren Sie die CSR mit dem privaten Schlüssel erneut:

openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365

2
2018-01-22 16:35





Wenn das Root-Zertifikat abläuft, gilt dies auch für die Zertifikate, die Sie damit signiert haben. Sie müssen ein neues Root-Zertifikat generieren und neue Zertifikate damit signieren. Wenn Sie den Prozess nicht alle paar Jahre wiederholen wollen, ist die einzige wirkliche Option, das gültige Datum auf dem Root-Zertifikat um etwa zehn oder zwanzig Jahre zu verlängern: Die Wurzel, die ich für meinen eigenen Gebrauch generiert habe, habe ich zwanzig Jahre lang festgelegt.

Sie können ein Stammzertifikat nicht "erneuern". Alles, was Sie tun können, ist ein neues zu generieren.

Erzeuge eine neue Wurzel mindestens ein oder zwei Jahre, bevor deine alte abläuft, damit du Zeit hast, um zu wechseln, ohne gegen eine Zeitmauer zu sein, wenn etwas schief geht. Auf diese Weise können Sie immer wieder vorübergehend auf die alten Zertifikate wechseln, bis Sie Ihre Kinderkrankheiten mit dem neuen Problem gelöst haben.

Soweit die VPN-Tunnel gehen, würde ich ein paar Testbed Server einrichten, mit denen Sie experimentieren können, damit Sie genau verstehen, was Sie tun müssen, bevor Sie es mit einem Client-Rechner tun.


0
2017-09-03 23:59



Diese Antwort scheint darauf hinzuweisen, dass es möglich ist, ein Stammzertifikat zu erneuern, indem der Schlüssel erneut verwendet wird. Aber ich vermute, dass dies nicht anders ist, als bei Null zu beginnen, da das neue Zertifikat eine andere Signatur haben wird und somit bestehende Client-Zertifikate nicht validiert werden. - Remy Blank
Ja, du kannst den Gültigkeitszeitraum verlängern ... und es ist weniger Arbeit, als alle PKI, Client-Zertifikate neu zu erstellen und neue Root-Accounts wiederherzustellen ... - ggrandes
Der Teil über das Ausstellen neuer End-Entitätszertifikate ist nicht unbedingt richtig. Dies hängt davon ab, wie der Berechtigungsschlüssel-Identifikator (Authority Key Identifier, AKID) in den unterstellten CAs und End-Entity-Zertifikaten dargestellt wird. Wenn die AKID basiert auf {Distinguished Name, Seriennummer}, dann wird Kontinuität erreicht. Siehe auch RFC 4518, Internet X.509 Public Key-Infrastruktur: Zertifizierungspfadaufbau. - jww


@Bianconiglio plus -set_serial hat für mich gearbeitet. Mein Server ist nur Intranet, also mache ich mir keine Sorgen, was die Nebenwirkungen sind und ich habe jetzt Zeit, an einer "richtigen" Lösung zu arbeiten.

Ich habe das folgende konfigurierbare Skript verwendet. Setzen Sie einfach die Variablen CACRT, CAKEY und NEWCA.

# WF 2017-06-30
# https://serverfault.com/a/501513/162693
CACRT=SnakeOilCA.crt
CAKEY=SnakeOilCA.key
NEWCA=SnakeOilCA2017
serial=`openssl x509 -in $CACRT -serial -noout | cut -f2 -d=`
echo $serial
openssl x509 -x509toreq -in $CACRT -signkey $CAKEY -out $NEWCA.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > $NEWCA.conf
openssl x509 -req -days 3650 -in $NEWCA.csr -set_serial 0x$serial -signkey $CAKEY -out $NEWCA.crt -extfile ./$NEWCA.conf -extensions v3_ca
openssl x509 -in $NEWCA.crt -enddate -serial -noout

0
2018-06-30 17:33





Wir hatten das gleiche Problem, und das war in unserem Fall, weil der Debian-Server auf dem neuesten Stand war und OpenSSL dieses Problem hatte:

https://en.wikipedia.org/wiki/Year_2038_problem

Die letzte für Debian 6 verfügbare Version von OpenSSL bringt dieses Problem mit sich. Alle Zertifikate, die nach dem 23.01.2018 erstellt wurden, ergeben eine Gültigkeit: für 1901 Jahr!

Die Lösung besteht darin, OpenSSL zu aktualisieren. Sie können die Konfigurationsdateien (mit den Zertifikaten) für die Clients erneut erstellen.


0
2018-03-09 10:38