Un certificato SSL jolly deve proteggere sia il dominio principale che i sottodomini?


81

Faccio questa domanda, perché Comodo mi sta dicendo che un certificato jolly per * .example.com proteggerà anche il dominio root example.com. Quindi, con un singolo certificato, sia my.example.com che example.com sono protetti senza preavviso da un browser.

Tuttavia, questo non è il caso del certificato che mi è stato fornito. I miei sottodomini sono protetti bene e non danno un errore, ma il dominio principale genera un errore nel browser, dicendo che l'identificazione non può essere verificata.

Quando confronto questo certificato con altri scenari simili, vedo che negli scenari che funzionano senza errori, il Nome alternativo soggetto (SAN) elenca sia * .example.com che example.com, mentre il certificato recente di Comodo elenca solo *. esempio.com come nome comune e NON esempio.com come nome alternativo soggetto.

Qualcuno può confermare / chiarire che il dominio principale deve essere elencato nei dettagli SAN se deve essere protetto in modo corretto?

Quando leggo questo: http://www.digicert.com/subject-alternative-name.htm Sembra che la SAN debba elencare entrambi per funzionare come ho bisogno. Qual è la tua esperienza?

Grazie mille.

Risposte:


72

C'è qualche incoerenza tra le implementazioni SSL su come corrispondono ai caratteri jolly, tuttavia è necessario il root come nome alternativo affinché funzioni con la maggior parte dei client.

Per un *.example.comcertificato,

  • a.example.com dovrebbe passare
  • www.example.com dovrebbe passare
  • example.com non dovrebbe passare
  • a.b.example.com può passare a seconda dell'implementazione (ma probabilmente no).

In sostanza, gli standard dicono che *dovrebbero corrispondere a 1 o più caratteri non punti, ma alcune implementazioni consentono un punto.

La risposta canonica dovrebbe essere in RFC 2818 (HTTP Over TLS) :

La corrispondenza viene eseguita utilizzando le regole di corrispondenza specificate da [RFC2459]. Se nel certificato è presente più di un'identità di un determinato tipo (ad esempio, più di un nome dNSName, una corrispondenza in uno dei set è considerata accettabile.) I nomi possono contenere il carattere jolly * che si considera corrisponda a un singolo componente del nome di dominio o frammento del componente. Ad esempio, *.a.comcorrisponde a foo.a.com ma non a bar.foo.a.com. f*.comcorrisponde a foo.com ma non a bar.com.

RFC 2459 afferma:

  • È possibile utilizzare un carattere jolly "*" come componente del nome più a sinistra nel certificato. Ad esempio, *.example.comcorrisponderebbe a.example.com, foo.example.com, ecc. Ma non corrisponderebbe a example.com.

Se hai bisogno di un certificato per funzionare per example.com, www.example.com e foo.example.com, hai bisogno di un certificato con subjectAltNames in modo da avere "example.com" e "* .example.com" (o esempio .com e tutti gli altri nomi che potresti aver bisogno di abbinare).


13

Hai ragione, il dominio principale deve essere un nome alternativo per essere convalidato.


6

Ogni provider SSL che abbia mai usato aggiungerà automaticamente il dominio radice come nome alternativo soggetto a un certificato SSL jolly, quindi DOMAIN.COM funzionerà automaticamente per un certificato jolly * .DOMAIN.COM.


8
Questo non è vero per AWS Certificate Manager dal 20/09/2017.
pho3nixf1re,

Non esiste un "dominio" per un certificato SAN in grado di proteggere più domini radice.
Jez,

-3

I certificati jolly sono generati idealmente per * .example.com Per proteggere sottodomini e domini con questo certificato, è sufficiente installare lo stesso certificato sui server che puntano a questi domini.

Ad esempio, si dispone di un certificato jolly per * .example.com one.example.com - server 1 esempio.com - server 2

è necessario installare questo certificato sul server 1 e sul server 2.

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.