TLS Certificate Monitoring: What It Is, Why It Matters, and How to Automate It

TLS certificate monitoring is not the same as setting a calendar reminder for certificate expiry. It is continuous automated scanning that covers all the ways a TLS certificate and TLS configuration can fail — and alerts you before it happens.

This guide explains what TLS monitoring actually covers, which specific problems it detects, and how to set it up in your organisation.

What TLS monitoring covers — and what it is not

Most teams start by monitoring expiry dates. That is necessary — but it is only one dimension of TLS risk. A certificate can be technically unexpired and still represent significant risk:

• Weak cipher suites: The certificate is valid, but the server offers RC4, 3DES, or other cryptographically weak algorithms
• Deprecated protocols: TLS 1.0 and 1.1 are disabled in modern browsers but may still be active on servers
• Chain errors: The certificate chain is incomplete — an intermediate certificate is not installed correctly
• OCSP problems: The certificate is issued but revoked, and OCSP validation is not working correctly
• Domain coverage gaps: The certificate does not cover all the domains it is supposed to
• Missing HSTS: The server serves HTTPS but does not send the HTTP Strict Transport Security header

TLS monitoring that only checks expiry dates is like a vehicle inspection that only checks the fuel level.

The seven things TLS scanning actually checks

1. Certificate expiry and renewal window

The baseline: when does the certificate expire, and when does it need to be renewed? With 47-day certificates arriving in 2029, this needs to be scanned daily — not monthly.

2. Certificate chain and intermediate certificates

A complete and correct certificate chain from leaf to root CA is critical. Browsers and API clients behave differently on chain errors — some accept them, others fail silently. Scanning detects chain problems proactively.

3. OCSP revocation status

Certificates can be revoked before expiry if the private key is compromised. OCSP scanning checks whether a certificate is active or revoked — a check many manual processes skip entirely.

4. TLS protocol version

Servers that still offer TLS 1.0 or 1.1 are vulnerable to known attacks and fail modern security standards. Scanning identifies endpoints running deprecated protocols.

5. Cipher suites and cryptographic strength

TLS grading (A+ to F) is a composite score that covers which cipher suites the server offers, whether forward secrecy is supported, and whether weak algorithms like RC4 or NULL-cipher are accessible.

6. HTTP security headers

HSTS, Content-Security-Policy, X-Frame-Options, and X-Content-Type-Options strengthen TLS security. Scanning identifies missing or misconfigured headers.

7. Certificate Transparency logs

CT logs are public records of all issued certificates. Monitoring CT logs detects certificates issued to your domains that you did not order — a signal of shadow IT or compromise.

Internet-facing vs. internal TLS monitoring

A typical organisation's TLS certificates split into two categories with very different visibility:

Internet-facing certificates are accessible from the internet and can be scanned directly. These are relatively easy to monitor and are also discoverable via CT logs.

Internal certificates — on AD servers, intranets, mail servers, CI/CD pipelines, and internal API communication — are only accessible from inside the network. They are systematically missed by external scanning, but they are often the ones that most surprise teams when they expire, because nobody knew they existed.

A complete TLS monitoring solution must cover both. CertControl does this via an on-premise agent that is deployed in the organisation's network and sends scan data to the platform — without requiring any inbound connections.

Scanning frequency: when is once a day enough?

For most organisations, daily scanning is sufficient today. With 47-day certificates from 2029, daily scanning will still be appropriate, but alert thresholds must be adjusted — you cannot wait 30 days to send the first alert on a 47-day certificate.

Recommended alert strategy for 47-day certificates: first alert at 21 days, escalation at 14, critical at 7. With ACME automation the question becomes irrelevant — certificates renew automatically.

How to set up TLS monitoring in practice

1. Inventory your endpoints: Start with internet-facing systems. CT log scanning can help discover subdomains you were unaware of.
2. Define criticality: Not all certificates are equally critical. Categorise endpoints as critical, important, and normal — alert levels should reflect this.
3. Set up alert recipients: Specify who receives which alerts. Avoid shared inboxes without clear ownership.
4. Include internal networks: Deploy an agent to scan internal networks. Internal certificates are at least as important as internet-facing ones.
5. Evaluate ACME automation: For certificates that can be renewed automatically, consider implementing ACME. It eliminates expiry risk for those certificates entirely.
6. Document the process: Describe who does what when an expiry alert fires. This is the documentation NIS2 supervisors and ISO 27001 auditors expect to see.