Overview 💥
Wildcard certificates (e.g., *.domain.com) are commonly used to secure multiple subdomains under a single domain. However, if not configured correctly in Liongard’s TLS/SSL Inspector, these certificates may cause inspection failures—especially when the Inspector is pointed at the root domain (domain.com) instead of a valid subdomain.
This article explains why these failures occur, how wildcard certificates work at the certificate/SAN level, and the steps required to configure your TLS/SSL Inspector to collect successfully.
Why Wildcard Certificate Failures Occur 🤔
1️⃣ Wildcard Certificates Do NOT Automatically Cover the Root Domain
A wildcard certificate issued for:
*.domain.com
covers only subdomains, such as:
www.domain.comapp.domain.commail.domain.com
It does not cover:
domain.com
(root / apex domain)
Unless the certificate explicitly includes the root domain as a Subject Alternative Name (SAN), the certificate is invalid for the root domain.
Certificate SAN Example
Certificate Field | Example Value |
Common Name (CN) |
|
SANs |
|
If domain.com is missing, the Inspector will fail when inspecting the root domain.
2️⃣ TLS/SSL Inspector Requires a Valid, Resolvable FQDN
The Inspector validates certificates using the target FQDN.
If the FQDN:
does not resolve
is not included in the certificate SAN list
resolves to an IP that rejects Cloud Agent scans
…the inspection will fail.
This is a certificate validation rule, not a Liongard-specific limitation.
3️⃣ DNS Misconfiguration or Missing Records
A wildcard may be valid, but if the DNS for the subdomain does not resolve properly (e.g., no A record, CNAME issues), the Inspector will time out or return no certificate.
Steps to Resolve 👨💻
1️⃣ — Confirm Which Domains the Certificate Covers
Inspect the certificate using:
openssl s_client -connect www.domain.com:443
Review the SAN section:
X509v3 Subject Alternative Name: DNS:*.domain.com DNS:domain.com DNS:www.domain.com
If domain.com is NOT listed → the certificate cannot validate the root domain.
2️⃣ — Edit the TLS/SSL Inspector to Use a Valid Subdomain
Choose a working subdomain included in the wildcard certificate:
www.domain.comapp.domain.comAny FQDN covered by your certificate SAN list
How to Update the Inspector:
Go to Inspectors → TLS/SSL
Click ⋮ (three dots) next to the failing Inspector
Select Edit
Replace the target with a valid subdomain
Save and rerun the Inspector
3️⃣ — Verify DNS Resolution
Ensure the subdomain resolves publicly:
nslookup www.domain.com
or
dig www.domain.com
You should get a valid public IP.
4️⃣ — Rerun the TLS/SSL Inspector
Once the Inspector is configured to point to a valid subdomain, the inspection should complete successfully.
Expected Outcome
Condition | Expected Result |
Subdomain is included in SANs | Inspection succeeds |
Root domain not included in SANs | Root inspection fails; subdomain succeeds |
DNS resolves properly | Certificate retrieved |
DNS broken or FQDN blocked | Inspector fails (see Additional Troubleshooting) |
Additional Troubleshooting 🚀
Use this section if the Inspector continues to fail after updating the FQDN.
1. Check DNS Resolution Errors
Issue | Explanation | Action |
| Subdomain does not exist | Create proper A/CNAME record |
No response | DNS provider blocking requests | Test via external DNS resolvers |
Wrong IP | FQDN pointing to internal/private IP | Fix DNS to route externally |
2. Review Blocklisting or Firewall Restrictions
Since TLS/SSL Inspector runs from the Liongard Cloud Agent, the hosting provider may block automated scans.
Signs include:
Timeout
Reset by peer
No certificate returned
Resolution:
Whitelist Cloud Agent IPs
Check WAF/CDN for anti-bot events
Verify SSL termination points
3. Validate Certificate Binding and Port
In some environments (e.g., load balancers, reverse proxies), the certificate is bound to a non-standard port.
Test with:
openssl s_client -connect www.domain.com:8443
If certificate appears on 8443:
→ Update the Inspector to:
https://www.domain.com:8443
4. Check Certificate Chain Issues
Issues like:
Missing intermediate certificates
Expired intermediates
Chain misconfiguration
…can also cause Inspector failures.
Use SSL Labs to confirm chain health.
Wildcard Certificate Coverage 📈
*.domain.com Certificate Coverage
┌──────────────────────────┐
│ domain.com │ ✘ NOT covered
└──────────────────────────┘
▲
│
┌───────────────┼──────────────────────────────┐
│ │ │
▼ ▼ ▼
www.domain.com app.domain.com mail.domain.com ✔ Covered
Wildcard protects only subdomains, NOT the apex.
When to Contact Liongard Support 🦁
Contact Support if:
The certificate validation still fails after using a valid subdomain
You cannot determine which SANs the certificate includes
DNS resolution behaves differently internally vs externally
You suspect Cloud Agent blocklisting
The Inspector shows unexpected or inconsistent results
Please include:
Information Needed | Why It Helps |
Domain inspected | Confirms scope |
Inspector error message | Identifies failure type |
Certificate chain or SAN list | Confirms coverage |
DNS results ( | Validates FQDN resolution |
Hosting provider or CDN details | Helps check anti-bot blocklisting |
Disclaimers ‼️
This behavior is expected due to certificate validation standards, not a Liongard-specific defect.
Wildcard certificates do not automatically cover root domains unless explicitly listed in SANs.
TLS/SSL Inspector requires public reachability; private domains are not supported.
Updates to wildcard certificate SANs require updating the Inspector target if domain coverage changes.