136 votes

Jorge Alves avatar

Expiration et renouvellement du certificat racine de l'autorité de certification

Demandé el 30 de Août, 2011
Quand la question a-t-elle été
132873 affichage
Nombre de visites la question a
5 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

En 2004, j'ai mis en place une petite autorité de certification en utilisant OpenSSL sous Linux et les scripts de gestion simple fournis avec OpenVPN. Conformément aux guides que j'ai trouvés à l'époque, j'ai fixé la période de validité du certificat de l'autorité de certification racine à 10 ans. Depuis, j'ai signé de nombreux certificats pour des tunnels OpenVPN, des sites web et des serveurs de messagerie, qui ont tous également une période de validité de 10 ans (c'était peut-être faux, mais je ne savais pas mieux à l'époque).

J'ai trouvé de nombreux guides sur la mise en place d'une AC, mais très peu d'informations sur sa gestion, et en particulier, sur ce qu'il faut faire lorsque le certificat de l'AC racine expire, ce qui arrivera dans le courant de l'année 2014. J'ai donc les questions suivantes :

  • Les certificats dont la période de validité s'étend après l'expiration du certificat de l'AC racine deviendront-ils invalides dès l'expiration de ce dernier, ou continueront-ils à être valides (parce qu'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 de l'autorité de certification racine et assurer une transition en douceur à son expiration ?
    • Puis-je, d'une manière ou d'une autre, re-signer le certificat de l'autorité de certification racine actuelle avec une période de validité différente, et télécharger le nouveau certificat signé vers les clients afin que les certificats des clients restent valides ?
    • Ou dois-je remplacer tous les certificats des clients par de nouveaux certificats signés par une nouvelle autorité de certification racine ?
  • Quand le certificat de l'autorité de certification racine doit-il être renouvelé ? A l'approche de l'expiration, ou un temps raisonnable avant l'expiration ?
  • Si le renouvellement du certificat de l'autorité de certification racine devient un travail important, que puis-je faire de mieux maintenant pour assurer une transition plus douce lors du prochain renouvellement (à part fixer la période de validité à 100 ans, bien sûr) ?

La situation est rendue légèrement plus compliquée par le fait que mon seul accès à certains des clients se fait par le biais d'un tunnel OpenVPN qui utilise un certificat signé par le certificat actuel de l'autorité de certification. Donc, si je dois remplacer tous les certificats des clients, je devrai copier les nouveaux fichiers sur le client, redémarrer le tunnel, croiser les doigts et espérer qu'il se rétablisse ensuite.

Demandé el 30 de Août, 2011 par Jorge Alves

Réponses

Trop de publicités?

190voto

Shane Madden avatar
Shane Madden Points 112034

Le fait de conserver la même clé privée sur votre autorité de certification racine permet à tous les certificats de continuer à être validés avec succès par rapport à la nouvelle racine ; il vous suffit de faire confiance à la nouvelle racine.

La relation de signature du 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é si nécessaire, maintient la relation de confiance en place. Les LCR peuvent également être transférées 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 un certificat enfant à partir de celui-ci :

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

Signer le certificat de l'enfant :

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

Tout est en place, relation normale entre les certificats. Vérifions la confiance :

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

Ok, alors, maintenant disons que 10 ans ont passé. 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 du certificat. Numéros de série différents, même modulus :

# 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 le monde réel de la validation des certificats.

Lancez une instance d'Apache, et allons-y (structure de fichier debian, ajustez 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 définir ces directives dans un fichier VirtualHost l'écoute sur 443 - rappelez-vous, le 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)

Ok, et pourquoi pas un navigateur utilisant l'API cryptographique de MS ? Il faut faire confiance à la racine, d'abord, puis tout va bien, avec le numéro de série de la nouvelle racine :

newroot

Et, nous devrions toujours travailler avec l'ancienne racine, aussi. 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 d'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 des racines de confiance de l'ordinateur. Il la trouvera automatiquement et validera le certificat par rapport à la (nouvelle) racine de confiance, même si Apache présente une chaîne différente (l'ancienne racine). Après avoir supprimé la nouvelle racine des racines de confiance et ajouté le certificat de la racine originale, tout va bien :

oldroot

Alors, c'est ça ! Conservez la même clé privée lors du renouvellement, insérez la nouvelle racine de confiance, et tout est pratiquement terminé. fonctionne juste . Bonne chance !

Répondu el 4 de Septembre, 2011 par Shane Madden (112034 Points )

0 votes

Avatar de Jorge Alves

Excellente réponse, merci ! Donc tout espoir n'est pas perdu, et je n'aurai qu'à télécharger le nouveau certificat racine à tous les clients pour qu'ils le fassent confiance ? C'est encore mieux que ce que je pensais, parce qu'OpenVPN permet plusieurs certificats CA dans un seul fichier, donc je peux simplement mettre l'ancien et le nouveau certificat CA dans un seul fichier et la transition devrait être transparente.

Commenté el 4 de Septembre, 2011 par Jorge Alves

0 votes

Avatar de Shane Madden

@Remy Oui, vous devrez vous assurer que tout ce qui présente une chaîne de certificats commence à présenter le nouveau certificat avant que l'ancien n'expire, et vous voudrez probablement retirer l'ancien des racines de confiance avant qu'il n'expire, mais tous les certificats émis contre l'ancienne racine devraient être validés sans problème contre la nouvelle racine.

Commenté el 5 de Septembre, 2011 par Shane Madden

5 votes

Avatar de jvhashe

