Quali certificati sono necessari per i sottodomini multi-livello?

Question

Quali certificati sono necessari per i sottodomini multi-livello?

#1 da (76 voti)
#2 da (34 voti)
#3 da (4 voti)
#4 da (1 voti)

111

Sto lavorando su un sito web con diversi livelli di sottodomini. Ho bisogno di proteggerli tutti con SSL e sto cercando di determinare la corretta strategia dei certificati.

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 :

Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Ciò di cui io penso ho bisogno sono i seguenti certificati:

*.foo.com , che corrisponderà, ad esempio, foo.com , www.foo.com . (Sebbene non sia chiaro se *.a.com corrisponda a a.com di per sé.)
*.ny.foo.com per abbinare new-york.ny.foo.com , buffalo.ny.foo.com , ecc. Alla fine avrò bisogno di 50 certificati di questo tipo per corrispondere a tutti gli stati, una volta che il nostro sito si espande per servirli tutti.

Le mie domande sono:

Questo schema è corretto? Nello scenario precedente, se un utente visita ca.foo.com , otterrà il certificato per *.foo.com o per *.ca.foo.com ?
Come posso garantire che gli utenti vedano tutti questi sottodomini come legittimamente di nostra proprietà? 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 loro browser che questi certificati condividono lo stesso proprietario?

tls certificates

posta Nathan Long 10.01.2012 - 14:06

fonte

4 risposte

Leggi altre domande sui tag tls certificates

FTPS (FTP + S) offre una sicurezza migliore di SFTP sul lato server? Un segreto in un URL

score 76 · Answer 1

In teoria:

a * corrisponde esattamente a un livello (quindi *.foo.com fa 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 veramente adatte con RFC 2818 e le complessità di X.509, potresti anche usare un certificato singolo che elenca le tre stringhe sopra nella sua estensione di nome Oggetto Alt .

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

score 34 · Answer 2

L'RFC 6125 è piuttosto recente e non è implementato da tutti, ma cerca di chiarire alcuni di questi problemi. Raccoglie le specifiche dell'identità in RFC 2818 e RFC di altri protocolli. Suggerirei di aderire a RFC 6125 se possibile. Le sezioni pertinenti per i certificati con caratteri jolly sono 6.4.3 e 7.2 (che scoraggia l'utilizzo di certificati jolly, infatti).

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).

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

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

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 dato che puoi elencare i 50 stati, potresti avere 52 voci DNS SAN:

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

How can I ensure that users see all of these subdomains as legitimately owned by us? For example, if a user visits foo.com, then mountain-view.ca.foo.com, and those are different certificates, will they get a warning? Is there some way to assure their browser that these certificates share the same owner?

Questa è una domanda complicata, poiché dipende da quanto familiari sono gli utenti con il processo di verifica del certificato. È possibile ottenere un certificato di convalida estesa (anche se penso che il certificato EV wildcard non sia probabilmente consentito), il 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 esempio Firefox "che è gestito da (sconosciuto)" nella barra blu, che in realtà non aiuta in alcun modo). In definitiva, gli utenti potevano andare e verificare all'interno del certificato per vedere a quali SAN è stato rilasciato il certificato. Tuttavia, dubito che molti lo faranno e capiranno cosa significa.

score 4 · Answer 3

link dice

Even more, DigiCert WildCard ssl certificates are unique in allowing you to secure ANY subdomain of your domain, including multiple levels of subdomains with one certificate. For example, your WildCard for *.digicert.com com could include server1.sub.mail.digicert.com as a subject alternate name.

score 1 · Answer 4

È possibile utilizzare un certificato con caratteri jolly oppure è possibile utilizzare anche un certificato con nomi di dominio alternativi. Personalmente, utilizzo un certificato di StartSSL che mi permette di avere tutti i miei domini elencati su un singolo certificato. Ho qualcosa come 10 domini wildcard e 15 altri ADN tutti sullo stesso certificato, così posso usare SSL tra i siti che ho ospitato sul mio server.