Your monitoring is green. Your browser shows a padlock. A user on a mobile network gets a certificate warning and you cannot reproduce it.
A hostname with both an A record and an AAAA record points at two different addresses. Nothing requires those to be the same server, and nothing keeps their configuration in sync. Each address presents whatever certificate it happens to have.
Worse, clients generally prefer IPv6 when it is available. So the endpoint you are least likely to test is often the one a large share of your visitors actually reach.
Check both families explicitly
dig +short example.com A
dig +short example.com AAAAThen query each address directly, forcing the family so nothing quietly falls back:
# IPv4
openssl s_client -4 -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -dates -subject
# IPv6
openssl s_client -6 -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -dates -subjectDifferent dates, a different subject, or one of them failing outright tells you immediately that the two addresses are not the same deployment.
Why they drift apart
| Cause | What happened |
|---|---|
| IPv6 added later | The AAAA record was created during a migration and left out of the deployment automation that handles the v4 host |
| Different infrastructure | IPv6 terminates at a different proxy, a different provider, or a tunnel with its own TLS configuration |
| Partial CDN coverage | The CDN handles one family and the other resolves straight to origin, bypassing the edge entirely |
| Stale AAAA record | The address belongs to a machine that was decommissioned or repurposed, and nobody removed the DNS record |
That last row is the one worth checking first if the IPv6 endpoint fails to connect at all rather than serving a wrong certificate. An orphaned AAAA record is both a broken experience for IPv6 clients and a dangling DNS entry worth cleaning up.
The failure mode this creates
It is not a clean outage, which is what makes it expensive. Some visitors are fine and some are not, split along a line that does not correspond to anything in your logs. Support tickets describe an unreproducible problem. Your uptime checks, which almost certainly run over IPv4 from a fixed location, report everything healthy throughout.
Anything checking one hostname from one network will keep telling you the site is up.
Fix it and keep it fixed
Deploy the certificate to whatever terminates TLS on the IPv6 address, or remove the AAAA record if that endpoint should not be serving traffic at all. Half-configured IPv6 is worse than no IPv6.
Then make both families part of the routine check rather than something you look at after an incident. Discovery and scan coverage covers reading per-endpoint evidence, and certificate deployment covers the wider set of places a renewal fails to land.