When dealing with complex domain structures, a common question arises: Can SSL certificates support second-level wildcards like *.*.example.com? The technical reality is more nuanced than a simple yes/no answer.

Most commercial CAs (Certificate Authorities) follow the Baseline Requirements set by the CA/Browser Forum, which currently don't support multi-level wildcards. Here's what you'll typically encounter:

// Valid certificate patterns
*.example.com  // First-level wildcard
example.com    // Base domain

// Not supported by most CAs
*.*.example.com
*.sub.example.com

For development environments or internal systems, you might consider:

openssl req -new -newkey rsa:2048 -nodes \
-keyout server.key -out server.csr \
-subj "/CN=*.*.example.com"

However, browsers will treat such certificates with caution. Chrome 58+ and Firefox 52+ may display security warnings for non-standard wildcard implementations.

For production environments needing extensive subdomain coverage:

// Option 1: SAN (Subject Alternative Name) certificates
DNS.1 = example.com
DNS.2 = *.example.com
DNS.3 = a.example.com
DNS.4 = b.example.com
...
DNS.100 = z.sub.example.com

// Option 2: Multiple wildcard certificates
*.app1.example.com
*.app2.example.com

Modern browsers implement strict validation rules for wildcard certificates. Testing matrix shows:

For organizations needing flexible certificate management:

// Using ACME with Let's Encrypt (rate limits apply)
certbot certonly --manual \
-d example.com \
-d *.example.com \
-d specific.sub.example.com

Large-scale deployments might consider:

• Private PKI infrastructure
• Service meshes with mTLS
• Cloud provider certificate managers

Wildcard SSL certificates are commonly used to secure multiple subdomains under a single domain. A standard wildcard certificate for *.example.com would cover blog.example.com, shop.example.com, etc. But what if you need to secure dynamic second-level subdomains like user123.app.example.com?

Many developers wonder if certificates support patterns like *.*.example.com. While this seems logical, most Certificate Authorities (CAs) don't offer this due to:

• Security concerns with unlimited subdomain coverage
• Implementation complexities in certificate validation
• Browser compatibility issues

According to the CA/Browser Forum Baseline Requirements (Section 7.1.3):

Wildcard certificates may only be issued for a single level of subdomains.
This means *.example.com is valid, but *.*.example.com is not permitted.

For applications requiring dynamic second-level subdomains, consider:

Option 1: Multiple Single-Level Wildcards

# Nginx configuration example
server {
    listen 443 ssl;
    server_name ~^(?<subdomain>.+)\.app\.example\.com$;
    ssl_certificate /path/to/wildcard.app.example.com.crt;
    ssl_certificate_key /path/to/wildcard.app.example.com.key;
    # ... other config
}

Option 2: Subject Alternative Names (SANs)

For a limited number of predictable subdomains:

openssl req -new -newkey rsa:2048 -nodes \
-keyout example.key -out example.csr \
-subj "/CN=example.com" \
-addext "subjectAltName=DNS:app.example.com,DNS:*.app.example.com"

Option 3: Automated Certificate Management

Using Let's Encrypt with DNS challenges:

# Certbot example with DNS plugin
certbot certonly --manual --preferred-challenges=dns \
-d 'example.com' -d '*.example.com' \
--manual-auth-hook ./authenticator.sh \
--manual-cleanup-hook ./cleanup.sh

Even if you could obtain a double wildcard certificate, browser support would be inconsistent. Modern browsers follow RFC 6125 which specifies:

• Single wildcards must appear in the leftmost label only
• Wildcards only match one label (not multiple levels)

For most use cases, we recommend:

1. Use single wildcards for known subdomain patterns
2. Implement automated certificate provisioning for dynamic needs
3. Consider DNS-level solutions like CNAME flattening when appropriate