Nom commun (CN) pour certificat générique

Le certificat SSL générique est une option envisageable lorsque l’on cherche à sécuriser plusieurs sous-domaines d'un même domaine. Ces certificats, qui utilisent l’astérisque comme caractère générique (*) dans le champ du nom de domaine, permet la sécurisation de nombreux sous-domaines (hôtes) liés à un même domaine de base.

Le nom commun d’un certificat générique commence toujours par une astérisque suivie d'un point (*.).

*.(nomdedomaine).com

À titre d’exemple, un certificat générique standard émis pour *.domaine.com sécurisera à la fois www.domaine.com, mail.domaine.com, info.domaine.com, etc. En revanche il ne sécurisera pas mail.test.com.

Les autres noms d’objet (SAN) doivent être des domaines à caractère générique (par exemple, *.votredomaine.com) ou être basés sur vos domaines à caractère générique répertoriés. Par exemple, si l'un de vos domaines génériques est *.exemple.com, vous pouvez utiliser www.exemple.com ou www.app.exemple.com, mais pas mail.secure.com. Une exception au certificat Secure Site Pro SSL, qui sécurise les deux domaines.

Installation de certificat sur des serveurs Web à partir des CN.

Par défaut, il est présumé que le certificat demandé sera installé sur tous les domaines correspondants. Cependant, pour tous les serveurs Web pris en charge par DigiCert, certaines règles exigent que le certificat ne soit installé que sur les domaines qualifiés.

Nginx

Lorsque la requête d'automatisation arrive, le serveur trouve les blocs serveur correspondants à partir du CN ou du SAN utilisé dans la requête.

Nginx compare le server_name au CN ou au SAN présent dans la requête.

Si un server_name correspondant est trouvé parmi le jeu de blocs serveur, tous les blocs correspondants seront sécurisés.

Par exemple :

generic
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 ;
}

Dans l’exemple ci-dessus, lorsque vous envoyez une requête d'automatisation pour :

  1. CN=*.abc-exemple.com – Sécurise à la fois les blocs serveur 8010 et 8030.
  2. CN=*.mail.abc-exemple.com – Sécurise uniquement le bloc serveur 8020.
  3. CN={8010/8020/8030}.abc-exemple.com – Sécurise uniquement les blocs serveur respectifs.
  4. CN=*.abc-exemple.com et SAN=*.mail.abc-exemple.com – Sécurise tous les blocs serveur.

Apache

Lorsque la requête d'automatisation arrive, le serveur trouve les blocs <VirtualHost> correspondants selon le CN ou le SAN utilisé dans la requête.

Apache compare le ServerName et le ServerAlias au CN ou au SAN présent dans la requête.

Si le ServerName ou le ServerAlias correspondant est trouvé dans le jeu d'hôtes virtuels, tous les blocs d'hôtes virtuels correspondants seront sécurisés.

Par exemple :

generic
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>

Dans l’exemple ci-dessus, lorsque vous envoyez une requête d'automatisation pour :

  1. CN=*.abc-exemple.com – Sécurise à la fois les blocs d'hôtes virtuels correspondant aux ports 552 et 553.
  2. CN=*.mail.abc-exemple.com – Sécurise uniquement le bloc d'hôte virtuel correspondant au port 551.
  3. CN={551/552/553}.abc-exemple.com – Sécurise uniquement les blocs d'hôtes virtuels respectifs.
  4. CN=*.abc-exemple.com et SAN=*.mail.abc-exemple.com – Sécurise tous les blocs d'hôtes virtuels.

IIS

Le serveur ISS ne recherche pas le CN ou le SAN correspondant utilisé dans la requête d'automatisation. Le certificat sera installé uniquement sur l’adresse IP et le port indiqués dans la requête.

Par exemple :

generic
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.com

Dans l’exemple ci-dessus, lorsque vous envoyez une requête d'automatisation pour :

  1. IP/Port=123.123.123.123: 401, CN=*.exemple.com – Sécurise uniquement l'adresse IP et le port 123.123.123.123: 401.
  2. IP/Port=125.125.125.125: 402, CN=*.exemple.com, SAN=*.mail.exemple.com – Sécurise uniquement l'adresse IP et le port 125.125.125.125: 402.
  3. IP/Port=127.127.127.127: 403, CN=*secure.exemple.com, SAN=*.exemple.com – Sécurise uniquement l’adresse IP et le port 127.127.127.127: 403.

Tomcat

Lorsque la requête d'automatisation arrive, le serveur cherche les blocs <Connector> correspondants selon le CN et/ou le SAN utilisé dans la requête.

Tomcat compare la variable SSLHostConfig hostName au CN et/ou au SAN présent dans la requête.

Si un SSLHostConfig Hostname est trouvé dans le jeu de blocs de connecteurs, alors tous les blocs correspondants seront sécurisés.

Par exemple :

generic
<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>

Dans l’exemple ci-dessus, lorsque vous envoyez une requête d'automatisation pour :

  1. CN=*.abc-exemple.com – Sécurise uniquement les blocs connector pour le port 182.
  2. CN=*.exemple.com – Sécurise uniquement le bloc connector pour le port 183.
  3. CN=*exemple.com – Sécurise tous les blocs connector.
  4. CN=*.secure.exemple.com et SAN=*.secure.exemple.com, *.blog.exemple.com, abc.exemple.com, *.login.exemple.com – Sécurise uniquement le bloc connector pour le port 184.

Pour une automatisation réussie, tous les blocs SSLHostConfig au sein d'un connecteur doivent disposer d'un certificat installé.

Par exemple, pour pouvoir automatiser et installer les certificats sur tous les blocs SSLHostConfig, vous devez passer la requête d'automatisation sous la forme suivante :

CN=*.exemple.com et SAN=*.mail.test.com

generic
<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>

IBM

Lorsque la requête d'automatisation arrive, le serveur trouve les blocs <VirtualHost> correspondants selon le CN ou le SAN utilisé dans la requête.

L’IBM server compare le ServerName et le ServerAlias au CN ou au SAN présent dans la requête.

Si le ServerName ou le ServerAlias correspondant est trouvé dans le jeu d'hôtes virtuels, tous les blocs d'hôtes virtuels correspondants seront sécurisés.

Par exemple :

generic
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>

Dans l’exemple ci-dessus, lorsque vous envoyez une requête d'automatisation pour :

  1. CN=*.abc-exemple.com – Sécurise à la fois les blocs d'hôtes virtuels correspondant aux ports 552 et 553.
  2. CN=*.mail.abc-exemple.com – Sécurise uniquement le bloc d'hôte virtuel correspondant au port 551.
  3. CN={551/552/553}.abc-exemple.com – Sécurise uniquement les blocs d'hôtes virtuels respectifs.
  4. CN=*.abc-exemple.com et SAN=*.mail.abc-exemple.com – Sécurise tous les blocs d'hôtes virtuels.
  5. CN=551.abc-exemple.com et SAN=securemail.abc.com – Sécurise uniquement les blocs d'hôte virtuel sur les port 551 et 553.