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, but not mail.secure.com. An exception is a Secure Site Pro SSL certificate which secures both the domains.
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.
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:
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:
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:
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:
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:
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.comIn the above example, when you request automation for:
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:
<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:
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
<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>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:
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: