Abbiamo avuto un server Web con certificati SSL errati ma il browser è riuscito a trovare un altro percorso attendibile a una radice e a fornire correttamente la pagina su HTTPS. Disponiamo inoltre di client software proprietari che utilizzano SSL al di fuori dei browser che si connettono allo stesso server ma non hanno convalidato la convalida SSL. La mia domanda è qual è il meccanismo nella logica del browser che gli consente di trovare percorsi alternativi a una radice attendibile?
In SSL / TLS il server dovrebbe mostrare il suo certificato come parte di una catena. In teoria, il server dovrebbe assicurarsi che la catena inviata sia corretta e il client è "moralmente autorizzato" a rifiutare la connessione se la catena esatta inviata dal server non riesce a convalidare. Tuttavia, i clienti sono consentiti a compiere ulteriori sforzi; se possono convalidare il certificato con un'altra catena, allora è OK continuare.
Pertanto, non è possibile incolpare formalmente alcuni client per non aver convalidato il certificato del server se il server invia una catena imperfetta.
Quando un client tenta di creare una catena alternativa, utilizzerà alcuni o tutti i seguenti metodi:
Questo ultimo metodo è ciò che di solito funziona. Un certificato ben rilasciato conterrà un'estensione AIA con un URL che punta al certificato per la CA che lo ha rilasciato. Questo certificato può contenere un'estensione AIA che punta alla CA di livello superiore e così via, fino alla radice. Fintanto che tutti gli URL sono accessibili pubblicamente, la rete è attiva e in esecuzione, e nessun amministratore di sistema è entrato nella sua patetica scusa perché una mente possa bloccare quel meccanismo (l'ho visto sfortunatamente), quindi la catena sarà ricostruita con successo. I moderni sistemi Windows lo fanno automaticamente.
Ma ricorda che i client SSL permessi non si comportano in questo modo. Un punto importante da notare è che il seguente URL si basa su HTTP. Un browser Web conosce HTTP; questa è una caratteristica fondamentale di un browser. Tuttavia, un'applicazione stand-alone che utilizza una libreria SSL potrebbe non essere in grado di emettere una richiesta HTTP casuale, o anche semplicemente disposti a farlo. Alcune librerie SSL forniscono il supporto del protocollo ma si basano sul chiamante per fornire effettivamente la connettività di rete (il chiamante apre e gestisce la connessione TCP, la libreria è puramente sul lato computazionale delle cose). A seconda di come è progettata l'applicazione e della sua implementazione SSL, potresti o non riuscire a spingere i certificati aggiuntivi laddove necessario.
È molto meglio se il server è installato correttamente in primo luogo.
Il browser di solito memorizza nella cache i certificati intermedi che hanno visto una volta. Questo può essere testato se si utilizza Firefox contro un server che manca un comune certificato intermedio. Se il browser ha già visto questo certificato mancante, consentirà la connessione. Tuttavia, se si utilizza un nuovo profilo firefox e si riprova, si verificherà un errore, poiché la memorizzazione nella cache del certificato viene eseguita per profilo.
Secondo me questo è un cattivo comportamento perché causa un comportamento inaffidabile del browser. È molto comune per gli amministratori non rendersi conto che la configurazione HTTPS non funziona quando i test con il loro browser non si lamentano perché hanno il certificato intermedio mancante nella cache.
Leggi altre domande sui tag web-browser tls certificates