A website can keep presenting a valid certificate while its TLS security posture changes underneath it. A load balancer update may re-enable an obsolete protocol, a hosting migration may remove a required modern cipher, or one node in a cluster may expose a configuration that differs from the others. Certificate-expiry monitoring alone will not catch these problems.
This guide explains how to use a web cron job to record supported TLS versions and cipher suites, compare them with an approved policy, and alert when the public configuration drifts. The aim is not to chase every theoretical preference. It is to detect changes that affect security, compatibility, or compliance before customers discover them.
What TLS configuration monitoring should answer
A useful check should establish which protocol versions a hostname accepts, which cipher suites can complete a handshake, which certificate chain is served, and whether results vary across resolved endpoints. It should also capture negotiation features that matter to your environment, such as HTTP/2 availability or the presence of TLS 1.3.
Keep this intent distinct from certificate transparency monitoring. Transparency logs help reveal newly issued certificates; a handshake scan shows what your live edge actually negotiates. Both signals are valuable, but they answer different questions.
Define an approved policy first
Before scheduling a scan, write down the expected state. A policy might require TLS 1.2 and TLS 1.3, reject TLS 1.0 and TLS 1.1, forbid known weak cipher families, and require a specific minimum key strength. Compatibility requirements vary, so base the policy on the clients you genuinely support and current guidance for your platform.
- Required protocols: versions that must remain available.
- Forbidden protocols: versions that must never negotiate.
- Allowed cipher families: an explicit allowlist or defensible rule set.
- Endpoint consistency: whether every public IP must expose the same policy.
- Certificate expectations: issuer, names, chain order, and expiry guardrails.
Version the policy alongside infrastructure configuration. When an intentional change is deployed, update the expected fingerprint in the same reviewed change rather than teaching the monitor to accept any new result automatically.
Probe each hostname safely
Create a monitoring endpoint or small scanner that performs bounded TLS handshakes against the production hostname. Test one protocol and cipher candidate at a time, close connections promptly, and enforce short connection and handshake timeouts. A scan should resemble ordinary diagnostic traffic, not a stress test.
Resolve the hostname at the start of each run and sample every returned address when practical. Multi-region CDNs and load balancers can serve different edge populations, so rotate locations or use multiple probes if regional consistency matters. If DNS changes unexpectedly, correlate the result with redirect-chain monitoring and your infrastructure change history.
Store a normalized configuration fingerprint
Raw scanner output often changes order even when the supported set is identical. Normalize protocol names, sort cipher identifiers, remove volatile timing fields, and hash the resulting policy-relevant structure. Store the hash plus a readable summary for comparison.
Keep the hostname, resolved address, scan location, timestamp, accepted protocols, accepted ciphers, certificate fingerprint, and scanner version. Scanner upgrades can change detection behavior, so their version belongs in every result. Use UTC timestamps and check server clock drift when several probes contribute evidence.
Separate security failures from compatibility failures
A forbidden legacy protocol becoming available is a security regression. A required modern protocol disappearing is usually a compatibility or performance regression. Treat both seriously, but route them with different context so responders know whether to disable an unsafe option or restore an expected one.
Also distinguish a definite handshake result from an incomplete scan. Network timeouts, rate limiting, or a temporarily unreachable edge should produce an “unknown” state rather than silently passing the previous policy. Retry with bounded backoff, then alert on persistent uncertainty.
Schedule the monitor at the right frequency
Daily checks are adequate for stable small sites; hourly checks are reasonable for frequently changing infrastructure. Run an additional scan immediately after planned load-balancer, CDN, proxy, or certificate deployments. Stagger checks across hostnames to avoid a burst of handshakes.
The cron job should call the scanner, validate a signed or otherwise protected response, and treat policy drift as a failed check. Keep the job idempotent. Repeated executions must not continually create duplicate incidents for the same unchanged drift.
Design alerts that speed up remediation
An actionable alert names the hostname, affected endpoint, first-seen time, previous fingerprint, current fingerprint, and the exact protocol or cipher difference. Include whether the change appeared on every endpoint or only one node, plus the most recent deployment or infrastructure event.
If a certificate also changed, link the related issuance evidence. If the TLS change followed a broader configuration rollout, compare it with webhook delivery monitoring and other edge-dependent checks to reveal wider impact.
A practical investigation sequence
- Repeat the scan from a second trusted network to rule out a local middlebox.
- Resolve and test every public address separately.
- Compare the change with recent CDN, proxy, operating-system, and library updates.
- Check whether only one region or one deployment pool differs.
- Validate the intended policy with the infrastructure owner.
- Roll back or correct the configuration, then verify the full endpoint set.
Do not “fix” an alert by weakening the expected policy unless the business has explicitly accepted the tradeoff. Document any compatibility exception, owner, scope, and review date.
Review trends and retire exceptions
Keep a compact history of configuration fingerprints and policy results. A timeline helps answer when support changed, whether it coincided with a release, and how long an exception has survived. Review allowed legacy options regularly and remove them once dependent clients no longer need them.
TLS protocol and cipher monitoring closes an important gap between certificate validity and live transport security. With an explicit policy, normalized fingerprints, endpoint-aware checks, and concise alerts, a web cron job can detect risky drift while it is still easy to correct.