Un certificato SSL wildcard è considerato un’opzione quando si cerca di proteggere più sottodomini all’interno dello stesso nome dominio. Questi certificati, usando un carattere wildcard (*) nel campo del nome dominio, proteggono numerosi sottodomini (host) collegati allo stesso dominio base.
Il nome comune per i certificati wildcard inizia sempre con un asterisco e un punto (*.).
*.(nomedominio).com
Ad esempio, un certificato wildcard standard emesso per *.dominio.com proteggerà www.dominio.com, mail.dominio.com, info.dominio.com, ecc. ma non proteggerà mail.test.com.
I nomi alternativi del soggetto (SAN) devono essere un dominio wildcard (ad esempio *.iltuodominio.com) o basati sui domini wildcard elencati. Ad esempio, se uno dei domini con carattere jolly è *.example.com, puoi utilizzare www.example.com o www.app.example.com, ma non mail.secure.com. Un’eccezione al certificato Secure Site Pro SSL che protegge entrambi i domini.
Per impostazione predefinita, si presume che il certificato richiesto sia installato in tutti i domini corrispondenti. Tuttavia, per ogni server web supportato da DigiCert, esistono alcune regole che richiedono l’installazione del certificato solamente sui domini qualificati.
Quando arriva la richiesta automazione, il server trova i blocchi server corrispondenti in base al CN o al SAN usato nella richiesta.
Nginx confronta il server_name con il CN o il SAN presente nella richiesta.
Se il server_name corrispondente viene trovato nel set di blocchi server, tutti i blocchi server che corrispondono saranno protetti.
Ad esempio:
server {
server_name 8010.abc-example.com *.abc-example.com;
listen 123.123.123.123:8010 ;
}
server {
server_name 8020.abc-example.com *.mail.abc-example.com ;
listen 123.123.123.123:8020 ;
}
server {
server_name 8030.abc-example.com *.abc-example.com ;
listen 123.123.123.123:8030 ;
}Nell’esempio sopra, quando richiedi l’automazione per:
Quando arriva la richiesta automazione, il server trova i blocchi <VirtualHost> corrispondenti in base al CN o al SAN usato nella richiesta.
Apache confronta il NomeServer e l’AliasServer con il CN o SAN presente nella richiesta.
Se il NomeServer o l’AliasServer viene trovato nel set di host virtuali, tutti i blocchi host che corrispondono saranno protetti.
Ad esempio:
Listen 551
<VirtualHost 125.125.125.125:551>
ServerName 551.abc-example.com
ServerAlias *.mail.abc-example.com
</VirtualHost>
Listen 552
<VirtualHost 125.125.125.125:552>
ServerName 552.abc-example.com
ServerAlias *.abc-example.com
</VirtualHost>
Listen 553
<VirtualHost 125.125.125.125:553>
ServerName 553.abc-example.com
ServerAlias *.abc-example.com securemail.abc-example.com
</VirtualHost>Nell’esempio sopra, quando richiedi l’automazione per:
Il server IIS non cerca il CN o SAN corrispondente usato nella richiesta automazione. Il certificato sarà installato solo nell’indirizzo IP e nella porta richiesti.
Ad esempio:
IP/Port: 123.123.123.123: 401
Common name: *.example.com
IP/Port: 125.125.125.125: 402
Common name: *.abc.example.com
SANs: *.mail.example.com
IP/Port: 127.127.127.127: 403
Common name: *secure.example.com
SANs: *.example.comNell’esempio sopra, quando richiedi l’automazione per:
Quando arriva la richiesta automazione, il server trova i blocchi <Connettore> corrispondenti in base al CN e/o al SAN usato nella richiesta.
Tomcat confronta il SSLHostConfig hostName con il CN e/o il SAN presenti nella richiesta.
Se il SSLHostConfig Hostname corrispondente viene trovato nel set di blocchi connettori, tutti i blocchi server che corrispondono saranno protetti.
Ad esempio:
<Connector port="182" SSLEnabled="false" defaultSSLHostConfigName="*.abc.example.com" connectionTimeout="20000">
<SSLHostConfig hostName="*.abc.example.com"> </SSLHostConfig>
</Connector>
<Connector port="183" SSLEnabled="false" defaultSSLHostConfigName="*.example.com" connectionTimeout="20000">
<SSLHostConfig hostName="*.example.com"> </SSLHostConfig>
<SSLHostConfig hostName="*.mail.example.com"> </SSLHostConfig>
<SSLHostConfig hostName="abc.example.com"> </SSLHostConfig>
<SSLHostConfig hostName="*.blog.example.com"> </SSLHostConfig>
</Connector>
<Connector port="184" SSLEnabled="false" defaultSSLHostConfigName="*.secure.example.com" connectionTimeout="20000">
<SSLHostConfig hostName="*.secure.example.com"> </SSLHostConfig>
<SSLHostConfig hostName="*.blog.example.com"> </SSLHostConfig>
<SSLHostConfig hostName="abc.example.com"> </SSLHostConfig>
<SSLHostConfig hostName="*.login.example.com"> </SSLHostConfig>
</Connector>Nell’esempio sopra, quando richiedi l’automazione per:
Per un’automazione corretta, tutti i blocchi SSLHostConfig all’interno del connettore devono avere un certificato installato.
Ad esempio, per automatizzare correttamente e installare i certificati su tutti i blocchi SSLHostConfig, devi eseguire la richiesta automazione con:
CN=*.esempio.com e SAN=*.mail.test.com
<Connector port="123" SSLEnabled="false" defaultSSLHostConfigName="*.example.com" connectionTimeout="20000">
<SSLHostConfig hostName="*.example.com"> </SSLHostConfig>
<SSLHostConfig hostName="*.mail.test.com"> </SSLHostConfig>
<SSLHostConfig hostName="abc.example.com"> </SSLHostConfig>
<SSLHostConfig hostName="*.blog.example.com"> </SSLHostConfig>
</Connector>Quando arriva la richiesta automazione, il server trova i blocchi <VirtualHost> corrispondenti in base al CN o al SAN usato nella richiesta.
Il server IBM confronta il NomeServer e l’AliasServer con il CN o SAN presente nella richiesta.
Se il NomeServer o l’AliasServer viene trovato nel set di host virtuali, tutti i blocchi host che corrispondono saranno protetti.
Ad esempio:
Listen 125.125.125.125:551
<VirtualHost 125.125.125.125:551>
ServerName 551.abc-example.com
ServerAlias *.mail.abc-example.com
</VirtualHost>
Listen 125.125.125.125:552
<VirtualHost 125.125.125.125:552>
ServerName 552.abc-example.com
ServerAlias *.abc-example.com
</VirtualHost>
Listen 125.125.125.125:553
<VirtualHost 125.125.125.125:553>
ServerName 553.abc-example.com
ServerAlias *.abc-example.com securemail.abc-example.com
</VirtualHost>Nell’esempio sopra, quando richiedi l’automazione per: