Ablauf und Erneuerung des Stammzertifikats der Zertifizierungsstelle

96

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.

Remy Blank
quelle

Antworten:

142

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:

Newroot

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:

Altwurzel


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!

Shane Madden
quelle
2
Was nützt es, ein neues Stammzertifikat zu erstellen, wenn Sie nur denselben privaten Schlüssel wiederverwenden? Wenn Sie dies immer und immer wieder tun, was nützt es dann, ein Ablaufdatum für das Zertifikat zu haben? Ich dachte, der Root-Ablauf wurde verwendet, um Administratoren dazu zu zwingen, einen neueren (höchstwahrscheinlich stärkeren) privaten Schlüssel zu erstellen, der sicherer gegen die immer weiter voranschreitenden Maschinen ist, die versuchen, die Schlüssel zu knacken. Ein vor 20 Jahren hergestellter 40-Bit-Schlüssel ist nicht sicher genug für
jvhashe
2
@jvhashe Wenn das Stammzertifikat nicht mehr kryptografisch stark genug ist, sollten Sie es unabhängig vom Ablaufdatum entfernen. Wenn Sie Ihre eigene Wurzel generieren, hindert nichts Sie daran, diese so einzustellen, dass sie Hunderte von Jahren zurückliegt, wenn Sie nicht mehr auf dem Planeten sind. Verfall ist kaum relevant für ein Root - Zertifikat - und für ein Kind Zertifikat, das Ablauf ist nicht wirklich über Verschlüsselungsstärke entweder (fragen Sie die Zertifizierungsstellen, die prepping alle 1024-Bit - Zert im Oktober zu widerrufen) - siehe hier für weitere Informationen.
Shane Madden
3
Darüber hinaus stellte ich fest, dass die Seriennummer identisch sein muss, damit diese Methode funktioniert.
Scott Presnell
2
-set_serial 01- WTF ??? SIE KÖNNEN SERIENNUMMERN NICHT WIEDERVERWENDEN . Haben Sie sogar RFC 4158, Internet X.509 Public Key Infrastructure: Zertifizierungspfadaufbau konsultiert ? Oder machst du es nur nach? Sie haben keine Ahnung, welche Probleme Benutzeragenten verursachen, wenn sie mit der Pfaderstellung beginnen.
1
@jww Hast du die Antwort gelesen? Das ist nur eine Demonstration der Tatsache, dass die Kryptographie funktioniert. Dieser Befehl generiert buchstäblich nur ein Testzertifikat, das wir später überprüfen können, um die Beziehung zwischen dem alten und dem neuen Stammzertifikat zu testen. Wenn jemand ist direkt diese Befehle verwenden, ich hoffe natürlich , etwas kaputt geht, und sie erkennen , dass sie die Aufmerksamkeit auf den Kontext etwas bezahlen müssen , bevor blind laufen sie (oder den Griff zu wegfliegen , ob 01ein akzeptabler Serien in einem Labor).
Shane Madden
14

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
Bianconiglio
quelle
2
Dies war eine äußerst hilfreiche Ergänzung. Die tatsächlich gültige Antwort führt bei mir nicht zu einem hinreichend kompatiblen Zertifikat, wenn Sie in Ihrem ursprünglichen Root ca. beliebige Einstellungen vorgenommen haben.
Theuni
1
Abgeordnet, sehr hilfreich. Ein weiterer Zusatz: Wie Scott Presnell in den Kommentaren zur akzeptierten Antwort musste ich auch die hexadezimale Seriennummer des erneuerten Zertifikats manuell angeben, damit sie mit der alten übereinstimmt. Dies bedeutete, dass -set_serial 0xdeadbeefabbader letztgenannte x509-Befehl hinzugefügt wurde (nicht die reale Seriennummer :). Erst dann wurden meine Client-Zertifikate erfolgreich mit dem erneuerten CA-Zertifikat abgeglichen.
JK Laiho,
Diese Methode ist einfacher, da sie dieselben Informationen wie das vorherige Zertifikat enthält.
4.
Ich habe ein Skript für diese Lösung erstellt und -set_serial - siehe meine Antwort
Wolfgang Fahl
Diese Antwort ersparte mir eine Menge Arbeit, nachdem ich fast einen Tag für ein Thema aufgewendet hatte, das dies erforderte. Ich wollte fast aufgeben. Ich gebe dir meinen Hut dafür!
Onitlikesonic
2

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
ggrandes
quelle
1

@ 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
Wolfgang Fahl
quelle
0

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.

Schneehase
quelle
Diese Antwort scheint darauf hinzudeuten, dass es möglich ist, ein Stammzertifikat zu erneuern, indem sein Schlüssel erneut verwendet wird. Ich vermute jedoch, dass dies nichts anderes ist, als von vorne zu beginnen, da das neue Zertifikat eine andere Signatur hat und daher vorhandene Kundenzertifikate nicht validiert.
Remy Blank
Ja, Sie können die Gültigkeitsdauer verlängern ... und es ist weniger Arbeit, als alle PKI- und Client-Zertifikate neu zu erstellen und neue Stammzertifikate erneut zu vertrauen ...
ggrandes
Der Teil über die Ausstellung neuer Endgerätezertifikate ist nicht unbedingt wahr. Dies hängt davon ab, wie der Authority Key Identifier (AKID) in den untergeordneten Zertifizierungsstellen und Endgerätezertifikaten dargestellt wird. Wenn die AKID auf {Distinguished Name, Serial Number} basiert , wird Kontinuität erreicht. Siehe auch RFC 4518, Internet X.509 Public Key Infrastructure: Zertifizierungspfadaufbau .
0

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.

Manuel
quelle