SSL Monitoring

Wildcard SSL Certificate Monitoring Best Practices

Wildcard SSL certificate monitoring requires special considerations. Learn to monitor all subdomains, manage single points of failure, and plan renewals carefully.

AzMonitor TeamAugust 20, 20256 min read · 908 wordsUpdated January 20, 2026
wildcard SSLSSL monitoringcertificate monitoringHTTPS

A wildcard SSL certificate (*.yoursite.com) covers all first-level subdomains under your domain with a single certificate. This is convenient for managing multiple subdomains but creates a unique monitoring challenge: when the certificate expires or is misconfigured, it takes down every subdomain simultaneously. Wildcard certificate monitoring requires understanding these risks and monitoring accordingly.

How Wildcard Certificates Work

A wildcard certificate with a common name of *.yoursite.com covers:

  • www.yoursite.com
  • api.yoursite.com
  • app.yoursite.com
  • admin.yoursite.com
  • Any other first-level subdomain

What wildcard certificates DON'T cover:

  • yoursite.com (the apex/root domain itself — requires a separate cert or SAN)
  • sub.api.yoursite.com (second-level subdomains require another wildcard: *.api.yoursite.com)

Modern alternative: Subject Alternative Name (SAN) certificates list specific domains. Let's Encrypt SAN certificates can cover up to 100 domains per certificate, making them a flexible alternative to wildcards.

The Risk Profile of Wildcard Certificates

Wildcard certificates have a unique risk profile compared to single-domain certificates:

Single point of failure: One certificate expiry takes down all subdomains simultaneously. One misconfigured deployment can affect all subdomains that use the same certificate.

Higher value for attackers: A compromised wildcard certificate allows an attacker to impersonate any subdomain of your domain — much more valuable than a single-domain cert.

Wider blast radius for problems: Any certificate problem (expiry, misconfiguration, revocation) immediately affects all services using the wildcard.

Monitoring Strategy for Wildcard Certificates

Monitor Each Subdomain Independently

Even though they all share the same certificate, monitor each subdomain separately:

ssl_monitors:
  - domain: yoursite.com
    check_interval: 5 minutes
  - domain: www.yoursite.com
    check_interval: 5 minutes
  - domain: api.yoursite.com
    check_interval: 1 minute  # Higher priority
  - domain: app.yoursite.com
    check_interval: 1 minute
  - domain: admin.yoursite.com
    check_interval: 5 minutes

Why monitor each separately if they share a certificate? Because:

  • Each subdomain might be deployed on different servers that could have certificate deployment issues
  • A deployment on one subdomain might update the certificate incorrectly for that subdomain only
  • Some subdomains might accidentally be reverted to an older certificate during deployments
  • You want to know which subdomains are affected when problems occur

Alert Well Ahead of Expiry

Because wildcard certificate expiry is catastrophic (all subdomains down simultaneously), alert earlier than you would for single-domain certificates:

| Alert Tier | Days Before Expiry | |-----------|-------------------| | First warning | 90 days | | Renewal urgency | 45 days | | Escalation | 21 days | | Emergency | 10 days | | Critical emergency | 3 days |

The extra lead time accounts for the higher complexity of wildcard certificate renewal (often requires DNS challenge validation, commercial CA coordination).

Track Certificate Fingerprint Across Subdomains

Monitor that all your subdomains are serving the same certificate (not an old, expired certificate on one server):

# Compare certificate fingerprints across subdomains
for subdomain in www api app admin; do
  fingerprint=$(openssl s_client -connect $subdomain.yoursite.com:443 2>/dev/null | \
                openssl x509 -noout -fingerprint 2>/dev/null | \
                awk -F= '{print $2}')
  echo "$subdomain.yoursite.com: $fingerprint"
done

All should match. If one differs, that subdomain is serving a different certificate — possibly an expired one.

Wildcard Certificate Renewal Challenges

DNS Validation Requirement

Most CAs require DNS validation to issue wildcard certificates (HTTP validation can't prove control of all subdomains). This means your renewal process must:

  1. Create a TXT record at _acme-challenge.yoursite.com
  2. Wait for DNS propagation
  3. Let the CA validate the TXT record
  4. Receive the new certificate

This process can take 10-30 minutes and requires DNS access — more complex than HTTP validation for single-domain certs.

Deployment Across All Servers

If you have multiple servers serving your various subdomains, you must deploy the new wildcard certificate to all of them. Missing one server means that subdomain gets certificate errors after the old cert expires.

Deployment checklist:

  • [ ] Web server 1 (www, marketing site)
  • [ ] API server cluster (api subdomain)
  • [ ] App servers (app subdomain)
  • [ ] CDN configuration updated
  • [ ] Load balancer SSL termination updated
  • [ ] Verified each subdomain serves new certificate

Let's Encrypt Wildcard Rate Limits

Let's Encrypt has rate limits that affect wildcard certificates:

  • 50 certificates per registered domain per week
  • 5 failed validation attempts per hostname per hour

Plan your wildcard certificate renewals to avoid hitting these limits, especially if you're testing automation.

When to Use Wildcard vs SAN Certificates

| Scenario | Recommendation | |---------|---------------| | 3-5 specific subdomains | SAN certificate (list them explicitly) | | 6-20 specific subdomains | Either wildcard or SAN | | Dynamic subdomains (per-customer) | Wildcard | | Maximum security | SAN (no wildcard risk) | | Simplicity of management | Wildcard | | Let's Encrypt (free) | SAN (up to 100 domains per cert) |

For most SaaS companies with customer-facing subdomains (customer.yourapp.com), wildcards are the practical choice. For companies with a small, fixed list of subdomains, SAN certificates provide better security.

Monitoring Wildcard Certificate Deployment

AzMonitor's SSL monitoring validates the complete certificate chain, including:

  • Exact expiry date of the presented certificate
  • Whether the certificate covers the requested hostname
  • Complete chain validity
  • TLS version and cipher suite

Configure SSL monitoring for each of your important subdomains, even if they share a wildcard certificate. Start wildcard certificate monitoring and get ahead of the expiry before it takes down all your subdomains at once.

Related: SSL expiry alerts for configuring multi-window warning alerts for certificate renewals.

Tags:wildcard SSLSSL monitoringcertificate monitoringHTTPS
Back to blog
A
AzMonitor Team
The AzMonitor team writes guides based on experience monitoring millions of endpoints daily across 10,000+ customer environments. Our expertise covers uptime monitoring, SRE practices, and reliability engineering.
Try AzMonitor free

3 monitors free forever · No credit card needed · Set up in 2 minutes

Start monitoring free →