it-swarm.dev

È tecnicamente possibile configurare due diversi certificati SSL per lo stesso dominio?

Supponiamo di avere questi URL:

  1. https://example.org/

  2. https://example.org/criticalpath

Voglio che il primo sia servito con un certificato SSL commerciale convalidato dal dominio e il secondo con un certificato SSL di convalida esteso. È tecnicamente possibile? È supportato da standard e browser SSL/TLS (e HTTPS?)?

Non sto chiedendo in alcun modo se questa è anche una buona configurazione (sceglierei l'EV per tutto il dominio), ho solo bisogno di sapere se tale configurazione è supportata. Gradirei davvero riferimenti agli standard.

24
Jaime Hablutzel

Sì e no.

È possibile avere più certificati con tutti lo stesso nome di dominio. Potresti avere un certificato comodo example.org e un certificato Entrust example.org, entrambi validi e ufficiali, nessun problema. Credo che alcuni bilanciatori del carico ruotino quale viene utilizzato in base alla connessione, ma solo in modo round robin.

No è che stai chiedendo se puoi selezionare quale certificato utilizzare in base all'URI (/ vs./percorso critico). Il problema è che l'URI è disponibile solo dopo aver inchiodato la connessione SSL utilizzando una delle due certificazioni. Quindi non puoi davvero scegliere quale certificato utilizzare in base alle informazioni che puoi avere solo dopo aver scelto il certificato.

Ora, non dirò al 100% che è impossibile. Con Apache, ad esempio, puoi impostare la configurazione SSLCipherSuite in base alla directory, quindi non sarei sorpreso se ci fosse alcuni modo per forzare un 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 : riflessioni su rinegoziazione

Disclaimer: non ho fatto nulla di tutto ciò, è un'interpretazione da laica delle RFC e di altri documenti. Decine di persone qui sono molto più qualificate per commentare di me.

Esaminerò TLS 1.2 poiché è ben descritto in RFC 5246 .

Sezione 7.4.1.1, "Il messaggio HelloRequest PUO 'essere inviato dal server in qualsiasi momento." Ciò dovrebbe indurre il client a rinegoziare la connessione. (Il client può ignorare quella richiesta e il server può interrompere la connessione se il client ignora la richiesta per troppo tempo.)

Una rinegoziazione assomiglia molto a una negoziazione iniziale, anche se può inoltrare alcune informazioni della negoziazione precedente per cercare di smussare il percorso (ad es. 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 del 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 certificato server diverso.

Sarò onesto con te, non so che troverai software esistente che farà quello che vuoi fare. Ti suggerirei di iniziare a giocare con Perl Crypto :: OpenSSL o la libreria ssl di Python per vedere se riesci a provarlo.

33
gowenfawr

No. Nessun web server può supportare questa funzione; non ora, mai. Ecco perché:

HTTPS segue questi passaggi in questo ordine:

  1. Il client si connette al server
  2. Negoziazione SSL/TLS (include lo scambio di certificati, la verifica dei certificati e l'impostazione della crittografia)
  3. Il client invia la richiesta (include nome host, percorso, cookie del server, ecc.)
  4. Il server invia una risposta (include intestazioni di risposta, contenuto, ecc.)

Si noti che il passaggio 2 sopra si verifica prima del passaggio 3. In altre parole, l'intera operazione di crittografia è completamente terminata prima che il browser indichi 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. Dato che queste informazioni non sono disponibili in quella fase, non possono prendere in considerazione la decisione su quale certificato utilizzare.

Si noti inoltre che il nome host viene inviato al server al passaggio 3, motivo per cui ogni certificato viene in genere installato su indirizzi IP univoci; il server utilizza l'indirizzo IP per determinare quale certificato presentare. Le versioni più recenti di SSL/TLS hanno aggiunto l'estensione denominata Server Name Identification per consentire al client di specificare il nome host durante la negoziazione TLS, ma questo funziona solo per i nomi host.

Non è prevista alcuna autorizzazione per la selezione del certificato basata sul percorso dell'URL, né lo sarà mai, poiché ciò implicherebbe che il percorso dell'URL deve essere inviato al server non crittografato come parte della selezione del certificato. E l'invio dell'URL non crittografato sarebbe inaccettabile per una pagina protetta.

8
tylerl

Sto pensando che potrebbe essere possibile utilizzando l'offload SSL, l'ispezione approfondita dei pacchetti e la rinegoziazione TLS. Tuttavia, se esegui la rinegoziazione di Google TLS, i 20 principali risultati 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ì:

https://example.org/

https://criticalpath.example.org/

sarebbe piuttosto banale. Dovresti semplicemente indirizzare questi due domini a IP interni diversi e associare gli IP a certificati diversi.

3
John Wu