Skip to main content

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.

Avis

The Common Name for wildcard certificates always starts with an asterisk and dot (*.). For example, *.(domainname).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.

Note

Le SAN doit correspondre à un domaine à caractère générique (par exemple, *.votredomaine.com) ou être basé 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, mais pas mail.secure.com. Une exception est faite 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 :

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 :

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 :

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 trouve les blocs <Connector> correspondants selon les CN et/ou les SAN utilisés 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 :

http to https Automation

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

<Connector port="8082" connectionTimeout="20000" protocol="HTTP/1.1" defaultSSLHostConfigName="*.avp.cert-testing.com" 
SSLEnabled="true">                   
    <SSLHostConfig hostName="*.avp.cert-testing.com">      
    <Certificate
     certificateKeyFile="C:\Certbot\-v1ItahTQMXDj5mWSECcn7o182xIChVEwGzsznbccjk\live\avp.cert-testing.com\privkey.pem"
     certificateFile="C:\Certbot\-v1ItahTQMXDj5mWSECcn7o182xIChVEwGzsznbccjk\live\avp.cert-testing.com\cert.pem"
     type="RSA"/>
     </SSLHostConfig>
</Connector>

In the above examples, when you request automation for:

  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.

Avis

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

CN=*.exemple.com et 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>

IBM

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

IBM server compare le ServerName et le ServerAlias aux CN ou aux SAN présents dans la requête.

Si un ServerName ou un 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 :

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.