Expiration et renouvellement du certificat racine de l'autorité de certification
En 2004, j'ai mis en place une petite autorité de certification utilisant OpenSSL sur Linux et les scripts de gestion simples fournis avec OpenVPN. Conformément aux guides que j'ai trouvés à l'époque, j'ai défini la période de validité du certificat d'autorité de certification racine sur 10 ans. Depuis lors, j'ai signé de nombreux certificats pour les tunnels OpenVPN, les sites Web et les serveurs de messagerie, qui ont également une période de validité de 10 ans (cela peut être faux, mais je ne savais pas mieux à l'époque).
J'ai trouvé de nombreux guides sur la mise en place d'une autorité de certification, mais seulement très peu d'informations sur sa gestion, et en particulier sur ce qui doit être fait lorsque le certificat de l'autorité de certification racine expire, ce qui se produira en 2014. J'ai donc les informations suivantes des questions:
- Les certificats dont la période de validité s'étend après l'expiration du certificat racine de l'AC deviendront-ils invalides dès leur expiration, ou continueront-ils d'être valides (car ils ont été signés pendant la période de validité du certificat de l'AC)?
- Quelles opérations sont nécessaires pour renouveler le certificat d'autorité de certification racine et assurer une transition en douceur au cours de son expiration?
- Puis-je en quelque sorte re-signer le certificat d'autorité de certification racine actuel avec une période de validité différente et télécharger le certificat nouvellement signé sur les clients afin que les certificats clients restent valides?
- Ou dois-je remplacer tous les certificats clients par de nouveaux certificats signés par un nouveau certificat d'autorité de certification racine?
- Quand faut-il renouveler le certificat d'autorité de certification racine? Proche de l'expiration, ou un délai raisonnable avant l'expiration?
- Si le renouvellement du certificat d'autorité de certification racine devient un travail majeur, que puis-je faire de mieux maintenant pour assurer une transition plus fluide lors du prochain renouvellement (à moins de fixer la période de validité à 100 ans, bien sûr)?
La situation est rendue un peu plus compliquée par le fait que mon seul accès à certains clients se fait via un tunnel OpenVPN qui utilise un certificat signé par le certificat CA actuel, donc si je dois remplacer tous les certificats clients, je devrai copier les nouveaux fichiers au client, redémarrez le tunnel, croisez les doigts et espérez qu'il revienne après.
Garder la même clé privée sur votre autorité de certification racine permet à tous les certificats de continuer à valider avec succès par rapport à la nouvelle racine; tout ce qui vous est demandé est de faire confiance à la nouvelle racine.
La relation de signature de certificat est basée sur une signature de la clé privée; conserver la même clé privée (et, implicitement, la même clé publique) tout en générant un nouveau certificat public, avec une nouvelle période de validité et tout autre nouvel attribut modifié au besoin, maintient la relation d'approbation en place. Les listes de révocation de certificats peuvent également continuer de l'ancien certificat au nouveau, car elles sont, comme les certificats, signées par la clé privée.
Alors vérifions!
Créez une autorité de certification racine:
openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes
Générez-y un certificat enfant:
openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr
Signez le certificat enfant:
openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr
Tout est là, relation de certificat normale. Vérifions la confiance:
# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK
Ok, alors disons maintenant que 10 ans se sont écoulés. Générons un nouveau certificat public à partir de la même clé privée racine.
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
Et .. ça a marché?
# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK
Mais pourquoi? Ce sont des fichiers différents, non?
# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020 newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899 origroot.pem
Oui, mais cela ne signifie pas que la nouvelle clé publique ne correspond pas cryptographiquement à la signature sur le certificat. Numéros de série différents, même module:
# 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
Allons un peu plus loin pour vérifier que cela fonctionne dans la validation des certificats dans le monde réel.
Lancez une instance Apache, et essayons-la (structure du fichier Debian, ajustez-la si nécessaire):
# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/
Nous allons mettre ces directives sur une VirtualHost écoute sur 443 - rappelez-vous, la newroot.pem le certificat racine n'existait même pas lorsque cert.pem a été généré et signé.
SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem
Voyons comment openssl le voit:
# 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)
D'accord, et que diriez-vous d'un navigateur utilisant l'API de chiffrement de MS? Je dois faire confiance à la racine, d'abord, puis tout va bien, avec le numéro de série de la nouvelle racine:
Et, nous devrions également continuer à travailler avec l'ancienne racine. Changez la configuration d'Apache:
SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem
Faites un redémarrage complet sur Apache, un rechargement ne changera pas les certificats correctement.
# 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)
Et, avec le navigateur MS crypto API, Apache présente l'ancienne racine, mais la nouvelle racine est toujours dans le magasin racine de confiance de l'ordinateur. Il le trouvera automatiquement et validera le certificat par rapport à la (nouvelle) racine de confiance, bien qu'Apache présente une chaîne différente (l'ancienne racine). Après avoir retiré la nouvelle racine des racines de confiance et ajouté le certificat racine d'origine, tout va bien:
Alors c'est tout! Gardez la même clé privée lorsque vous renouvelez, échangez dans la nouvelle racine de confiance, et c'est à peu près tout fonctionne juste. Bonne chance!
J'ai remarqué que des extensions CA pouvaient être manquantes dans le certificat renouvelé de la clé CA d'origine. Cela a fonctionné de manière plus appropriée pour moi (cela crée un ./ renouvelé soi-même signé.conf où les extensions CA v3 sont définies, et ca.key et ca.crt = sont supposés être la clé et le certificat CA d'origine):
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
Mode de base pour étendre la période valide de root (vous avez besoin du X.509 public et de la clé privée associée):
Générez la CSR à partir du X.509 public et de la clé privée:
openssl x509 -x509toreq -in XXX.crt -signkey XXX.key -out XXX.csr
Re-signer le CSR avec la clé privée:
openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365
@Bianconiglio plus -set_serial a fonctionné pour moi. Mon serveur est uniquement intranet, donc je ne m'inquiète pas trop des effets secondaires et j'ai maintenant le temps de travailler sur une "bonne" solution.
J'ai utilisé le script configurable suivant. Définissez simplement les variables CACRT, CAKEY et 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
Lorsque votre certificat racine expire, les certificats que vous avez signés le font également. Vous devrez générer un nouveau certificat racine et signer de nouveaux certificats avec lui. Si vous ne voulez pas répéter le processus toutes les quelques années, la seule vraie option est de prolonger la date de validité sur le certificat racine quelque chose comme dix ou vingt ans: la racine que j'ai générée pour mon propre usage, je l'ai définie sur vingt ans.
Vous ne pouvez pas "renouveler" un certificat racine. Tout ce que vous pouvez faire est d'en générer un nouveau.
Générez une nouvelle racine au moins un an ou deux avant l'expiration de votre ancienne afin d'avoir le temps de changer sans être contre un mur du temps en cas de problème. De cette façon, vous pouvez toujours revenir temporairement aux anciens certificats jusqu'à ce que vos problèmes de dentition avec le nouveau soient résolus.
En ce qui concerne les tunnels VPN, je configurerais quelques serveurs de banc d'essai pour expérimenter afin que vous compreniez précisément ce que vous devez faire avant de le faire avec la machine d'un client.
Nous avons eu le même problème, et c'était dans notre cas parce que le serveur Debian était à jour, et l'openSSL avait ce problème:
https://en.wikipedia.org/wiki/Year_2038_problem
La dernière version d'OpenSSL disponible pour Debian 6 apporte ce problème. Tous les certificats créés après le 23.01.2018 produisent une valeur: pour l'année 1901!
La solution est de mettre à jour l'OpenSSL. Vous pouvez recréer les fichiers de configuration (avec les certificats) pour les clients.