X.509 Convalida del certificato con Java e Bouncycastle

Question

tramite bouncycastle wiki page Sono stato in grado di capire come creare un certificato radice X.509 e una richiesta di certificazione, ma non capisco come procedere il concetto e la programmazione dopo questo .

Consente che la parte A esegua una richiesta di certificato e ottenga il proprio certificato client dalla CA. In che modo una parte B può validare il certificato di A? Che tipo di certificato ha bisogno? Un certificato di base? Un certificato cliente "normale"?

E come funziona la convalida a livello di programmazione, se supponiamo che A abbia inviato correttamente il suo certificato in formato DER o PEM a B?

Qualsiasi aiuto è molto apprezzato.

migliori saluti, Rob

Answer 1

Ok, l'idea alla base di CA è la seguente:

• CA sono persone tutti si fidano. A tal fine, una selezione di Trusted CA è disponibile nel browser/client di posta elettronica/anche sul mio cellulare. Nel tuo caso, la tua chiave radice pubblica (certificato) dovrebbe essere nella tua applicazione.
• Gli utenti inviano richieste alla CA per un certificato in formato PEM con la chiave pubblica. Le CA ne fanno alcune (lascio questa forma ambigua deliberatamente) di verifica all'utente finale, ad esempio addebitandole denaro o in caso di certificati di verifica avanzata (verde), verifiche in background.
• Se la CA non ritiene che la richiesta dell'utente sia valida, la comunica in qualche modo.
• Se lo fanno, firmano la chiave pubblica e producono un certificato contenente queste informazioni. Qui è dove si elabora il cert-req e lo si trasforma in un certificato X.509.
• Altri utenti incontrano il nostro utente fittizio e vogliono sapere se possono fidarsi di loro. Quindi, danno un'occhiata al certificato e scoprono che è firmato digitalmente da qualcuno che hanno nella loro lista di fiducia. Quindi, il fatto che si fidino della CA radice e solo la CA radice possa firmare (tramite la propria chiave privata) la chiave pubblica di questo utente e la CA si fidi dell'utente, deduciamo che il nuovo utente può fidarsi di mr fittizio.

A livello di codice, si implementa questo leggendo il certificato X.509 e individuando chi deve essere la CA. Data l'impronta digitale di CA, lo trovi nel tuo database e verifica la firma. Se corrisponde, hai la tua catena di fiducia.

Questo funziona perché, come ho detto, solo la CA può creare la firma digitale ma chiunque può verificarla. È esattamente il contrario del concetto di crittografia. Quello che fai è "criptare con la chiave privata" i dati che desideri firmare e verificare che "decifrare con la chiave pubblica" sia uguale ai dati che hai.

Answer 2

Dal punto di vista di un programmatore, sono necessarie alcune cose per convalidare un certificato X.509.

1. Un insieme di "trust ancore" — i certificati di origine delle CA su cui si fa affidamento. Questi devono essere protetti da manomissioni, in modo che un utente malintenzionato non sostituisca un certificato CA con il proprio falso. Le chiavi pubbliche in questi certificati vengono utilizzate per verificare le firme digitali su altri certificati.
2. Una raccolta di certificati intermedi. L'applicazione potrebbe conservare una raccolta di questi, ma la maggior parte dei protocolli, come SSL e S/MIME, che utilizzano i certificati hanno un modo standard per fornire certificati aggiuntivi.La conservazione di questi non richiede alcuna cura particolare; la loro integrità è protetta dalla firma di una CA radice.
3. Informazioni di revoca. Anche se un certificato è stato emesso da una CA, potrebbe essere stato revocato prematuramente perché la chiave privata è stata divulgata o l'entità finale ha cambiato la propria identità. Ad esempio, una persona cambia lavoro e un certificato con il nome della vecchia società in esso contenuto viene revocato. È possibile utilizzare CRL o un servizio Web come OCSP per ottenere un aggiornamento sullo stato di un certificato.

Con questi ingressi disponibili, è possibile utilizzare built-in PKIX support per costruire e convalidare un percorso del certificato.

/* Givens. */ 
InputStream trustStoreInput = ... 
char[] password = ... 
List<X509Certificate> chain = ... 
Collection<X509CRL> crls = ... 

/* Construct a valid path. */ 
KeyStore anchors = KeyStore.getInstance(KeyStore.getDefaultType()); 
anchors.load(trustStoreInput, password); 
X509CertSelector target = new X509CertSelector(); 
target.setCertificate(chain.get(0)); 
PKIXBuilderParameters params = new PKIXBuilderParameters(anchors, target); 
CertStoreParameters intermediates = new CollectionCertStoreParameters(chain) 
params.addCertStore(CertStore.getInstance("Collection", intermediates)); 
CertStoreParameters revoked = new CollectionCertStoreParameters(crls); 
params.addCertStore(CertStore.getInstance("Collection", revoked)); 
CertPathBuilder builder = CertPathBuilder.getInstance("PKIX"); 
/* 
* If build() returns successfully, the certificate is valid. More details 
* about the valid path can be obtained through the PKIXBuilderResult. 
* If no valid path can be found, a CertPathBuilderException is thrown. 
*/ 
PKIXBuilderResult r = (PKIXBuilderResult) builder.build(params); 

Una cosa importante da notare è che se un percorso non può essere trovato, non si ottiene molte informazioni circa il motivo. Questo può essere frustrante, ma è così in base alla progettazione. In generale, ci sono molti percorsi potenziali. Se falliscono tutti per ragioni diverse, in che modo il costruttore di percorsi decidere cosa segnalare come motivo?