Overview 💥
Partners may occasionally report that Liongard’s SSL/TLS Inspector shows a different certificate expiration date than what they see in their browser for the same domain.
This can appear confusing at first, especially when:
The certificate looks valid in all locations
No recent certificate changes were intentionally made
Multiple tools show different expiration dates
This article explains why this behavior occurs, how Liongard collects SSL/TLS data, and how to confidently validate and explain the results.
Why Does This Happen? 🤔
This behavior is almost always caused by modern web infrastructure, not by incorrect inspection.
1️⃣ CDN / Edge-Based Certificate Delivery (Most Common)
If a domain is fronted by a CDN or load balancer (such as Cloudflare, AWS CloudFront/ALB, Azure Front Door, Akamai, Fastly), it may:
Serve different certificates from different edge locations
Temporarily host overlapping certificates during renewals
Roll out new certificates gradually across regions
➡️ Result:
Two users accessing the same domain from different locations may receive different but valid certificates.
2️⃣ Geographic & Network Routing Differences
TLS certificates are presented during the handshake, and the backend handling that handshake can differ based on:
Geographic location
DNS resolver (ISP vs public DNS)
Network path or ISP routing
IPv4 vs IPv6 resolution
💡 Important note:
Incognito / private browsing mode does not change DNS routing — it only clears browser cache and session data.
3️⃣ Overlapping or Staged Certificate Renewals
Some organizations intentionally deploy:
A new certificate before the old one expires
Multiple certificates for rollback or validation
During this window:
Both certificates are valid
Different tools may observe different expiration dates
How Liongard Collects SSL/TLS Certificate Data 📊
The SSL/TLS Inspector is cloud-based and runs from Liongard’s platform (On-Demand Agent).
Here’s how it works:
You configure public domains or hostnames (and ports, if non-443)
Liongard performs a remote TLS handshake over the public Internet
The results reflect exactly what the target exposes externally at scan time
🔎 Liongard does not:
Use browser caches
Reuse historical certificate data
Rotate scan regions dynamically
➡️ It reports the certificate actually presented during the scan.
Validation Example 🙌
⚠️ The following example uses a sanitized sample domain for demonstration purposes. Certificate details are illustrative but realistic.
Example domain:
https://www.example-secure-site.com
Using OpenSSL to Inspect the Certificate
Run:
openssl s_client -connect <your-domain>:443 -servername <your-domain> | openssl x509 -noout -dates -issuer -subject -pubkey -fingerprint
Replace
<your-domain>with the domain being inspectedThis will display:
Validity period (
notBefore/notAfter)Issuer / Subject
Public key
Certificate fingerprint
Sample Output
Certificate 1 (Edge / Location A)
Issuer: R12 (Let's Encrypt)
Subject: CN=www.example-secure-site.com
Validity: Dec 26, 2025 → Mar 26, 2026
SHA-256 Fingerprint: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0771d5
Public Key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx05577
Certificate 2 (Edge / Location B)
Issuer: R13 (Let's Encrypt)
Subject: CN=www.example-secure-site.com
Validity: Oct 27, 2025 → Jan 25, 2026
SHA-256 Fingerprint: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxd843d3
Public Key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx6715d9205577
How to Interpret This Example
Different certificates are being served
Notice the Issuer, Validity, and Fingerprint differ
This is expected in CDN or edge deployments with staged certificate rollouts
Same public key
Both certificates share the same public key
Indicates the certificate was reissued using the existing key pair, a common approach to reduce complexity while rotating certificates
Edge / location dependent
Liongard’s SSL/TLS Inspector may see either certificate depending on scan edge or region
Browsers in different locations may also observe different expiration dates
SHA-256 fingerprint
Unique for each certificate, confirming the certificates are distinct even if the public key is the same
Certificate 1 (Edge / Location A) | Certificate 2 (Edge / Location B) |
 |  |
How to Confirm Certificate Differences 🧑🏫
Partners can verify whether different TLS/SSL certificates are being served from different locations using OpenSSL:
openssl s_client -connect <your-domain>:443 -servername <your-domain> | openssl x509 -noout -dates -issuer -subject
Replace
<your-domain>with the affected public domain hostname.Compare the following fields between locations or tools:
Expiration dates (
notBefore/notAfter)Issuer (e.g., Let’s Encrypt)
Subject / Common Name (CN)
Serial number (optional for deeper verification)
If differences exist between scans or regions, this confirms edge-based or CDN certificate variance.
💡 Tip: Run the command from multiple networks, regions, or devices to see if the certificate changes.
Is This a Liongard Issue? 🧐
No. Liongard is accurately reporting the certificate it receives during its scan.
This aligns with:
Direct TLS handshake behavior
Command-line tools (
curl,openssl)Third-party SSL verification services
Different expiration dates do not indicate incorrect inspection — they reflect how the domain is configured publicly.
Recommended Actions 🤩
If consistent certificate reporting is required across all tools and regions:
Review CDN or load balancer certificate configuration
Identify overlapping or staged certificates
Complete any in-progress certificate rotation
Ensure a single active certificate is deployed across all edge locations
References 📚
Disclaimer ‼️
The external links provided in this article are for informational purposes only. Liongard does not own, control, endorse, or guarantee the accuracy, completeness, or availability of content on third-party websites. Configuration steps, interfaces, and behaviors may change without notice. Partners should always refer to official vendor documentation and validate changes in their own environments.