Ho creato una nuova Autorità di certificazione attendibile che rilascia un certificato all'entità finale e l'entità finale userà questo certificato come affidabile per tutte le sue operazioni PKI. Alcuni come la chiave CA radice è stata compromessa.
Ora la mia domanda qui è come posso revocare la CA ROOT come autofirmata?
La revoca in realtà sta cancellando l'emissione del certificato - la CA che ha firmato il certificato annuncia che ora lo nega. Una CA radice rilasciata automaticamente non può essere revocata. Una CA root , per definizione, è a priori di fiducia, non perché il suo certificato è stato firmato da una CA più in alto nella gerarchia. Pertanto, non c'è nessuno che possa emettere informazioni di revoca che sarebbero autorevoli su quella CA.
Alcuni commenti extra devono essere fatti, però:
Non revochi una CA; revochi un certificato . Qualsiasi entità che ha un nome e possiede una coppia di chiavi, in particolare una CA, può possedere diversi certificati. Ogni certificato è un'affermazione di tale proprietà chiave. Ciò che si pensa come una "CA radice" può anche essere una CA intermedia nel senso seguente: oltre al certificato autofirmato (tradizionalmente autofirmato), può anche aver ottenuto un altro certificato che contiene il suo nome e la sua chiave pubblica, e rilasciato (firmato) da un'altra CA. Il secondo certificato, emesso da una CA distinta, può essere revocato. Questo tipo di situazione è comune in caso di "rinnovo CA root" (viene creata una nuova CA radice e vengono emessi "certificati incrociati" in modo che la transizione sia scorrevole).
Quali certificati non possono fare, forse altri sistemi possono. Ad esempio, un browser Web può contenere un elenco di CA radice attendibile a priori (per la convalida dei certificati server SSL); quindi, qualsiasi aggiornamento dell'eseguibile del browser può aggiungere o rimuovere CA principale. Non è presente alcun CRL, ma sicuramente sembra un meccanismo di revoca, soprattutto perché i browser moderni si aggiornano automaticamente. Windows ha un sistema simile con un archivio di certificati "non consentito" che agisce come un super-CRL imposto dal sistema operativo che può rendere qualsiasi certificato non attendibile, anche certificati CA radice aggiunti esplicitamente all'archivio di root attendibili.
Il tentativo di creare un CRL contenente il numero di serie della radice compromessa, come suggerito in un'altra risposta, non avrà l'effetto desiderato, per due motivi:
I sistemi che convalidano i certificati (ad es. client SSL durante il tentativo di verificare il certificato del server) scaricano CRL solo per i certificati dove ha senso, cioè non per CA radice, poiché non possono verificare la firma sul salvataggio CRL relativamente a la chiave pubblica della CA più in alto nella catena, poiché non esiste tale CA. Puoi scrivere ciò che vuoi in qualsiasi CRL; se i clienti non lo guardano, non ti porteranno lontano.
Anche se potresti in qualche modo convincere un cliente a scaricare quel "CRL suicida", in cui la CA radice si uccide, ricorda che la chiave privata è stata compromessa, quindi il ladro di chiavi potrebbe produrre e firmare un CRL controcorrente questo dice che va tutto bene e nessuno viene revocato. Poiché il download del CRL non può essere protetto in altro modo, l'autore dell'attacco può impedire che il meccanismo di autodistruzione si verifichi, anche supponendo che avrebbe funzionato con i client esistenti (e non lo fa).
effettuare una revoca dei certificati per il certificato di origine ed esportarlo in un elenco di revoche di certificazione, inserendolo nella posizione specificata, verrà inserito il CRL.
Leggi altre domande sui tag public-key-infrastructure