Una CA intermedia può essere considerata affidabile come una CA radice autofirmata?

Una CA principale è in realtà un'illusione. In X.509 , ci sono ancore di fiducia . Un'ancora di fiducia è, per lo più, un nome e una chiave pubblica, che conosci a priori e di cui ti fidi. La rappresentazione di quel nome e quella chiave pubblica come "file di certificato" (tradizionalmente autofirmato) è solo un modo conveniente per mantenere l'ancoraggio sicuro come un mucchio di byte.

Come per X.509, una CA è "intermedia" solo se non ti fidi di essa a priori; non è una proprietà intrinseca della CA. Quello che devi fare è convincere il tuo software a considerare la CA come un'ancora di fiducia. Un possibile trucco è quello di ricodificare i dati rilevanti (il nome della CA e la chiave pubblica) come un certificato autofirmato (presumibilmente). Si noti che l'auto-firma è solo una Tradizione; è lì soprattutto perché il formato del file per un certificato ha un campo obbligatorio per una firma. Per una CA "root", questa firma non ha alcun significato (non ha molto senso verificarla, dal momento che non comprerebbe nulla di sicurezza). Pertanto, le applicazioni che utilizzano certificati CA radice raramente verificano che la firma sia "self".

Pertanto, potresti creare un certificato "autofirmato" personalizzato con il nome della tua "CA intermedia" come SubjectDN e IssuerDN . Per la firma, inserire solo byte di posta indesiderata di circa la dimensione corretta (256 byte per una firma a 2048 bit). Quindi, prova a impostare questo certificato pseudo-autofirmato come root: è probabile che funzioni con la tua VPN. In alternativa, crea la tua CA radice ed emetterai un certificato extra per la CA intermedia (non hai bisogno della cooperazione della CA intermedia per questo, hai solo bisogno del suo nome e della chiave pubblica, e hai questi, nel certificato CA intermedio ).

Secondo l'RFC sulla convalida del certificato - RFC 3280 - Sezione 6.2:

The selection of one or more trusted CAs is a local decision. A system may provide any one of its trusted CAs as the trust anchor for a particular path. The inputs to the path validation algorithm may be different for each path. The inputs used to process a path may reflect application-specific requirements or limitations in the trust accorded a particular trust anchor. For example, a trusted CA may only be trusted for a particular certificate policy. This restriction can be expressed through the inputs to the path validation procedure.

Può darsi che tu abbia qualche problema grave, ad esempio, se le estensioni della politica nel certificato CA indicano che deve essere verificata da CRL o OSCP, allora potresti avere un blocco legittimo nella tua applicazione quando non è in grado di trovare la CA radice per verificare parti di questo processo - ad esempio i CRL possono essere firmati dalla CA radice, quindi se la CA radice non è disponibile nel trust store, l'applicazione potrebbe non essere in grado di gestire situazione.

Sembra che, in base alla RFC, dovresti essere in grado di impostare un certificato CA intermedio che possa fungere da ancoraggio affidabile e dovresti essere in grado di creare una serie di impostazioni dei criteri che funzionano. Posso dire per esperienza, tuttavia, che sei entrato nel dubbio regno di "forse". Stai proponendo qui una configurazione non standard che non è tipica. La maggior parte delle volte, la CA radice è usata qui perché è la cosa di livello più alto là fuori, e nel lungo periodo, il provisioning dell'ancora di fiducia è solitamente piuttosto peloso che la gente è felice di andare con la più alta potenza di fiducia ed evitare qualsiasi necessità di aggiungere nuovi CA all'app nel tempo. Il regno di impostare correttamente le estensioni delle policy e di far giocare l'app è Advanced PKI Vodoo - i messaggi di errore sono spesso assurdi, c'è un supporto tecnico minimo e può richiedere un po 'di tempo per farlo funzionare correttamente.

È probabile che i suoni rappresentino una mancanza di implementazione, piuttosto che una deliberata decisione di progettazione.

Concettualmente, se aggiungi il certificato CA intermedio al tuo insieme di trust ancore (CA di cui ti fidi e quindi accetti cose firmate da loro), allora un client dovrebbe essere disposto ad accettare altri certificati firmati da quella CA, anche se quella CA non è la radice della catena. Quello sarebbe un modo eminentemente ragionevole per un cliente o un comportamento. Tuttavia, questo potrebbe essere un caso d'uso che non è molto comune e che gli sviluppatori di applicazioni non hanno considerato, quindi il loro codice potrebbe non supportarlo. C'est la vie.

Il sistema funziona come previsto. Per definizione, un certificato intermedio viene emesso da e si affida alla relazione di trust assegnatagli dal trust tra il client e il certificato della CA radice. La CA radice è autofirmata e attendibile dal client, la CA intermedia è firmata dalla CA radice.

In termini semplici, la CA intermedia dice "hey, io sono un CA, puoi fidarti di me perché sono firmato dalla CA radice di cui ti fidi già". Il client quindi cerca di vedere se effettivamente si fida della CA radice e se tale relazione di fiducia è stata stabilita, la gerarchia dei certificati (catena di certificati) viene convalidata e il certificato può essere utilizzato.

Usando determinati campi e metodi (modelli di certificato, OID, campo Utilizzo chiave migliorato, ecc.) è possibile specificare a cosa serve un determinato certificato, ma l'intero schema si basa sul client che si fida della radice della catena di certificati. / p>