Verifica del client con PKCS # 7

Un certificato è una cosa che dovrebbe essere validata , un processo convoluto mediante il quale il certificato viene inserito alla fine di una catena di certificati , che inizia con CA principale, passa da CA a CA secondaria e termina con il certificato a cui sei interessato (spesso chiamato "end-entity"). La firma su ciascun certificato deve essere verificata con la chiave pubblica del certificato precedente nella catena.

La CA radice che hai già (questo è il punto della CA radice: questo è ciò che inizi con). Per una corretta convalida, è necessario ottenere tutti gli altri certificati, per costruire una catena. In alcuni protocolli, è prevista l'invio di certificati CA non radice insieme all'entità finale (ad esempio, un server SSL / TLS non invia solo il proprio certificato al client, ma una catena completa). Se il protocollo in uso non fornisce tale funzionalità, il sistema che deve convalidare il certificato dovrà ottenere in altro modo la CA non root. A volte questi possono essere scaricati, seguendo l'URL trovato nei certificati stessi (estensione Accesso alle informazioni dell'autorità ), ma ciò richiede che i certificati siano stati effettivamente posizionati su server accessibili in remoto con l'URL corretto in posizione.

Tuttavia, in generale, è considerato educato inviare una CA non root ogni volta che si trasmette il certificato stesso. Questo può solo rendere le operazioni più agevoli.

Il formato PKCS # 7 (ora chiamato CMS ) è un formato generico per file crittografati e / o firmati. Succede che quando usa l'opzione "firmata", include un campo di intestazione facoltativo per memorizzare "certificati extra" che possono essere utili a chiunque cerchi di verificare le firme. Quindi, è diventato tradizionale ab (a) utilizzare questo formato in un "sacco di certificati": questo è un file CMS, firmato, senza contenuto e senza firma, ma con il campo "extra certificate" contenente i certificati (senza ordine) . Questo è spesso chiamato "certificato PKCS # 7" e ai sistemi Windows piace chiamarlo "file .P7B".

Quello che dovrebbe essere nel tuo negozio di fiducia è la CA radice e nient'altro, per definizione. La CA non root viene inviata a te in modo che la tua macchina possa trovare facile costruire la catena. Una caratteristica molto bella dei certificati è che sono firmati : quindi, il modo in cui li ottieni è irrilevante per la sicurezza; ciò che importa è se la firma coincide.

Quello che deve essere nel tuo truststore è un certificato di cui ti fidi per questa specifica comunicazione . Potresti voler utilizzare anche una o più connessioni CRL o OCSP.

In sostanza si sta tentando di creare una catena di certificati per un certificato attendibile, mentre si convalidano tutti i certificati nella catena. Quindi questi certificati dovrebbero avere date corrette, non dovrebbero essere revocati e dovrebbero ovviamente verificare con il certificato dell'emittente.

La convalida con una CA ben nota è ottima, ma si tenga presente che non si desidera verificare l'invio di un messaggio da parte di una qualsiasi parte che dispone di un certificato da parte di una CA ben nota. Chiunque può ottenerne uno.

Quindi potresti voler controllare esplicitamente il campo dell'oggetto, utilizzare il blocco del certificato o qualcosa di diverso per la verifica della firma.

Quanti certificati vengono consegnati all'interno del CMS PKCS # 7 possono variare. Sono solo usati per creare una catena per un certificato di fiducia.

Quindi nel tuo caso potresti voler stabilire un trust per il certificato CA a cui è stata assegnata l'attività per proteggere questo particolare messaggio (che presumo sia firmato). Si tratta di un'azione fuori banda (ad esempio, potrebbe essere necessario prendere il telefono per verificare l'impronta digitale del certificato). Se non esiste una CA specifica per questa attività, è possibile inserire il certificato foglia nel trust store.