Wildcard(*) SSL Certificate In Common Name (CN)

In today's digital landscape, securing your website with SSL certificates is crucial. At IDMWORKS, we have lots of experience providing wildcard SSL certificates and custom development solutions to enhance your security infrastructure.

Recently I faced with an issue with a wildcard(*) in Common Name (CN) in the SSL certificate.

Invoking a SOAP end point over SSL through a standalone java web services client was complaining with an error "the https URL hostname does not match the Common Name (CN) on the server certificate in the client's truststore." To resolve this a new certificate was setup by adding "hostname.subdomain.mycompany.com(FQDN)" in Subject Alternate Name(SAN). This outlines how the new certificate was setup.

What is a WildCard SSL certificate?

A wildcard SSL certificate allows you to secure a website and an unlimited number of subdomains with a single certificate. For instance, if you have multiple subdomains like blog.example.com, shop.example.com, and support.example.com, a wildcard SSL certificate for *.example.com will cover them all. This not only simplifies management but also reduces costs.

Benefits of Wildcard SSL Certificates

1. Cost-Effective: Purchase one certificate instead of multiple individual certificates.
2. Simplified Management: Manage fewer certificates, reducing administrative overhead.
3. Enhanced Security: Provide encrypted connections across all subdomains.

A SSL certificate with CN=*.mycompany.com is called a WildCard certificate. This wildcard SSL certificate would protect a.mycompany.com, b.mycompany.com, c.mycompany.com and so on and so forth. But this certificate will not work if the certificate is used for second, third and other sublevel domains, unless the sublevel domains are added in Subject Alternate Name(SAN) in the certificate.

What is a Certificate CN?

The Certificate Common Name (CN) is the domain name that you want your SSL certificate to protect. It is a critical part of the SSL certificate as it specifies the host or server name. When a browser connects to a website, the SSL/TLS handshake includes verification of the certificate CN against the domain name in the URL.

New Certificate Example

A SSL certificate which has CN=*.mycompany.com will not work for "blog.subdomain.mycompany.com", unless "blog.subdomain.mycompany.com" is added in Subject Alternate Name (SAN).

Below describes the environment where I encountered the issue and also the solution for the issue:

Environment

A Dynamic Invocation Interface (DII) web service java client invoking .NET SOAP web service. The DII web service java client is a standalone java application running on JRE 7.

The Fully Qualified Domain Name(FQDN) in SOAP end point click here.

Certificate Setup

CN=*.mycompany.com

SubjectAlternativeName [
DNSName: *.mycompany.com
DNSName: mycompany.com
DNSName: subdomain.mycompany.com
]

Issue The way the SSL certificate was setup.

Solution

A new certificate was setup by adding "hostname.subdomain.mycompany.com(FQDN)" in Subject Alternate Name(SAN). Below is how the new certificate was setup which resolved the issue.

New Certificate Setup

CN=*.mycompany.com

SubjectAlternativeName [
DNSName: *.mycompany.com
DNSName: mycompany.com
DNSName: hostname.subdomain.mycompany.com

Custom Development Solutions

At IDMWORKS, we understand that each business has unique security needs. Our custom development services ensure that your certificate CN and wildcard SSL certificates are tailored to your specific requirements. We provide comprehensive IAM solutions that include:

• Custom SSL certificate configurations
• Implementation and deployment of wildcard SSL certificates
• Ongoing support and maintenance