Ho creato un'Autorità di certificazione radice autofirmata per alcuni servizi interni nella nostra azienda, che mi sono configurata (principalmente servita su HTTPS). Quindi ho creato certificati per tali servizi, firmati con questa CA.
Ora voglio aggiungere un'estensione x509 (punto di distribuzione CRL) alla CA principale senza invalidare i certificati server esistenti emessi da questa CA. È possibile?
Il mio istinto è "sì" perché, a quanto ho capito, l'accesso alla chiave privata corrispondente è necessario e sufficiente per la "piena autorità" sull'identità del certificato. Cioè, a meno che non vi sia una sorta di nonce incorporato insieme alla chiave pubblica nel certificato quando viene generato (probabilmente).
Sono ancora abbastanza nuovo nella gestione dei certificati SSL, ma (penso di) comprendere le basi della catena di fiducia standard. Sono anche a mio agio con l'uso di base di altre crittografie PKI: gestisco le chiavi SSH e utilizzo GPG per la firma e la crittografia. Ho studiato Informatica, anche se sono solo un dilettante autodidatta in crittografia.
Non ho mai realizzato un CSR per il IIRC originale (penso che sia stato il risultato diretto di openssl req -new -x509). Naturalmente ho ancora la chiave privata della CA originale e, usando questa opzione, sono stato in grado di "invertire" il certificato originale in una richiesta di firma del certificato:
openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key
Speravo che questo avrebbe effettivamente "estratto" il nonce sopra menzionato e mi avrebbe permesso di ricreare il certificato ma questa volta con un crlDistributionPointscampo, e di conseguenza tutti i certificati firmati con la CA originale sarebbero ancora validi contro questa nuova CA, con l'eccezione che i client avrebbero recuperato il mio file CRL (attualmente vuoto) dall'URL HTTP designato nel campo.
Quindi ho creato un file di configurazione dell'estensione ext.conf:
[ cert_ext ]
subjectKeyIdentifier=hash
crlDistributionPoints=URI:http://security.mycompany.co.za/root.crl
E ho generato la nuova versione della CA principale dal CSR:
openssl x509 -extfile ./ext.conf -extensions cert_ext -req -signkey private/MyCA.key -in MyCA.csr -out MyNewCA.pem
Ora quando visualizzo il certificato con openssl x509 -text -in MyNewCA.pem | less
Riesco a vedere la parte di estensione 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`
Ma ahimè! I miei certificati precedentemente firmati non convalidano più rispetto a questo:
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
Principalmente sto cercando maggiori informazioni su come funzionano i certificati e perché. Ma gradirei anche una soluzione al problema che porta a questo, quindi ecco anche alcune informazioni di base.
Come sono entrato in questo casino: HTTPS ai servizi interni funziona alla grande una volta che la mia CA è installata tramite Explorer RMB → Installa la GUI del certificato su Windows o /usr/local/share/ca-certificatesseguita da update-ca-certificatesDebian e Ubuntu. Ma di recente ho riscontrato un'eccezione: Git su Windows, in particolare se installato per utilizzare Windows Secure Channel come back-end SSL. Che apparentemente insiste per impostazione predefinita che ci deve essere un campo CRL nei certificati SSL.
Quindi immagino che sia davvero un problema di Windows Secure Channel perché il messaggio di errore che continuo a eseguire sembra interamente specifico di 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.
Se installo Git con OpenSSL e concateno manualmente la mia CA sul file indicato da git.http.sslcainfo, allora funziona, ma temo che i miei utenti saranno inclini a non dare seguito alla verifica dell'identità SSL se ritengono che questo processo sia più impegnativo di facendo clic sulla "facile" GUI del programma di installazione dei certificati di Windows.
-x509toreqavrebbe recuperato tutte le informazioni uniche dalla CA radice esistente, ma o non lo fa o c'è qualcosa di sbagliato nel mio processo da lì.
req -new -x509ed x509 -req -signkeyentrambi predefiniscono il seriale del certificato autofirmato su un numero casuale (sebbene questo possa essere sovrascritto) effettivamente un nonce. Se il tuo figlio cert (o uno di essi) contiene AuthorityKeyIdentifier utilizzando l'opzione 'issuer + serial' (invece di o in aggiunta all'opzione 'keyid'), che sarà il caso se hai usato cacon il file di configurazione predefinito upstream, tu è necessario creare il nuovo root con lo stesso seriale di quello vecchio; usare -set_serial. ...