it-swarm-eu.dev

Quali certificati sono necessari per i sottodomini multilivello?

Sto lavorando su un sito web con diversi livelli di sottodomini. Devo proteggerli tutti con SSL e sto cercando di determinare la corretta strategia di certificazione.

Ecco cosa devo proteggere:

  • foo.com
  • www.foo.com
  • Qualsiasi combinazione di city.state.foo.com. (Questi sono stati degli Stati Uniti.)

La mia comprensione è che un certificato con caratteri jolly può coprire solo un "livello" di sottodominio. Secondo RFC 2818 :

I nomi possono contenere il carattere jolly * che si ritiene corrisponda a qualsiasi singolo componente del nome di dominio o frammento di componente. Ad esempio, * .a.com corrisponde a foo.a.com ma non a bar.foo.a.com. f * .com corrisponde a foo.com ma non a bar.com.

Quello che penso di cui ho bisogno sono i seguenti certificati:

  • *.foo.com, che corrisponderà, ad esempio, a foo.com, www.foo.com. (Anche se non sono chiaro se *.a.com partite a.com da solo.)
  • *.ny.foo.com per abbinare new-york.ny.foo.com, buffalo.ny.foo.com, ecc. Avrò bisogno di 50 di questi certificati per soddisfare tutti gli stati, una volta che il nostro sito si espanderà per servirli tutti.

Le mie domande sono:

  • Questo schema è corretto? Nello scenario sopra, se un utente visita ca.foo.com, riceveranno il certificato per *.foo.com o per *.ca.foo.com?
  • Come posso garantire che gli utenti vedano tutti questi sottodomini come legittimamente posseduti da noi? Ad esempio, se un utente visita foo.com, poi mountain-view.ca.foo.com e quelli sono certificati diversi, riceveranno un avviso? C'è un modo per assicurare al proprio browser che questi certificati condividano lo stesso proprietario?
114
Nathan Long

Teoricamente:

  • a * corrisponde esattamente a un livello (quindi *.foo.com non corrisponde a foo.com)
  • ma puoi avere diversi * in un nome

Quindi, se tutte le implementazioni SSL seguono fedelmente RFC 2818 , hai solo bisogno di tre certificati, con nomi:

  • foo.com
  • *.foo.com
  • *.*.foo.com

e, se le implementazioni sono davvero brave a rispettare RFC 2818 e le complessità di X.509, potresti persino usare un certificato singolo che elenca i tre stringhe sopra nella sua estensione Nome Alt soggetto.

Ora, teoria e pratica corrispondono perfettamente ... in teoria. Potresti avere sorprese su ciò che effettivamente fanno i browser. Ti suggerisco di provarlo; alcuni certificati di esempio possono essere creati con lo strumento da riga di comando OpenSSL (vedere ad esempio questa pagina per alcune linee guida).

76
Tom Leek

RFC 6125 è abbastanza recente e non è implementato da tutti, ma cerca di chiarire alcuni di questi problemi. Raccoglie le specifiche di identità in RFC 2818 e RFC di altri protocolli. Suggerirei di aderire a RFC 6125 se puoi. Le sezioni pertinenti per i certificati con caratteri jolly sono 6.4. e 7.2 (che scoraggia, in effetti, l'uso dei certificati con caratteri jolly).

Non è chiaro dalla tua domanda se vuoi eseguire un singolo server web (o almeno essere in grado di eseguirlo tutto dietro un singolo indirizzo IP) o se sei in grado di avere un certificato per sito (e quindi un indirizzo IP per sito, poiché SNI non è molto ben supportato in generale).

È possibile disporre di un singolo certificato con più nomi alternativi soggetto (SAN). Il problema deriva dal caso con due etichette jolly, che potrebbero non essere chiaramente specificate (*.*.foo.com).

Se il doppio carattere jolly funziona, un certificato con queste 3 SAN voci DNS dovrebbe funzionare:

  • foo.com
  • *.foo.com
  • *.*.foo.com

Tuttavia, poiché potrebbe non funzionare (a seconda delle implementazioni del client, che probabilmente non sono sotto il tuo controllo) e poiché puoi elencare i 50 stati, potresti avere 52 SAN voci DNS:

  • foo.com
  • *.foo.com
  • *.ny.foo.com
  • ... (uno per ogni stato)

Come posso garantire che gli utenti vedano tutti questi sottodomini come legittimamente posseduti da noi? Ad esempio, se un utente visita foo.com, quindi mountain-view.ca.foo.com e questi sono certificati diversi, riceveranno un avviso? C'è un modo per assicurare al proprio browser che questi certificati condividano lo stesso proprietario?

Questa è una domanda delicata, poiché dipende da quanto gli utenti hanno familiarità con il processo di verifica del certificato. Potresti ottenere un certificato di convalida estesa (anche se penso che il certificato EV con caratteri jolly probabilmente non sia consentito), che darebbe una barra verde. Ciò darebbe un'etichetta di "proprietà" nella maggior parte dei browser. Dopodiché, le stesse interfacce del browser possono essere fonte di confusione (ad es. Quella di Firefox "gestita da (sconosciuto)" nella barra blu, che non aiuta in alcun modo). Alla fine, gli utenti possono andare a controllare il certificato per vedere a quali SAN è stato emesso il certificato. Tuttavia, dubito che molti lo faranno e capiranno cosa significa.

34
Bruno

http://www.digicert.com/welcome/wildcard-plus.htm dice

Inoltre, i certificati ssl di DigiCert WildCard sono unici nel consentire di proteggere QUALSIASI sottodominio del proprio dominio, inclusi più livelli di sottodomini con un certificato. Ad esempio, la WildCard per * .digicert.com com potrebbe includere server1.sub.mail.digicert.com come nome alternativo soggetto.

4
TechNikh

È possibile utilizzare un certificato jolly oppure utilizzare un certificato con nomi di dominio alternativi. Personalmente, utilizzo un certificato di StartSSL che mi consente di avere tutti i miei domini elencati su un singolo certificato. Ho qualcosa come 10 domini jolly e 15 altri ADN tutti sullo stesso certificato in modo da poter utilizzare SSL attraverso i siti che ho ospitato sul mio server.

1
AJ Henderson