Ablauf und Erneuerung des Stammzertifikats der Zertifizierungsstelle

2004 habe ich eine kleine Zertifizierungsstelle mit OpenSSL unter Linux und den einfachen Verwaltungsskripten von OpenVPN eingerichtet. In Übereinstimmung mit den damals gefundenen Anleitungen habe ich die Gültigkeitsdauer für das Stammzertifizierungsstellenzertifikat auf 10 Jahre festgelegt. Seitdem habe ich viele Zertifikate für OpenVPN-Tunnel, Websites und E-Mail-Server signiert, die alle ebenfalls eine Gültigkeitsdauer von 10 Jahren haben (dies mag falsch gewesen sein, aber ich wusste es zu der Zeit nicht besser).

Ich habe viele Anleitungen zum Einrichten einer Zertifizierungsstelle gefunden, aber nur sehr wenige Informationen über deren Verwaltung und insbesondere darüber, was zu tun ist, wenn das Zertifikat der Stammzertifizierungsstelle abläuft, was irgendwann im Jahr 2014 passieren wird Fragen:

• Werden Zertifikate mit einer Gültigkeitsdauer, die nach Ablauf der Gültigkeitsdauer des Stammzertifizierungsstellenzertifikats verlängert wird, ungültig, sobald dieses abläuft, oder bleiben sie weiterhin gültig (weil sie während der Gültigkeitsdauer des Zertifizierungsstellenzertifikats signiert wurden)?
• Welche Vorgänge sind erforderlich, um das Zertifikat der Stammzertifizierungsstelle zu erneuern und einen reibungslosen Übergang über dessen Ablauf sicherzustellen?
  • Kann ich das aktuelle Stammzertifizierungsstellenzertifikat mit einem anderen Gültigkeitszeitraum erneut signieren und das neu signierte Zertifikat auf Clients hochladen, sodass Clientzertifikate weiterhin gültig sind?
  • Oder muss ich alle Client-Zertifikate durch neue ersetzen, die von einem neuen Zertifikat der Stammzertifizierungsstelle signiert wurden?
• Wann sollte das Zertifikat der Stammzertifizierungsstelle erneuert werden? Vor Ablauf oder eine angemessene Zeit vor Ablauf?
• Wenn die Erneuerung des Stammzertifizierungsstellenzertifikats zu einer wichtigen Aufgabe wird, was kann ich jetzt besser tun, um einen reibungslosen Übergang bei der nächsten Erneuerung zu gewährleisten (außer natürlich, dass die Gültigkeitsdauer auf 100 Jahre festgelegt wird)?

Die Situation wird durch die Tatsache etwas komplizierter, dass ich nur über einen OpenVPN-Tunnel auf einige Clients zugreifen kann, der ein vom aktuellen CA-Zertifikat signiertes Zertifikat verwendet. Wenn ich also alle Client-Zertifikate ersetzen muss, muss ich kopieren die neuen dateien an den client senden, den tunnel neu starten, die finger drücken und hoffen, dass er danach hochkommt.

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

Die Zertifikatsignaturbeziehung basiert auf einer Signatur des privaten Schlüssels. Durch Beibehalten desselben privaten Schlüssels (und implizit desselben öffentlichen Schlüssels) beim Generieren eines neuen öffentlichen Zertifikats mit einem neuen Gültigkeitszeitraum und anderen neuen Attributen, die nach Bedarf geändert werden, bleibt die Vertrauensbeziehung bestehen. Auch CRLs können vom alten zum neuen Zertifikat übergehen, da sie wie Zertifikate vom privaten Schlüssel signiert sind.

Also, lassen Sie uns überprüfen!

Erstellen Sie eine Stammzertifizierungsstelle:

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

Generieren Sie daraus ein untergeordnetes Zertifikat:

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

Unterschreiben Sie das Kind-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, jetzt sagen wir mal, es sind 10 Jahre vergangen. Generieren wir ein neues öffentliches Zertifikat aus demselben privaten Stammschlüssel.

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 wieso? Das sind verschiedene Dateien, oder?

