Come creare e utilizzare correttamente certificati e certificati con firma incrociata

OK, questo è il migliore che ho trovato finora.

Il problema con l'elaborazione della profondità, credo, è solo OpenSSL. Non va bene che non possa costruire percorsi adeguati. RFC-5280, Sec 6.1 dice:

A certificate MUST NOT appear more than once in a prospective certification path.

OpenSSL probabilmente viola questo. Tuttavia, devo dire che non vedo una spiegazione in RFC-5280 su come costruire percorsi, tranne per il suo Sec 3.2 ; vi è il suggerimento che i percorsi devono terminare con una CA autofirmata singola alla fine di ogni catena (che, tuttavia, contraddice le affermazioni secondo cui la catena di verifica non dovrebbe avere ancore di fiducia, ma i trust ancore possono contenere certs, che rende il lato post-catena contiene più certificati, dove OpenSSL termina con loop infinito). Ad ogni modo, non sono d'accordo con ciò che OpenSSL sta facendo.

Devo anche dire che ciò di cui stavo parlando non è solo un certificato con firma incrociata, ma si tratta di certificati reciprocamente incrociati. L'ovvia differenza è che i normali cross-signed non creano una dipendenza così circolare, e si ottiene avendo un'ancora di trust da una CA che è firmata da un'altra CA (dal punto di vista del verificatore, è lo stesso caso di un intermediario di fiducia , AFAIU).

Il modo per farlo funzionare con OpenSSL, è quello di non aggiungere certificati incrociati nella lista di fiducia, ma di fornirli come parte dei certificati intermedi prodotti dal titolare della chiave.

Se metto tutto autofirmato in trust.pem , tutti i cross-certs in untrust.pem , quindi il verificatore funziona, anche se sputa gli errori intermedi (che ha senso in quanto non tutti gli alberi si compilano / verificano con successo):

Qui sono presenti entrambe le radici:

$  openssl verify -verbose -CAfile trust.pem -untrusted nontrust.pem host1/cert.pem 
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 24 at 2 depth lookup:invalid CA certificate
OK

Qui c'è solo uno o un altro presente di root:

$  openssl verify -verbose -CAfile ca1/ca1.pem -untrusted nontrust.pem host1/cert.pem 
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 24 at 2 depth lookup:invalid CA certificate
OK
$  openssl verify -verbose -CAfile ca2/ca2.pem -untrusted nontrust.pem host1/cert.pem 
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
OK

Che mostra la parte più interessante della cross signing che possiamo aggiungere una CA a un'autorità di certificazione e mantenere attivi i certificati originali.

TUTTAVIA

RFC-5246, Sez. 7.4.2 che documenta TLS 1.2 dice che il server ha solo una catena da presentare al client (e viceversa). Se i certificati con firma incrociata non possono far parte dell'archivio fiduciario, il cliente deve fornire catene multiple per verificare che vi siano opzioni. Quindi, sì, funziona in teoria, ma non con SSL (potrebbe funzionare con altri protocolli di verifica, non ho verificato), almeno nella sua implementazione OpenSSL.

Vorrei iniziare dicendo che nella mia risposta è incluso un po 'di congetture. La mia ipotesi migliore è che tu abbia emesso 2 certificati foglia e che l'emittente di un certificato punti all'altro e viceversa, causando il ciclo.

Non ho provato a riprodurre il tuo problema da solo, ma ho giocato con il cross signing. Il sito LE ( Cross Signing di LE ) e i tuoi suggerimenti, mi hanno permesso di pubblicare e utilizzare certificati incrociati. Il mio obiettivo non era la resilienza di root di CA, ma il rollover di CA root. Se il tuo ruolo è CA, in pratica non è molto diverso da quello che hai cercato di ottenere. I fattori critici sono:

• Il campo Oggetto deve essere identico (vedi anche sopra)
• Le chiavi devono essere identiche (vedi anche sopra)
• I certificati devono avere un emittente diverso e 1 può essere autofirmato, come la mia applicazione

In parte come il collegamento LE, ho creato un certificato intermedio con firma incrociata e un nuovo certificato radice. Un certificato intermedio permanente (PATHLEN: 0) è firmato da uno dei 2 certificati incrociati, non importante quale, poiché il soggetto e le chiavi sono identici. Suggerimento: riutilizzare il CSR dei to-be cross-certs per entrambi, quindi il Subject non può essere sbagliato. Sulla croce firmata (temp.) CERT intermedio, ho impostato il PATHLEN su 1 (non può essere 0!)

Per essere chiari:

• Percorso 1 (vecchia radice): Cert foglia, perm. Certificato intermedio, temp. Cert intermedio, "vecchio" certificato radice
• Percorso 2 (nuova radice): Cert foglia, perm. Cert intermedio, 'nuovo' cert root

Puoi giocare con SAN e date di inizio / fine che ti piacciono. Il cert intermedio (temp o roll-over) nel "vecchio" percorso radice ha una validità di 5 anni, la "nuova" radice 10 anni. Dopo aver importato il 'nuovo' certificato radice, il percorso più breve (4 → 3) è stato immediatamente utilizzato da Firefox. Nel mio caso è necessario caricare 3 certificati sul server Web: leaf cert, perm. certificato intermedio, temp. intermedio ('vecchio' root / temp / roll-over) cert.

OpenSSL non mi ha deluso per testare il certificato foglia per un percorso valido. Ho usato lo strumento di verifica di OpenSSL con CAfile per la root nel percorso e non affidabile per i certificati intermedi usati. Entrambi i percorsi verso la vecchia e la nuova radice potrebbero essere verificati in questo modo.

Come utente finale (non CA), se si desidera avere resilienza, dovrebbe funzionare con 1 CSR per ottenere (ordine) certificati foglia da 2 CA e caricare il server Web con quei 2 certificati concatenati con il Certificato intermedio dalla CA di emissione. Quindi 4 certificati in totale.