Common Name (CN) for a wildcard certificate

A wildcard SSL certificate is considered as an option when looking to secure multiple subdomains within the same domain name. These certificates, using a wildcard character (*) in the domain name field, secure numerous subdomains (hosts) linked to the same base domain.

The Common Name for wildcard certificates always starts with an asterisk and dot (*.).

*.(domainname).com

For example, a standard wildcard certificate issued to *.domain.com will secure www.domain.com, mail.domain.com, info.domain.com, etc. but it will not secure mail.test.com.

The Subject Alternative Name (SAN) must be a wildcard domain (for example, *.yourdomain.com) or based on your listed wildcard domains. For example, if one of your wildcard domains is *.example.com, then you may use www.example.com or www.app.example.com, but not mail.secure.com. An exception is a Secure Site Pro SSL certificate which secures both the domains.

Certificate installation on web servers based on CNs

By default, the requested certificate is assumed to be installed in all matching domains. However, for every DigiCert-supported web server, there are rules that require the certificate to be installed only on the qualified domains.

Nginx

When the automation request arrives, the server finds the matching server blocks based on the CN or SAN used in the request.

Nginx compares the server_name to the CN or SAN present in the request.

If matching server_name is found in the set of server blocks, all the server blocks that match will be secured.

For example:

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

In the above example, when you request automation for:

  1. CN=*.abc-example.com – Secures both port 8010 and 8030 server blocks.
  2. CN=*.mail.abc-example.com – Secures only port 8020 server block.
  3. CN={8010/8020/8030}.abc-example.com – Secures only respective server block.
  4. CN=*.abc-example.com and SAN=*.mail.abc-example.com – Secures all server blocks.

Apache

When the automation request arrives, the server finds the matching <VirtualHost> blocks based on the CN or SAN used in the request.

Apache compares the ServerName and ServerAlias to the CN or SAN present in the request.

If matching ServerName or ServerAlias is found in the set of virtual hosts, all the virtual host blocks that match will be secured.

For example:

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>

In the above example, when you request automation for:

  1. CN=*.abc-example.com – Secures both port 552 and 553 virtual host blocks.
  2. CN=*.mail.abc-example.com – Secures only port 551 virtual host block.
  3. CN={551/552/553}.abc-example.com – Secures only respective virtual host block.
  4. CN=*.abc-example.com and SAN=*.mail.abc-example.com – Secures all virtual host blocks.

IIS

The IIS server does not look for matching CNs or SANs used in the automation request. The certificate will only be installed on the requested IP address and port.

For example:

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

In the above example, when you request automation for:

  1. IP/Port=123.123.123.123: 401, CN=*.example.com – Secures only 123.123.123.123: 401 IP address and port.
  2. IP/Port=125.125.125.125: 402, CN=*.example.com, SAN=*.mail.example.com – Secures only 125.125.125.125: 402 IP address and port.
  3. IP/Port=127.127.127.127: 403, CN=*secure.example.com, SAN=*.example.com – Secures only 127.127.127.127: 403 IP address and port.

Tomcat

When the automation request arrives, the server finds the matching <Connector> blocks based on the CNs and/or SANs used in the request.

Tomcat compares the SSLHostConfig hostName to the CN and/or SAN present in the request.

If matching SSLHostConfig Hostname is found in the set of connectors blocks, then all the blocks that match will be secured.

For example:

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>

In the above example, when you request automation for:

  1. CN=*.abc.example.com – Secures only port 182 connector blocks.
  2. CN=*.example.com – Secures only port 183 connector block.
  3. CN=*example.com – Secures all connector blocks.
  4. CN=*.secure.example.com and SAN=*.secure.example.com, *.blog.example.com, abc.example.com, *.login.example.com – Secure only port 184 connector block.

For successful automation, all the SSLHostConfig blocks within a connector must have a certificate installed.

For example, to successfully automate and install the certificates to all SSLHostConfig blocks, you must place the automation request with:

CN=*.example.com and 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

When the automation request arrives, the server finds the matching <VirtualHost> blocks based on the CNs or SANs used in the request.

IBM server compares the ServerName and ServerAlias to the CNs or SANs present in the request.

If matching ServerName or ServerAlias is found in the set of virtual hosts, all the virtual host blocks that match will be secured.

For example:

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>

In the above example, when you request automation for:

  1. CN=*.abc-example.com – Secures both port 552 and 553 virtual host blocks.
  2. CN=*.mail.abc-example.com – Secures only port 551 virtual host block.
  3. CN={551/552/553}.abc-example.com – Secures only respective virtual host block.
  4. CN=*.abc-example.com and SAN=*.mail.abc-example.com – Secures all virtual host blocks.
  5. CN=551.abc-example.com and SAN=securemail.abc.com – Secures only port 551 and 553 virtual host blocks.