Tecnicamente, l'utilizzo di caratteri jolly è definito in RFC 2818 , che fa consente nomi come " *.*.example.com " o " foo.*.bar.*.example.com " o anche " *.*.* ". Tuttavia, tra teoria e pratica, possono esserci, diciamo, differenze pratiche (teoria e pratica coincidono perfettamente solo in teoria, non in pratica). I browser Web hanno implementato regole più rigide, perché:
- L'implementazione della corrispondenza con caratteri jolly multilivello richiede ben cinque minuti in più rispetto all'implementazione della corrispondenza dei nomi con un singolo carattere jolly.
- I fornitori di browser non si fidavano della CA esistente per mai che emettevano un certificato "
*.*.com ".
- Gli sviluppatori sono esseri umani, quindi molto bravi a non vedere ciò che non possono immaginare, quindi i nomi multi-carattere non sono stati implementati da persone che non si rendevano conto che erano possibili.
Quindi i browser Web applicheranno restrizioni, che RFC 6125 cercano almeno di documentare. La maggior parte delle RFC è pragmatica: se la realtà non corrisponde alle specifiche, modifica le specifiche, non la realtà. Nota che i browser applicheranno anche regole extra, come proibire " *.co.uk " (non tutti i browser usano le stesse regole, anche se non sono documentati).
Anche le CA professionali entrano nella danza con i propri vincoli, come i test di verifica dell'identità prima di emettere certificati, o semplicemente riluttanza a emettere certificati jolly troppo ampi: il core business di una CA professionale è vendere molti certificati e certificati con caratteri jolly non sono d'aiuto. Al contrario, in effetti. Le persone vogliono acquistare certificati jolly proprio per evitare l'acquisto di molti singoli certificati.
Un'altra teoria che non è riuscita a metterla in pratica è Name Constraints . Con questa estensione X.509, è possibile che una CA rilasci un certificato per una CA secondaria, limitando tale CA secondaria in modo che possa emettere certificati server solo in una determinata struttura di dominio. Un'estensione Name Constraints con una "sottostruttura esplicita" di valore " .example.com " consentirebbe www.example.com e foo.bar.example.com . In quel modello, il proprietario del dominio example.com eseguiva la propria CA, limitata dalla sua über-CA ai soli nomi nella sottostruttura example.com . Sarebbe bello e dandy.
Sfortunatamente, qualsiasi cosa tu faccia con i certificati X.509 è completamente inutile se le implementazioni implementate (cioè i browser Web) non la supportano ei browser esistenti non supportano i vincoli di nome. Non lo fanno, perché non esiste un certificato con i vincoli dei nomi da elaborare (quindi sarebbe un codice inutile), e non esiste un tale certificato perché i browser Web non sarebbero in grado di elaborarli comunque. Per eseguire il boot delle cose, qualcuno deve avviare il ciclo, ma i produttori di browser attendono dopo la CA professionale e le CA professionali non sono disposte a supportare i vincoli dei nomi, per gli stessi motivi precedenti (che si riducono a alla lunga).