Quoi qu'il en soit, quel est l'intérêt de créer un nouveau certificat racine si c'est pour réutiliser la même clé privée ? Si vous continuez à faire cela encore et encore, alors quel est l'intérêt d'avoir une date d'expiration pour le certificat ? Je pensais que l'expiration de la racine était utilisée pour forcer les administrateurs à créer une clé privée plus récente (très probablement plus forte) qui soit plus sûre contre les machines en constante évolution qui tentent de casser les clés. Une clé de 40 bits fabriquée il y a 20 ans n'est pas assez sûre pour que l'on puisse l'utiliser.

Commenté el 22 de Août, 2013 par jvhashe
Afficher 9 autres commentaires

21voto

Bianconiglio avatar
Bianconiglio Points 171

J'ai remarqué que les extensions de l'autorité de certification pouvaient manquer dans le certificat renouvelé de la clé originale de l'autorité de certification. Cette méthode a fonctionné de manière plus appropriée pour moi (elle crée un fichier ./renewedselfsignedca.conf où les extensions v3 CA sont définies, et ca.key y ca.crt sont supposés être la clé et le certificat originaux de l'autorité de certification) :

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
Répondu el 22 de Avril, 2013 par Bianconiglio (171 Points )

2 votes

Avatar de Grantismo

Il s'agit d'un ajout extrêmement utile. La réponse valide n'aboutit pas à un certificat suffisamment compatible pour moi si vous avez des paramètres arbitraires sur votre ca racine d'origine.

Commenté el 2 de Décembre, 2014 par Grantismo

1 votes

Avatar de easycheese

Je suis d'accord, c'est très utile. Autre ajout : comme Scott Presnell dans les commentaires de la réponse acceptée, j'ai également dû spécifier manuellement le numéro de série hexadécimal du nouveau certificat afin qu'il corresponde à l'ancien. Pour ce faire, j'ai dû ajouter -set_serial 0xdeadbeefabba (pas le vrai numéro de série :) ) à la dernière commande x509. Ce n'est qu'à ce moment-là que les certificats de mes clients ont été vérifiés avec succès par rapport au certificat renouvelé de l'autorité de certification.

Commenté el 19 de Mai, 2015 par easycheese

0 votes

Avatar de lepe

Cette méthode est plus simple car elle conserve les mêmes informations que le certificat précédent.

Commenté el 4 de Novembre, 2016 par lepe
Afficher 2 autres commentaires

4voto

msEmmaMays avatar
msEmmaMays Points 101

Mode de base pour prolonger la période de validité de la racine (vous avez besoin de la clé publique X.509 et de la clé privée associée) :

Générer le CSR à partir de la clé publique X.509 et de la clé privée :

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

Re-signez le CSR avec la clé privée :

openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365
Répondu el 22 de Janvier, 2013 par msEmmaMays (101 Points )

0 votes

Avatar de relet

Ces commandes ont fonctionné pour moi, avec une autorité de certification locale/auto-signée, alors que la réponse précédente a échoué avec unable to verify the first certificate pendant la vérification openssl.

Commenté el 30 de Novembre, 2020 par relet

4voto

Wolfgang Fahl avatar
Wolfgang Fahl Points 555

@Bianconiglio plus -set_serial a fonctionné pour moi. Mon serveur n'est qu'un intranet, je ne m'inquiète donc pas trop des effets secondaires et j'ai maintenant le temps de travailler à une solution "appropriée".

J'ai utilisé le script configurable suivant. Il suffit de définir les variables CACRT , CAKEY y 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
Répondu el 30 de Juin, 2017 par Wolfgang Fahl (555 Points )

3voto

Snowhare avatar
Snowhare Points 157

Lorsque votre certificat racine expire, il en va de même pour les certificats que vous avez signés avec lui. Vous devrez générer un nouveau certificat racine et signer de nouveaux certificats avec celui-ci. Si vous ne voulez pas répéter le processus tous les quelques années, la seule véritable option est de prolonger la date de validité du certificat racine de quelque chose comme dix ou vingt ans : La racine que j'ai générée pour mon propre usage a été fixée à 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 l'ancienne, afin d'avoir le temps de passer à la nouvelle racine sans vous heurter à un mur du temps en cas de problème. De cette façon, vous pourrez toujours revenir temporairement aux anciens certificats jusqu'à ce que les problèmes de démarrage du nouveau soient résolus.

En ce qui concerne les tunnels VPN, je mettrais en place quelques serveurs de test pour les expérimenter afin de comprendre précisément ce que vous devez faire avant de le faire avec la machine d'un client.

Répondu el 4 de Septembre, 2011 par Snowhare (157 Points )

0 votes

Avatar de Jorge Alves

Cette réponse semble suggérer qu'il est possible de renouveler un certificat racine en réutilisant sa clé. Mais je soupçonne que ce n'est pas différent de repartir de zéro, car le nouveau certificat aura une signature différente et ne validera donc pas les certificats des clients existants.

Commenté el 4 de Septembre, 2011 par Jorge Alves

0 votes

Avatar de msEmmaMays

Oui, vous pouvez prolonger la période de validité... et c'est moins de travail que de recréer tous les pki, les certificats des clients, et de refaire confiance à la nouvelle racine...

Commenté el 22 de Janvier, 2013 par msEmmaMays

0 votes

Avatar de Utilisateur non enregistré

La partie concernant la délivrance de nouveaux certificats d'entité finale n'est pas nécessairement vraie. Cela dépend de la manière dont l'identifiant de la clé de l'autorité (AKID) est représenté dans les AC subordonnées et les certificats d'entité finale. Si l'AKID est basé sur {nom distinctif, numéro de série} la continuité sera assurée. Voir aussi RFC 4518, Internet X.509 Public Key Infrastructure : Construction du chemin de certification .

Commenté el 31 de Mars, 2016 par Utilisateur non enregistré

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X