J'ai créé une autorité de certification racine auto-signée pour quelques services internes dans notre entreprise, que j'ai configurée moi-même (principalement servie via HTTPS). J'ai ensuite créé des certificats pour ces services, signés avec cette autorité de certification.
Maintenant, je veux ajouter une extension x509 (point de distribution CRL) à l'autorité de certification racine sans invalider les certificats de serveur existants émis par cette autorité de certification. Est-ce possible?
Mon intuition est "oui" car, si je comprends bien, l'accès à la clé privée correspondante est nécessaire et suffisant pour une "pleine autorité" sur l'identité du certificat. C'est-à-dire, à moins qu'une sorte de nonce ne soit incorporée avec la clé publique dans le certificat lors de sa génération (probable).
Je suis encore relativement nouveau dans la gestion des certificats SSL, mais je pense (je pense) comprendre les bases de la chaîne de confiance standard. Je suis également à l'aise avec l'utilisation de base d'autres crypto PKI: je gère les clés SSH et j'utilise GPG pour la signature et le cryptage. J'ai étudié l'informatique, bien que je ne sois qu'un autodidacte en cryptographie.
Je n'ai jamais fait de CSR pour l'IIRC d'origine (je pense que c'était la sortie directe de openssl req -new -x509). J'ai toujours la clé privée de l'autorité de certification d'origine, bien sûr, et en l'utilisant, j'ai pu "inverser" le certificat d'origine en une demande de signature de certificat:
openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key
J'espérais que cela "extrairait" effectivement le nonce mentionné ci-dessus et me permettrait de recréer le certificat, mais cette fois avec un crlDistributionPointschamp, et par conséquent tous les certificats signés avec l'autorité de certification d'origine continueraient à être validés par rapport à cette nouvelle autorité de certification, à l'exception que les clients récupéreraient mon fichier CRL (actuellement vide) à partir de l'URL HTTP indiquée dans le champ.
J'ai donc fait un fichier de configuration d'extension ext.conf:
[ cert_ext ]
subjectKeyIdentifier=hash
crlDistributionPoints=URI:http://security.mycompany.co.za/root.crl
Et j'ai généré la nouvelle version de l'autorité de certification racine à partir du CSR:
openssl x509 -extfile ./ext.conf -extensions cert_ext -req -signkey private/MyCA.key -in MyCA.csr -out MyNewCA.pem
Maintenant, quand je vois le certificat avec openssl x509 -text -in MyNewCA.pem | less
Je peux voir la partie d'extension CRL:
X509v3 extensions:
X509v3 Subject Key Identifier:
82:D0:01:03:49:FF:30:16:FA:DC:0A:1E:C1:8C:3D:66:A1:78:FF:F8
X509v3 CRL Distribution Points:
Full Name:
URI:http://security.mycompany.co.za/root.crl`
Mais hélas! Mes certificats précédemment signés ne valident plus par rapport à celui-ci:
openssl verify -verbose -CAfile MyCA.pem git.pem
git.pem: OK
openssl verify -verbose -CAfile MyNewCA.pem git.pem
git.pem: <redacted DN>
error 20 at 0 depth lookup:unable to get local issuer certificate
Surtout, je cherche plus d'informations sur le fonctionnement des certificats et pourquoi. Mais j'accueillerais également une solution au problème qui a conduit à celui-ci, alors voici également quelques informations générales.
Comment je me suis retrouvé dans ce pétrin: HTTPS pour les services internes fonctionne très bien une fois que mon autorité de certification est installée via l'explorateur RMB → Installer le GUI du certificat sous Windows, ou le /usr/local/share/ca-certificatessuivi de update-ca-certificatesDebian et Ubuntu. Mais j'ai récemment rencontré une exception: Git sur Windows, en particulier s'il est installé pour utiliser Windows Secure Channel comme back-end SSL. Ce qui, apparemment par défaut, insiste sur le fait qu'il doit y avoir un champ CRL dans les certificats SSL.
Donc je suppose que c'est vraiment un problème de canal sécurisé Windows car le message d'erreur dans lequel je continue de fonctionner semble entièrement spécifique à Microsoft: fatal: unable to access 'https://angery@git.mycompany.co.za/gitblit/r/secret_project.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
Si j'installe Git avec OpenSSL et que je concatène manuellement mon autorité de certification sur le fichier pointé par git.http.sslcainfo, cela fonctionne, mais je crains que mes utilisateurs ne soient enclins à ne pas procéder à la vérification d'identité SSL s'ils estiment que ce processus demande plus d'efforts que en cliquant sur l'interface graphique d'installation du certificat Windows "facile".
-x509toreqcela récupérerait toutes les informations uniques de l'autorité de certification racine existante, mais ce n'est pas le cas ou il y a un problème avec mon processus à partir de là.
req -new -x509et les x509 -req -signkeydeux par défaut la série du certificat auto-signé à un nombre aléatoire (bien que cela puisse être remplacé) est un nonce. Si votre certificat enfant (ou l'un d'eux) contient AuthorityKeyIdentifier en utilisant l'option 'issuer + serial' (au lieu ou en plus de l'option 'keyid'), ce qui sera le cas si vous l'utilisiez caavec le fichier de configuration par défaut en amont, vous besoin de créer la nouvelle racine avec la même série que l'ancienne; utiliser -set_serial. ...