Risk of Wildcard Certificate in SSL with Examples

A wildcard certificate is a specific form of the certificate used in TLS/SSL instances. It is a single certificate with a wildcard character (*) in the domain name field.

This allows the certificate to secure multiple subdomain names (hosts) pertaining to the same base domain.

Get Your Free Linux training!

Join our free Linux training and discover the power of open-source technology. Enhance your skills and boost your career! Learn Linux for Free!

For example, a wildcard certificate for *.(domainname).com, could be used for www.(domainname).com, mail.(domainname).com, store.(domainname).com, in addition to any additional sub domain name in the (domainname).com.

Table of Contents

Advantage of wildcard certificates

Wildcard certificates in the format of *. have become increasingly popular because they provide a way to secure a large number of websites at a low cost by using only a single certificate.

Normally a separate certificate would be required for each subdomain under a domain, and this could lead to a large number of certificates and force cryptographic renegotiation as a user crosses the subdomains.

A wildcard certificate addresses this issue by enabling TLS/SSL encryption on multiple subdomains using a single certificate as long as the domains are controlled by the same organization and share the same second-level domain name.

Generally, there are 4 reasons for choosing a wildcard certificate.

Secure unlimited subdomains
Ease of certificate management
Cost savings
Flexible and fast implementations

Examples of wildcard certificates

For instance, a wildcard certificate for *.mydomain.com works for domains such as app1.mydomain.com and app2.mydomain.com, but not app2.test.mydomain.com. Instead, we end up with domains looking something like app1-test.mydomain.com for test, and app1.mydomain.com for production.

The good news here is that we don’t need to know all of our domains when we issue the certificate, and wildcard certificates tend to be less expensive than multi-domain certificates from third-party issuers.

However, it forces a consistent domain structure internally and externally, meaning that internal cluster servers will need to fit the scheme with something like prod-ucp-1.mydomain.com, and we will generally need to use a split/internal DNS approach for our externally accessible DNS names, such as app1.mydomain.com.

How to Set Up a Wildcard SSL Certificate?

Setting up a Wildcard cert is nothing out of the norm. We just need to follow two simple steps.

STEP #1 Generate a Wildcard certificate signing request (CSR)

Before placing an order for our certificate, we will have to complete a certificate signing request (CSR).

This will help the company whose services we are using determine everything they need to know to assign our certificate. It also tells them what are domains need to be secured.

Remember, as mentioned before, don’t forget to add an asterisk sign to the main domain we would like to secure.

For example: *.helloworld.com

STEP #2 Purchase Wildcard SSL Certificate from CA

Risk of using wildcard certificates

wildcard certificates can create significant security risks since the same private key is used across multiple systems, thereby increasing the risk of compromise across our organization.

wildcards certificate is simply less secure and can open the door to phishing attacks.

If the private key of an ordinary SSL certificate is compromised, only the connections to the individual server listed in the certificate are affected and the damage is easy to be mitigated. On the other hand, the private key of a wildcard certificate is a single point of a total compromise. If that key is compromised, all secure connections to all servers and subdomains listed in the certificate will be compromised.

Should we use wildcard certificates?

If cybercriminals infiltrate our domain, they can gain privileges that allow them to create unlimited domains—all encrypted by our wildcard certificate.

Even worse, these subdomains will appear to be valid because they are authenticated by our wildcard certificate. These illegitimate subdomains allow cybercriminals to host malicious websites that they can then use in phishing campaigns.

How does this work? Any subdomain created for the domain on a web server that uses a wildcard certificate will use the same certificate.

For example, a webserver with a wildcard certificate is hosting the domain https://example.com. Anyone with access to the webserver can set up a subdomain, https://phishing.example.com, on the webserver using the wildcard certificate.

Visitors to the phishing site are not likely to realize that they are on the phishing site because their browsers establish an HTTPS connection using the legitimate wildcard certificate. All these visitors often see is the green highlighted part of the URL which signals a valid site. Most visitors are not likely to scroll through the entire URL to discover the part of the URL which would arouse suspicion about its validity.

So, it just makes sense to avoid using wildcard certificates on production systems. Instead, we should use subdomain-specific certificates that are rotated often. A compromised wildcard certificate can lead to serious repercussions. But we can avoid (or at least significantly mitigate) the potential impact of an attack by using short-lived, non-wildcard certificates.