TLS Configuration Monitoring: Cipher, Chain, OCSP & CT Logs

The certificate is valid. The browser padlock is green. The expiry monitor says there are 83 days left. And yet a subset of Android users cannot connect, an API client fails with certificate verify failed, PCI-DSS scanning flags deprecated TLS, and your CDN status page shows nothing wrong.

This is the gap between certificate expiry monitoring and TLS configuration monitoring. Expiry is only one failure mode. The handshake can break because the intermediate certificate chain is incomplete. Security can regress because TLS 1.0 was re-enabled by a load-balancer template. Mobile clients can fail because the server stopped stapling OCSP. A new subdomain can launch without SAN coverage. A certificate can be issued for your domain by an unexpected CA and show up in Certificate Transparency logs.

If you only monitor notAfter, you will miss most of this.

This guide covers the production TLS checks worth running continuously: protocol versions, cipher suites, certificate chain validity, SAN coverage, OCSP stapling, Certificate Transparency logs, HSTS preload status, and external grading. It extends SSL Certificate Expiration: The Preventable Outage from "will the cert expire" to "is the TLS surface safe and compatible right now."

TLS Monitoring Is More Than Expiry

A complete TLS monitor answers five questions:

Is the certificate valid today? Not expired, not before start date, trusted root.
Is the chain valid? Leaf -> intermediate -> root can be built by real clients.
Is the configuration safe? TLS 1.2/1.3 only, modern cipher suites, forward secrecy.
Is revocation status available? OCSP stapling works where expected.
Did anyone issue a certificate for us unexpectedly? Certificate Transparency monitoring.

Most outages happen in the second and third buckets, not the first.

TLS Version Monitoring

TLS 1.0 and 1.1 have been deprecated for years. In 2026, production public sites should support:

TLS 1.2
TLS 1.3

And should reject:

SSLv2
SSLv3
TLS 1.0
TLS 1.1

Why monitor this continuously? Because TLS settings often live in infrastructure templates, CDN policies, or load-balancer profiles. A rollback or migration can silently re-enable old versions.

Alert when:

TLS 1.0 or 1.1 becomes accepted on production
TLS 1.3 support disappears unexpectedly
Different regions/CDN edges expose different versions

PCI-DSS and many enterprise procurement scans will fail public endpoints that accept old protocol versions. See PCI DSS Compliance Monitoring.

Cipher Suite Monitoring

Cipher drift is subtle. You do not need to inspect every cipher manually, but you do need a policy.

Healthy policy in 2026:

TLS 1.3 ciphers: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256
TLS 1.2: ECDHE key exchange, AES-GCM or CHACHA20-POLY1305
Forward secrecy required

Reject or alert on:

NULL ciphers
EXPORT ciphers
RC4
3DES
CBC-only fallback for modern clients
Static RSA key exchange without forward secrecy
Anonymous DH

The incident pattern: a dev/test load-balancer profile with "maximum compatibility" gets applied to prod. Everything still works, but your security grade drops and compliance scans fail.

Certificate Chain Monitoring

A browser does not only validate the leaf certificate. It builds a chain:

Leaf certificate: www.example.com
Intermediate CA: Example Intermediate R3
Root CA: Example Root

The server usually sends the leaf and intermediate. The client already trusts the root. If the server forgets to send the intermediate, some clients can still recover by fetching it. Others cannot.

Common chain failures:

Missing intermediate certificate
Wrong intermediate certificate after CA rotation
Cross-sign transition breaks older clients
Root removed from older Android or embedded trust stores
Certificate installed on one CDN edge but not all edges

The Let's Encrypt DST Root CA X3 cross-sign expiry in 2021 is the canonical reminder: the certificate can be "valid" and still fail for a meaningful set of clients because chain-building differs across platforms.

Monitor the chain from multiple probe environments, not just one modern browser stack.

SAN Coverage and Hostname Drift

The Subject Alternative Name (SAN) list determines which hostnames the certificate covers.

Alert when:

A monitored hostname is not present in SAN
A wildcard does not cover the intended depth (*.example.com does not cover api.eu.example.com)
A new production subdomain launches without cert coverage
SAN list changes unexpectedly

This matters during migrations, regional launches, and custom-domain onboarding.

Pair with Domain Expiry & WHOIS Monitoring: the domain can be valid while the certificate does not cover the host.

OCSP Stapling Monitoring

OCSP tells clients whether a certificate has been revoked. OCSP stapling lets the server attach a recent revocation response during the TLS handshake.

Why it breaks:

CDN disables stapling on a new edge policy
OCSP responder outage
Intermediate CA transition changes responder URL
Stapled response expires and is not refreshed

Monitor:

Stapling present when expected
OCSP response status is good
Stapled response is not expired
Responder is reachable from multiple regions

Some clients soft-fail revocation checks. Others fail closed in enterprise environments. If you sell to enterprises, OCSP failures become customer-visible.

