Nome comune SSL jolly - può essere chiamato in modo diverso?


34

Mi chiedevo solo se un certificato SSL con caratteri jolly deve necessariamente avere un nome comune che contenga il nome di dominio dei siti ai quali è necessario applicare il certificato SSL.

Ad esempio, per quanto segue:

Nome dominio: testdomain.com

Siti secondari:

  • www.testdomain.com
  • mobile.testdomain.com
  • mytestenvironment.testdomain.com

Devo necessariamente che il mio certificato jolly abbia un nome comune di *.testdomain.com?


serverfault.com potrebbe essere un posto migliore per questa domanda.

Risposte:


38

Sì, il tuo nome comune dovrebbe essere * .yourdomain.com per un certificato jolly.

Fondamentalmente, il nome comune è ciò che indica per quale dominio è buono il tuo certificato, quindi deve specificare il dominio effettivo.

Chiarimento: non dovrebbe "contenere" il nome di dominio dei siti, dovrebbe essere il dominio dei siti. Immagino che non ci siano differenze nella tua domanda, volevo solo chiarire, nel caso in cui ci sia un malinteso su quale dovrebbe essere il dominio o su quale verrà utilizzato il certificato.


4

In realtà, è necessario utilizzare le dnsNamevoci nella subjectAltNamesezione del certificato per specificare gli FQDN, non la parte CN del subject. L'uso di subjecta questo scopo è stato deprecato poiché la RFC 2818 è stata pubblicata nel 2000. Citando la sezione 3.1 :

Se è presente un'estensione subjectAltName di tipo dNSName, DEVE essere utilizzata come identità. In caso contrario, DEVE essere utilizzato il campo (più specifico) Nome comune nel campo Oggetto del certificato. Sebbene l'uso del nome comune sia una pratica esistente, è deprecato e le autorità di certificazione sono incoraggiate a utilizzare invece il nomeNNS.

L'unico caso in cui i contenuti del subjectsono rilevanti nel contesto della convalida del certificato del server è se non è dnsNameincluso nel subjectAltName, un caso che è stato deprecato negli ultimi 17 anni al momento della scrittura.

L'uso dei certificati jolly è deprecato, come mostrato nella sezione 7.2 di RFC 6125 :

Questo documento afferma che il carattere jolly '*' NON DOVREBBE essere incluso negli identificativi presentati ma PUO 'essere verificato dai client dell'applicazione (principalmente per motivi di compatibilità con le versioni precedenti dell'infrastruttura distribuita).

L'uso della stessa chiave privata per diversi servizi è generalmente considerato una cattiva pratica. Se uno dei servizi dovesse essere compromesso, le comunicazioni da altri servizi saranno a rischio e dovrai sostituire la chiave (e il certificato) per tutti i servizi.

Suggerisco RFC 6125 come una buona fonte di informazioni al riguardo.


"E così sono i certificati jolly": potresti per favore elaborare? dnsNamepuò contenere un dominio jolly. Inoltre, cosa dovrebbe esserci subjectin quel caso?
WoJ,

Dai un'occhiata alle sezioni 1.5 e 7.2 di RFC 6125 . Fintanto che ne subjectAltNamecontiene almeno uno dnsName, i contenuti di subjectsono irrilevanti nel contesto della verifica del certificato.
Erwan Legrand,

@WoJ Ho modificato la mia risposta. Spero che ora sia tutto più chiaro.
Erwan Legrand,

3

Sì, il certificato SSL Wildcard è la migliore soluzione in base alle tue esigenze. Con il certificato Wildcard sarai in grado di proteggere le informazioni del tuo visitatore. Non importa quale sia la pagina del tuo sito web inviata. Il certificato jolly protegge un numero illimitato di sottodomini che condividono lo stesso nome di dominio.

L'installazione dello stesso certificato jolly su tutti i sottodomini e i server trasmette il rischio integrato: se un server o un sottodominio è compromesso, tutti i sottodomini possono essere ugualmente compromessi. Assicurati che il tuo sito Web sia protetto con più livelli di protezione da qualsiasi pressione esterna e interna.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.