Scadenza e rinnovo del certificato radice dell'autorità di certificazione

Nel 2004, ho creato una piccola autorità di certificazione usando OpenSSL su Linux e i semplici script di gestione forniti con OpenVPN. In conformità con le guide che ho trovato in quel momento, ho impostato il periodo di validità per il certificato CA radice su 10 anni. Da allora, ho firmato molti certificati per tunnel, siti Web e server di posta elettronica OpenVPN, tutti con un periodo di validità di 10 anni (questo potrebbe essere stato sbagliato, ma al momento non lo sapevo meglio).

Ho trovato molte guide sull'impostazione di una CA, ma solo pochissime informazioni sulla sua gestione, e in particolare su ciò che deve essere fatto alla scadenza del certificato della CA principale, che accadrà qualche tempo nel 2014. Quindi ho i seguenti domande:

• I certificati che hanno un periodo di validità che si estende dopo la scadenza del certificato CA principale non saranno più validi non appena questi ultimi scadono o continueranno ad essere validi (perché sono stati firmati durante il periodo di validità del certificato CA)?
• Quali operazioni sono necessarie per rinnovare il certificato CA principale e garantire una transizione graduale alla scadenza?
  • Posso in qualche modo ri-firmare il certificato della CA radice corrente con un periodo di validità diverso e caricare il certificato appena firmato sui client in modo che i certificati client rimangano validi?
  • O devo sostituire tutti i certificati client con quelli nuovi firmati da un nuovo certificato CA radice?
• Quando deve essere rinnovato il certificato CA principale? In scadenza o entro un termine ragionevole prima della scadenza?
• Se il rinnovo del certificato della CA principale diventa un lavoro importante, cosa posso fare meglio ora per garantire una transizione più fluida al prossimo rinnovo (ovviamente, a meno di impostare il periodo di validità a 100 anni, ovviamente)?

La situazione è resa leggermente più complicata dal fatto che il mio unico accesso ad alcuni client è tramite un tunnel OpenVPN che utilizza un certificato firmato dall'attuale certificato CA, quindi se devo sostituire tutti i certificati client, dovrò copiare i nuovi file sul client, riavvia il tunnel, incrocia le dita e spero che arrivi dopo.

Il mantenimento della stessa chiave privata nella CA principale consente a tutti i certificati di continuare a convalidare correttamente con la nuova radice; tutto ciò che ti serve è fidarti della nuova radice.

La relazione di firma del certificato si basa su una firma della chiave privata; mantenendo la stessa chiave privata (e, implicitamente, la stessa chiave pubblica) durante la generazione di un nuovo certificato pubblico, con un nuovo periodo di validità e qualsiasi altro nuovo attributo modificato in base alle necessità, mantiene in essere la relazione di fiducia. Anche i CRL possono continuare dal vecchio certificato al nuovo, così come, come i certificati, firmati dalla chiave privata.

Quindi, verificiamo!

Crea una CA principale:

openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes

Genera un certificato figlio da esso:

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

Firma il certificato bambino:

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

Tutto impostato lì, normale relazione con il certificato. Verifichiamo la fiducia:

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

Ok, quindi, diciamo che sono passati 10 anni. Generiamo un nuovo certificato pubblico dalla stessa chiave privata di root.

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

E .. ha funzionato?

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

Ma perché? Sono file diversi, giusto?

# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

Sì, ma ciò non significa che la nuova chiave pubblica non corrisponda crittograficamente alla firma sul certificato. Numeri di serie diversi, stesso modulo:

# 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

Andiamo un po 'oltre per verificare che funzioni nella convalida del certificato nel mondo reale.

Avvia un'istanza di Apache e proviamola (struttura del file debian, aggiustandola se necessario):

# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

Imposteremo queste direttive su un VirtualHostascolto su 443 - ricorda, il newroot.pemcertificato di root non esisteva nemmeno quando è cert.pemstato generato e firmato.

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

Diamo un'occhiata a come lo vede openssl:

# 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, e che ne dici di un browser che utilizza l'API crittografica di MS? Devo fidarmi del root, prima, poi va tutto bene, con il nuovo numero seriale del root:

E dovremmo continuare a lavorare anche con la vecchia radice. Cambia la configurazione di Apache:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

Fai un riavvio completo su Apache, un ricaricamento non cambierà correttamente i certificati.

# 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)

E, con il browser API crypto di MS, Apache presenta la vecchia radice, ma la nuova radice è ancora nell'archivio radice attendibile del computer. Lo troverà automaticamente e convaliderà il certificato sulla radice (nuova) attendibile, nonostante Apache presenti una catena diversa (la vecchia radice). Dopo aver rimosso la nuova radice da radici attendibili e aver aggiunto il certificato radice originale, tutto va bene:

Quindi, questo è tutto! Mantieni la stessa chiave privata quando rinnovi, scambia la nuova radice attendibile e praticamente funziona . In bocca al lupo!

Ho notato che le estensioni della CA potrebbero mancare nel certificato rinnovato della chiave CA originale. Questo ha funzionato in modo più appropriato per me (crea un ./renewedselfsignedca.conf in cui sono definite le estensioni CA v3 e si presume che ca.key e ca.crt siano la chiave e il certificato CA originali):

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

Modalità di base per estendere il periodo valido di root (sono necessari l'X.509 pubblico e la chiave privata associata):

Generare il CSR da X.509 pubblico e chiave privata:

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

Firma nuovamente il CSR con chiave privata:

openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365

@Bianconiglio plus -set_serial ha funzionato per me. Il mio server è solo intranet, quindi non mi preoccupo molto degli effetti collaterali e ora ho il tempo di lavorare su una soluzione "corretta".

Ho usato il seguente script configurabile. Basta impostare le variabili CACRT, CAKEY e 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

Quando il certificato di root scade, lo stesso vale per i certificati che hai firmato. Dovrai generare un nuovo certificato root e firmare con esso nuovi certificati. Se non vuoi ripetere il processo ogni pochi anni, l'unica vera opzione è quella di estendere la data valida sul certificato di root di qualcosa come dieci o venti anni: la radice che ho generato per il mio uso ho impostato venti anni.

Non è possibile "rinnovare" un certificato radice. Tutto quello che puoi fare è generarne uno nuovo.

Genera una nuova radice almeno uno o due anni prima che scada quella vecchia in modo da avere il tempo di cambiare senza essere contro un muro temporale se qualcosa va storto. In questo modo puoi sempre tornare temporaneamente ai vecchi certificati fino a quando non risolvi i tuoi problemi di dentizione con quello nuovo.

Per quanto riguarda i tunnel VPN, installerei un paio di server testbed con cui sperimentare in modo da capire esattamente cosa devi fare prima di farlo con la macchina di un client.

Abbiamo avuto lo stesso problema, e questo era nel nostro caso perché il server Debian non era aggiornato e openSSL aveva questo problema:

https://en.wikipedia.org/wiki/Year_2038_problem

L'ultima versione di OpenSSL disponibile per Debian 6 porta questo problema. Tutti i certificati creati dopo il 23.01.2018 producono un valore: per 1901 anni!

La soluzione è aggiornare OpenSSL. È possibile creare nuovamente i file di configurazione (con i certificati) per i client.