Controllo della catena di certificati

Il server fornirà il proprio certificato e facoltativamente (ma consigliato) tutti i certificati CA intermedi nella catena (ovvero il pacchetto CA ). Non è necessario fornire il certificato CA radice della catena e il client deve ignorare tale certificato se fornito nel bundle in ogni caso, vedere questa domanda per maggiori dettagli su questo. Dal momento che il bundle completo è abbastanza probabilmente non necessario, in futuro il client sarà in grado dichiararlo ha una copia memorizzata nella cache di per ridurre l'impostazione della connessione.

Il punto di convalida è che il client dovrebbe essere in grado di verificare l'intera catena fino a una radice attendibile, quindi deve avere già una copia della radice e deve avere o ottenere tutti i prodotti intermedi.

Se al client mancano certificati CA intermedi, può fidarsi di quelli forniti dal server finché sono verificabili, quindi può riempire eventuali pezzi mancanti utilizzando le copie locali dei certificati CA. Questo è il metodo utilizzato per gli aggiornamenti dei certificati CA intermedi, in modo che i client possano eseguire facilmente l'aggiornamento (non esiste un sistema di recupero o pubblicazione di certificati X.509 ampiamente diffuso analogo ai server delle chiavi PGP). Ci possono essere zero, uno o più certificati intermedi in una catena.

Ogni certificato ha solo i dettagli identificativi del suo emittente / genitore immediato (cioè non dell'intera catena) - questo è registrato nel campo Emittente DN e più utile nel campo AKID ( AKID / SKID PDF). Il nome Emittente leggibile non può identificare univocamente un certificato specifico (non registra il numero di serie specifico). Il SKID (identificatore chiave soggetto) è effettivamente un'identificazione personale di un certificato e il AKID (identificatore chiave di autorizzazione) è l'identificazione personale del suo emittente, funziona come un elenco collegato singolarmente dal end cert (idealmente) fino a una radice attendibile (anche se i certificati più vecchi spesso non hanno questi campi, quindi vengono utilizzati i DN).

• Iniziando con la catena fornita dal server (se presente) il client dovrebbe funzionare in fondo all'elenco, potrebbe aggiungere certificati intermedi che mancano al suo archivio, se sono validi.
• Quindi, il client deve risalire dal certificato dei server, in genere utilizzando il campo AKID per individuare il certificato emittente (padre) specifico, verificare e lavorare fino a quando non raggiunge una radice autofirmata attendibile.

I termini associati a questo processo sono Creazione percorso di certificazione e Convalida del percorso di certificazione . Non esiste un singolo "modo giusto" per farlo. Un client robusto controllerà da capo a capo, i browser in genere offrono un bypass (con avvertenze con parole severe) e su alcuni sistemi è possibile limitare la profondità dal certificato finale per verificare come ottimizzazione.

(Il controllo di validità include firma / hash, intervallo di date, CRL, OCSP, pinning ecc. e possibilmente DANE .)

Si sovrappone a entrambe le opzioni, oltre all'aggiornamento automatico dei certificati CA intermedi.

La catena di attendibilità viene verificata avviando il certificato del server e verificando le firme finché non viene trovata una radice attendibile. Pertanto, la firma del certificato del sito viene verificata rispetto al certificato pubblico della CA intermedia. La CA intermedia tuttavia non è attendibile, pertanto la firma del certificato pubblico della CA intermediaria viene convalidata rispetto al certificato pubblico della CA principale. Poiché la firma è valida (e non ci sono voci dell'elenco di revoche che dicono che non dovrebbe essere più valida), la CA intermedia (e quindi il certificato del server) eredita la fiducia dal certificato radice attendibile.

Il processo può continuare per il numero di generazioni della gerarchia necessario fino a quando viene raggiunto un certificato attendibile. Se il certificato del server è stato aggiunto manualmente al repository di certificati attendibili sul computer locale, ad esempio, la firma della CA intermedia non sarebbe mai stata verificata poiché non è necessario ottenere la fiducia.

Normalmente, il server non invia tutte le catene di certificati per impostazione predefinita. Dipende da come il server è configurato e se tutte le sue catene di certificati sono incluse nel keystore del server web.

Per ottenere questo risultato nella configurazione del client Openssl Server, è necessario concatenare tutti i suoi intermediari con il proprio certificato. I certificati dovrebbero essere nell'ordine del proprio certificato all'inizio e nel certificato intermedio che ha firmato questo nel successivo e così via (Si può ignorare la concatenazione di CA radice dal momento che esiste sul client). E utilizzare lo stesso elenco di catene di certificati con SSL_CTX_use_certificate_chain_file sul lato server. Ora sul client, è sufficiente disporre di un certificato CA root per verificare questa catena di certificati.

C'è un altro approccio che è inverso a questo. Il server invia semplicemente il proprio certificato (che è firmato da Intermediate cert e Intermediate by Root CA) nell'handshake SSL. In questo caso, il cliente deve disporre di certificati CA intermedi e root per verificare l'intera catena. Il client concatena CA intermedio e principale nell'ordine di CA principale all'inizio seguito da un certificato intermedio e così via. (Si può ignorare il concatenamento del certificato del server in questo elenco). Il client può utilizzare l'API SSL_CTX_use_certificate_file e includere questo file concatenato per verificare il certificato del server.