Réémission de l'autorité de certification racine auto-signée sans invalider les certificats signés par elle

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://[email protected]/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".

Deux certificats sont considérés comme identiques tant que le nom du sujet et la clé publique des certificats correspondent.

Par conséquent, tout ce que vous devez faire est de réutiliser les clés et de vous assurer que le nom du sujet dans le nouveau certificat est le même que l'ancien. Après cela, vous pouvez modifier n'importe lequel des autres champs et / ou extensions et le certificat résultant sera considéré comme le même.

Par exemple, créez votre fichier de configuration OpenSSL:

[ req ]

prompt             = no
string_mask        = default
distinguished_name = x509_distinguished_name
x509_extensions     = x509_ext

[ x509_distinguished_name ]

# Note that the following are in 'reverse order' to what you'd expect to see.
# Adjust for your setup:

countryName = za
organizationName = My Company
organizationalUnitName = Security
commonName = My Root CA

[ x509_ext ]

basicConstraints = critical,CA:true
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash
crlDistributionPoints = URI:http://security.mycompany.co.za/root.crl

et enregistrez-le par exemple rootca.cnf. Assurez-vous que les éléments du [req_distinguished_name]sont identiques à ceux de votre certificat racine racine (il s'agit de la partie du nom de sujet identique).

Ensuite, exécutez:

openssl req -new -x509 -key rootca.key -out MyNewCA.pem -config rootca.cnf

où rootca.keyest la clé privée utilisée dans le certificat d'origine (il s'agit de la même partie clé publique / privée).

Cela crée MyNewCA.pem, que vous pouvez vérifier avec:

$ openssl x509 -noout -text -in MyNewCA.pem

Certificate:
Data:
    Version: 3 (0x2)
    Serial Number: 17564687072266118846 (0xf3c24dd49d5166be)
Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=za, O=My Company, OU=Security, CN=My Root CA
    Validity
        Not Before: Jul 15 05:05:54 2017 GMT
        Not After : Aug 14 05:05:54 2017 GMT
    Subject: C=za, O=My Company, OU=Security, CN=My Root CA
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:c8:3d:32:8a:56:31:f6:27:1a:ce:9e:b2:1d:fb:
                ce:9f:ce:5b:42:25:aa:fe:8b:f4:34:32:ac:b3:02:
                50:71:f8:c3:43:0c:c7:2c:9f:fe:48:1b:c6:c0:e7:
                d6:44:a9:e7:d7:a0:7e:58:f4:b6:38:61:7e:d0:af:
                0f:56:21:e7:49:7a:66:13:f5:7a:fe:3d:ab:65:f8:
                01:eb:52:a7:3b:ae:a0:cf:50:57:b9:e0:09:0b:1f:
                90:14:fb:18:56:1d:57:99:a9:76:a2:63:d1:c2:d3:
                a3:f4:3a:ff:91:0d:ee:8d:44:13:58:00:09:93:da:
                e8:6a:fd:64:5f:c3:42:8e:2a:49:6e:0d:73:b7:b9:
                d4:6c:c6:ce:30:c5:82:24:a5:00:37:17:a0:1d:f1:
                c9:e9:e3:18:48:22:4f:33:96:a7:3c:a9:31:f1:3f:
                14:40:6a:74:e8:78:82:45:04:d4:4b:56:0b:cd:be:
                48:8d:03:fb:39:70:0b:91:99:70:06:bd:5e:8b:f2:
                d1:f4:6f:fc:ce:e7:f8:3c:0a:20:ea:35:b8:5f:2f:
                ee:8d:ff:d3:93:85:6b:fb:71:db:1b:e6:e9:1d:a7:
                f8:e4:ae:f4:71:fe:35:a7:89:24:af:69:a4:34:3b:
                14:66:05:02:5e:2a:1d:ac:e0:d2:48:6c:13:4e:75:
                58:93
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Basic Constraints: critical
            CA:TRUE
        X509v3 Key Usage: critical
            Certificate Sign, CRL Sign
        X509v3 Subject Key Identifier: 
            3B:45:93:3A:2A:BC:39:29:36:13:6C:BD:B6:B4:31:C7:E7:BB:32:73
        X509v3 CRL Distribution Points: 

            Full Name:
              URI:http://security.mycompany.co.za/root.crl

Signature Algorithm: sha256WithRSAEncryption
     4d:96:d4:03:4f:e3:7c:26:be:59:f8:23:87:60:f7:4c:d3:a1:
     1c:77:a1:14:e3:e7:da:c8:2a:a3:1b:06:2a:4d:55:1c:83:26:
     73:46:0d:8a:e4:b7:d1:1e:38:cc:78:90:00:01:b3:8e:f9:3c:
     62:be:04:09:90:4e:22:87:b1:aa:bd:f9:73:bd:a7:76:ad:d5:
     ae:2d:7a:1c:1e:1a:67:c8:57:4c:f9:6d:8b:62:d6:e5:ea:e0:
     40:5c:12:28:7e:ea:f0:0c:d6:cd:f4:1d:d5:56:09:ad:43:b4:
     eb:8c:68:ce:56:a2:a8:ae:a4:d5:35:bb:58:b8:ed:82:82:b5:
     ef:cb:e2:6d:76:61:ed:ee:a5:1f:68:95:07:ed:5b:f0:65:92:
     d2:dc:1d:c6:fa:7f:e0:c9:38:c2:c6:6f:03:38:e7:3a:b0:24:
     06:e0:bc:07:dd:e7:a0:dc:74:09:e5:37:7b:66:e1:6f:47:4c:
     71:ff:02:48:7f:d4:4f:ce:cb:91:e9:ee:cd:b6:f1:0a:03:19:
     3e:19:05:7d:8f:48:e7:f1:cc:07:37:3d:91:3c:6f:54:71:3c:
     a2:6c:55:c3:03:c1:7f:eb:9e:70:f1:8f:a1:fb:62:33:8b:86:
     2c:79:bc:76:e2:01:9a:68:df:af:40:a1:b2:9c:f6:a1:e1:6e:
     2a:dd:1a:d6

Utilisez ce nouveau certificat à la place de l'original.

Vous pouvez modifier d'autres champs et extensions, tels que la période de validité du certificat, mais gardez à l'esprit que vous ne devriez pas vraiment avoir de contraintes (autres que basicConstraints = critical,CA:true) sur le certificat de l'autorité de certification racine.

Après un examen plus approfondi, votre problème peut simplement être dû au fait que votre certificat d'autorité de certification racine de remplacement ne possède pas basicConstraintet éventuellement les keyUsageextensions. Il peut être utile d'essayer d'ajouter ces deux extensions à votre ext.confpremière et de tester le nouveau certificat racine CA résultant en utilisant la -x509toreqméthode que vous avez publiée.