html

When you encounter a certificate error for www.groups.example.com despite having a valid wildcard SSL certificate (*.example.com), you're hitting a fundamental limitation of wildcard certificates. The asterisk in a wildcard certificate only covers one level of subdomains.

Your certificate covers:

*.example.com  (valid for: blog.example.com, api.example.com)
example.com    (valid for root domain)

But it does not cover:

*.sub.example.com  (invalid for: www.groups.example.com)
sub.sub.example.com

Option 1: Get a multi-level wildcard certificate (expensive and rare):

*.groups.example.com

Option 2: Use Subject Alternative Names (SANs) in your certificate:

DNS:groups.example.com
DNS:www.groups.example.com

For VHosts setups, ensure your ServerName matches exactly:

<VirtualHost *:443>
    ServerName www.groups.example.com
    SSLCertificateFile /path/to/cert.pem
    SSLCertificateKeyFile /path/to/key.pem
    SSLCertificateChainFile /path/to/chain.pem
</VirtualHost>

server {
    listen 443 ssl;
    server_name www.groups.example.com;
    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;
    ...
}

Use OpenSSL to verify certificate coverage:

openssl s_client -connect www.groups.example.com:443 -servername www.groups.example.com | openssl x509 -noout -text | grep DNS

When requesting certificates from DigiCert or other CAs:

• Always include both root and www variants
• Specify all subdomains explicitly if needed
• Consider using ACME clients for automation

For completeness, ensure proper redirects:

# Apache
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# Nginx
server {
    listen 80;
    server_name www.groups.example.com;
    return 301 https://$host$request_uri;
}

---

When you encounter the "ssl_error_bad_cert_domain" error on a second-level subdomain like www.groups.example.com with a wildcard certificate valid for *.example.com, you're facing a fundamental limitation of wildcard certificates in the SSL/TLS specification.

Wildcard certificates only cover one level of subdomains. The certificate you have (*.example.com) is valid for:

• example.com (root domain)
• anything.example.com (single subdomain)
• But NOT something.anything.example.com (multi-level)

To check your certificate's coverage, use OpenSSL:

openssl s_client -connect www.groups.example.com:443 | openssl x509 -noout -text | grep DNS

This will show the exact Subject Alternative Names (SANs) your certificate covers.

Here are your options to resolve this:

Option 1: Modify Your Subdomain Structure

Change from www.groups.example.com to:

• groups-www.example.com (single level)
• Or groups.example.com without www

Option 2: Get a Multi-Level Wildcard (Not Standard)

Some CAs offer certificates with multiple wildcards like *.*.example.com, but this violates RFC 6125 and may cause compatibility issues.

Option 3: Use Subject Alternative Names (SANs)

Request a certificate with explicit SANs:

openssl req -new -key server.key -subj "/CN=example.com" \
-reqexts SAN -config <(cat /etc/ssl/openssl.cnf \
<(printf "[SAN]\nsubjectAltName=DNS:example.com,DNS:*.example.com,DNS:*.groups.example.com")) \
-out server.csr

If you choose Option 3, here's a sample VirtualHost config:

    ServerName www.groups.example.com
    SSLEngine on
    SSLCertificateFile /path/to/cert.pem
    SSLCertificateKeyFile /path/to/privkey.pem
    SSLCertificateChainFile /path/to/chain.pem
    # Other directives...

Be aware that some older browsers (particularly mobile browsers) may still show warnings even with properly configured SAN certificates due to strict wildcard interpretation.

Use these tools to verify your setup:

• openssl s_client -connect www.groups.example.com:443 -servername www.groups.example.com
• SSL Labs Server Test
• Browser developer tools (Security tab)