# 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 auf dem Zertifikat ü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 noch ein wenig weiter, um zu überprüfen, ob es in der realen Welt der Zertifikatvalidierung funktioniert.

Starten Sie eine Apache-Instanz und probieren Sie es aus (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 werden diese Anweisungen auf VirtualHost443 einstellen - denken Sie daran, dass das newroot.pemStammzertifikat nicht einmal existierte, als cert.pemes generiert und signiert wurde.

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 das 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 die MS-Krypto-API verwendet? Ich muss zuerst der Wurzel vertrauen, dann ist alles in Ordnung, mit der Seriennummer der neuen Wurzel:

Und wir sollten auch weiterhin mit der alten Wurzel arbeiten. Schalten Sie 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 von Apache durch. Durch ein erneutes Laden werden die Zertifikate nicht ordnungsgemäß gewechselt.

# 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-Krypto-API-Browser präsentiert Apache das alte Stammverzeichnis, das neue befindet sich jedoch noch im vertrauenswürdigen Stammverzeichnis des Computers. Es findet es automatisch und validiert das Zertifikat anhand der vertrauenswürdigen (neuen) Wurzel, obwohl Apache eine andere Kette (die alte Wurzel) aufweist. Nachdem Sie die neue Wurzel von vertrauenswürdigen Wurzeln entfernt und das ursprüngliche Wurzelzertifikat hinzugefügt haben, ist alles in Ordnung:

Das war's! Behalten Sie den gleichen privaten Schlüssel bei, wenn Sie ihn verlängern, tauschen Sie den neuen vertrauenswürdigen Stamm ein, und es funktioniert so ziemlich alles . Viel Glück!

Ich habe festgestellt, dass im erneuerten Zertifikat des ursprünglichen CA-Schlüssels möglicherweise CA-Erweiterungen fehlen. Dies hat für mich besser funktioniert (es wird eine ./renewedselfsignedca.conf erstellt, in der CA-Erweiterungen für Version 3 definiert sind und ca.key und ca.crt als Original-CA-Schlüssel und -Zertifikat angenommen werden):

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

Basismodus zum Verlängern der Gültigkeitsdauer von root (Sie benötigen den öffentlichen X.509-Schlüssel und einen zugehörigen privaten Schlüssel):

Generieren Sie die CSR aus öffentlichem X.509 und privatem Schlüssel:

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

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

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

@ Bianconiglio plus -set_serial hat für mich gearbeitet. Mein Server ist nur ein Intranet-Server, daher 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. Stellen Sie einfach die Variablen CACRT, CAKEY und NEWCA ein.

# 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

Wenn Ihr Stammzertifikat abläuft, tun dies auch die Zertifikate, die Sie damit signiert haben. Sie müssen ein neues Stammzertifikat erstellen und damit neue Zertifikate signieren. Wenn Sie den Vorgang nicht alle paar Jahre wiederholen möchten, besteht die einzige echte Option darin, das gültige Datum auf dem Stammzertifikat etwa um zehn oder zwanzig Jahre zu verlängern: Die Wurzel, die ich für meinen eigenen Gebrauch erstellt habe, habe ich für zwanzig Jahre festgelegt.

Sie können ein Root-Zertifikat nicht "verlängern". Sie können lediglich ein neues generieren.

Generieren Sie mindestens ein oder zwei Jahre vor Ablauf Ihrer alten Wurzel eine neue Wurzel, damit Sie Zeit haben, umzusteigen, ohne gegen eine Zeitmauer zu stoßen, wenn etwas schief geht. Auf diese Weise können Sie immer vorübergehend auf die alten Zertifikate zurückgreifen, bis Sie Ihre Kinderkrankheiten mit dem neuen behoben haben.

In Bezug auf die VPN-Tunnel habe ich ein paar Testbed-Server eingerichtet, mit denen Sie experimentieren können, damit Sie genau wissen, was Sie tun müssen, bevor Sie es mit dem Computer eines Clients tun.

Wir hatten das gleiche Problem, und das war in unserem Fall, weil der Debian-Server veraltet war und die openSSL das folgende 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, haben eine Gültigkeit von 1901 Jahren!

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