Supponiamo di avere questi URL:
Voglio che il primo sia servito con un certificato SSL commerciale validato dal dominio e il secondo con un certificato SSL di convalida esteso. È tecnicamente possibile? È supportato dagli standard e dai browser SSL / TLS (e HTTPS?)?
Non sto chiedendo in alcun modo se questa è anche una buona configurazione (vorrei andare per l'EV per tutto il dominio), ho solo bisogno di sapere se tale configurazione è supportata. Apprezzerei molto i riferimenti agli standard.
Sì e No.
È possibile avere più certificati che hanno tutti lo stesso nome di dominio. Potresti avere un certificato di esempio.org di Comodo e un certificato di esempio di Entrust.org, entrambi validi e ufficiali, nessun problema. Credo che alcuni strumenti di bilanciamento del carico ruoteranno quale viene utilizzato su base per connessione, ma solo in modalità round robin.
Il No sta chiedendo se è possibile selezionare quale certificato utilizzare in base all'URI (/ vs. / criticalpath). Il problema è che l'URI è disponibile solo dopo che la connessione SSL è stata inchiodata usando uno dei due certificati. Quindi non puoi davvero scegliere quale certificato usare in base alle informazioni che puoi avere solo dopo aver scelto il certificato.
Ora, non ho intenzione di dire che il 100% è impossibile. Con Apache, ad esempio, puoi impostare la configurazione SSLCipherSuite su una base per directory quindi non sarei sorpreso se ci fosse un qualche modo per forzare una rinegoziazione che implicherebbe un nuovo certificato. Ma sospetto piuttosto che sia praticamente non implementato anche se è teoricamente possibile. (Apache SSLCertificate * è per server o per-vhost, non per directory).
Appendice : modifiche alla rinegoziazione
Dichiarazione di non responsabilità: non ho fatto nulla di tutto ciò, è un'interpretazione da parte di un laico delle RFC e di altri documenti. Dozzine di persone qui sono molto più qualificate per commentare di me.
Vederò TLS 1.2 poiché è descritto in modo preciso all'interno di RFC 5246 .
Sezione 7.4.1.1, "Il messaggio HelloRequest può essere inviato dal server in qualsiasi momento." Questo dovrebbe indurre il Cliente a rinegoziare la connessione. (Il cliente MAGGIO ignorare quella richiesta, e il server può abbandonare la connessione se il client ignora la richiesta troppo a lungo.)
Una rinegoziazione assomiglia molto a una negoziazione iniziale, sebbene possa passare alcune informazioni dalla precedente negoziazione in avanti per cercare di appianare il percorso (ad esempio, ecco la cifra concordata l'ultima volta ). Quindi il client invia un ClientHello , quindi il server invia un ServerHello , quindi il server invia un certificato server ( 7.4.2).
Quindi la mia lettura della RFC è che, sì, un server può forzare la rinegoziazione di una connessione, inclusa la selezione di un diverso certificato server.
Sarò onesto con te, non so che troverai software esistenti che faranno ciò che vuoi fare. Ti suggerisco di iniziare a giocare con Perl Crypto :: OpenSSL o Python's ssl lib per vedere se puoi provarlo.
No. Nessun server Web può supportare questa funzionalità; non ora, non mai. Ecco perché:
HTTPS segue questi passaggi in questo ordine:
Si noti che il passaggio 2 sopra avviene prima del passaggio 3. Cioè, l'intera cosa della crittografia è completamente finita prima che il browser comunichi al server quale URL sta cercando. Ciò significa che quando il server seleziona un certificato SSL da utilizzare, non sa ancora quale sarà il percorso dell'URL. Poiché queste informazioni non sono disponibili in quella fase, non possono prendere in considerazione la decisione del certificato da utilizzare.
Si noti inoltre che il nome host viene inviato al server nel passaggio 3, motivo per cui ogni certificato viene generalmente installato su indirizzi IP univoci; il server utilizza l'indirizzo IP per determinare quale certificato presentare. Versioni più recenti dell'estensione aggiunta SSL / TLS chiamata Identificazione nome server per consentire al client di specificare il nome host durante la negoziazione TLS, ma questo funziona solo per gli hostname.
Non è prevista la possibilità di consentire la selezione del certificato in base al percorso dell'URL, né lo sarà mai, poiché ciò implicherebbe che il percorso dell'URL debba essere inviato al server non crittografato come parte della selezione del certificato. E l'invio dell'URL non crittografato sarebbe inaccettabile per una pagina sicura.
Sto pensando che potrebbe essere possibile usando offloading SSL, deep packet inspection e rinegoziazione TLS. Tuttavia, se esegui la rinegoziazione di Google TLS, i primi 20 hit riguarderanno le vulnerabilità di rinegoziazione, quindi se lo fai, potresti finire per rendere il tuo sito meno sicuro, non di più.
D'altra parte, se il tuo schema fosse così:
sarebbe piuttosto banale. Dovresti semplicemente indirizzare questi due domini a diversi IP interni e associare gli IP a diversi certificati.
Leggi altre domande sui tag domain tls certificates