Certificate Transparency Log Monitoring

Certificate Transparency (CT) logs record publicly trusted certificates. This is how you detect unexpected certificates issued for your domain.

Monitor CT logs for:

New certificates for your apex and subdomains
Unexpected CA
Unexpected SAN entries
Certificates issued outside your normal automation path
Wildcard certificate issuance

Not every unexpected cert is malicious. Sometimes a team added a new CDN or a customer-hosted tenant. But every unexpected cert deserves review.

Alert routing:

New cert from expected CA and expected automation account: informational
New cert from unexpected CA: high
New wildcard cert or sensitive subdomain cert from unexpected CA: critical

This is a supply-chain and domain-control signal, not just a TLS signal.

HSTS and Preload Status

HSTS is technically an HTTP security header, but it directly affects TLS behavior:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Monitor:

Header present on HTTPS entry points
max-age meets policy
includeSubDomains present if you rely on it
preload present if submitted to preload list
HSTS preload-list status for critical domains

See HTTP Security Headers Monitoring: CSP, HSTS, CORS Drift for the broader header layer.

External Grade Monitoring

SSLLabs/Qualys-style grades are useful as a summary, but do not rely on a letter grade alone. Track the underlying checks:

Supported protocol versions
Cipher policy
Chain validity
OCSP stapling
HSTS
Certificate validity dates
Known vulnerabilities (ROBOT, POODLE, Heartbleed-class findings)

Use grade drops as a high-level alert, then rely on your own checks for diagnosis.

Multi-Region TLS Monitoring

TLS configuration can vary by edge.

Examples:

CDN edge in one region still serves old certificate
Regional load balancer lacks intermediate chain
Enterprise network path hits different CDN POP with stale config
IPv6 endpoint serves different certificate from IPv4

Monitor from multiple regions and both IPv4/IPv6 where supported. See Multi-Region Monitoring: Why Location Matters.

What to Alert On

Critical (page)

Certificate chain invalid for production hostname
Hostname not covered by SAN
TLS handshake fails from any primary region
TLS 1.0 or SSLv3 accepted on payment/auth endpoints
Unexpected certificate issued for sensitive subdomain in CT logs
OCSP stapled response expired on enterprise-facing endpoint

High (notification)

TLS 1.3 support disappears
Weak cipher suite appears
OCSP stapling missing where expected
External TLS grade drops
HSTS missing on apex or www
Certificate chain differs across regions

Informational

New expected certificate issued
SAN list changed
Intermediate CA changed
HSTS max-age changed but still within policy

TLS Configuration Monitoring Checklist

Certificate expiry monitored separately
TLS versions probed (1.2/1.3 accepted; old versions rejected)
Cipher suite policy enforced
Forward secrecy required
Certificate chain validates from multiple probes
SAN coverage checked for every monitored hostname
OCSP stapling checked where required
CT logs monitored for new certificates
HSTS header and preload status monitored
IPv4 and IPv6 endpoints checked where applicable
Multi-region probes enabled
PCI-DSS/SOC 2 evidence retained for TLS checks
Runbook exists for CA/intermediate rotation

See SOC 2 Compliance Monitoring for evidence and audit controls.

How Webalert Helps With TLS Configuration Monitoring

Webalert can monitor the handshake and the user-visible HTTPS endpoint:

TLS checks - Detect certificate validity, hostname mismatch, chain failures, and days until expiry.
Protocol and cipher monitoring - Alert when old protocol versions or weak ciphers appear.
OCSP checks - Verify stapling and revocation response freshness where supported.
CT log alerts - Notify when new certificates appear for your domain.
HTTP checks - Confirm the HTTPS endpoint returns the expected status and content after TLS succeeds.
Header checks - Pair TLS monitoring with HSTS and security-header assertions.
Multi-region checks - Probe from different regions to catch CDN edge drift.

Example Webalert configuration:

URL: https://www.example.com/
Expected TLS versions: TLS 1.2 and TLS 1.3 only
Reject: TLS 1.0, TLS 1.1, SSLv3
Certificate SAN must include: www.example.com
Chain must validate: true
HSTS header must contain: max-age=
Alert if CT log sees unexpected CA for example.com

See features and pricing for details.

Summary

Certificate expiry is only one TLS failure mode.
Monitor protocol versions, cipher suites, chain validity, SAN coverage, OCSP stapling, CT logs, and HSTS.
TLS misconfig often arrives through CDN, load-balancer, or infrastructure-template changes rather than application code.
Multi-region and IPv6 probes matter because edge configuration can drift.
Compliance scans care about protocol and cipher policy, not just certificate dates.
Pair TLS monitoring with domain expiry, DNS monitoring, and HTTP security-header monitoring.

The padlock can be green while the configuration is still wrong. Monitor the handshake, not just the date.

Monitor TLS configuration before customers or auditors find the drift

Start monitoring with Webalert ->

See features and pricing. No credit card required.