TLS certificates: detect expiry before an outage

Monitor certificates actually served with OpenSSL and PowerShell, check SNI and chains, then renew with actionable alerts, a pilot, and rollback.

01

A renewed certificate can still cause an outage

The portal works, renewal reports success, and users then receive a TLS error. The new certificate may be in the server store while the service still presents the old one. Another node may have been missed, or an intermediate may be absent.

Useful monitoring combines inventory, network probes, and deployment evidence. The commands below read metadata and establish diagnostic connections; they do not change bindings or configuration. All example.com domains are fictional. This guide organizes maintenance and does not replace a complete PKI assessment.

02

1. Inventory endpoints, not just certificate files

Create a row for each DNS name, port, protocol, and TLS termination point. A shared certificate may cover services owned by different teams. Include internal certificates, network appliances, and rarely used services.

Separate the certificate exposed by a proxy or CDN from the origin certificate. An Internet check may not see the certificate behind Cloudflare. Test both paths from authorized networks without bypassing access controls.

FieldFictional examplePurpose
DNS / SNI / portportal.example.com / 443Select the intended virtual site
PathInternet → proxy → originIdentify every TLS termination
Owner / criticalityApplications team / criticalRoute alerts
Issuer / SAN / expiryApproved CA / expected names / UTCCheck identity and remaining lifetime
Renewal / deploymentACME / proxy reloadSeparate issuance from activation
Nodes / evidenceTwo nodes / SHA-256 fingerprintConfirm coverage
03

2. Check the served certificate with OpenSSL and SNI

These examples target OpenSSL 3.x and Bash. GNU timeout is a separate utility and is not installed everywhere by default. The probe host needs DNS resolution, network reachability, and approved trust anchors. Probing a public TLS endpoint does not require an administrator account; mutual TLS needs an appropriate authorized method.

-servername sends SNI; -verify_hostname checks the expected identity. The s_client documentation explains that -verify_return_error stops the handshake on validation failure. Simply displaying a chain does not demonstrate acceptance.

To test a specific node, change only the -connect destination to its authorized IP and retain the DNS name for SNI and hostname verification. Repeat per node and IPv4/IPv6 path. One DNS resolution does not automatically cover every instance.

Read only — TLS validation
# Bash, OpenSSL 3.x; GNU timeout limits the complete operation.
timeout 15 openssl s_client -connect portal.example.com:443 \
  -servername portal.example.com -verify_hostname portal.example.com \
  -verify_return_error -showcerts </dev/null
# Read the exit status immediately; nonzero is a failed probe.
echo $?
04

3. Read expiry without confusing dates with trust

The first certificate extracted by x509 is normally the server certificate. Other certificates displayed by -showcerts are certificates sent by the server, not necessarily a complete or validated chain. The client trust store may supply a root.

-checkend takes seconds. A nonzero status needs investigation to separate approaching expiry from a parsing failure; preserve stderr and command status. In pipelines, preserve connection failures too. NotAfter alone checks neither identity, chain, nor revocation.

Read only — metadata and a 30-day horizon
# Metadata only: this pipeline is NOT a trust-validation result.
set -o pipefail
timeout 15 openssl s_client -connect portal.example.com:443 \
  -servername portal.example.com -showcerts </dev/null |
  openssl x509 -noout -subject -issuer -dates -serial \
    -fingerprint -sha256 -ext subjectAltName
# For an existing PUBLIC certificate file (no private key):
openssl x509 -in leaf.pem -noout -checkend 2592000
# 0 = does not expire within 30 days; nonzero = expiry or command error.
05

4. Inventory Windows certificates with PowerShell

The Cert: provider is Windows-specific. Microsoft documents certificate stores and the ExpiringInDays filter. Start with authorized read permissions and keep access-denied errors visible. Do not grant access to private keys for metadata collection.

My is not a universal inventory: IIS may use WebHosting, applications may use PEM or PFX files, and appliances have their own stores. HasPrivateKey reports an associated key, not its contents. An unused expired certificate is not necessarily an impending outage. Map it to a binding before considering removal.

Read only — LocalMachine certificate store
# Windows only; reads metadata, never exports private keys.
Get-ChildItem Cert:\LocalMachine\My |
  Select-Object Subject, Thumbprint, NotAfter, HasPrivateKey,
    @{Name='DaysRemaining';Expression={
      [math]::Floor(($_.NotAfter.ToUniversalTime() -
        [datetime]::UtcNow).TotalDays)
    }} | Sort-Object DaysRemaining

# Other stores may also be relevant, including WebHosting on IIS.
Get-ChildItem Cert:\LocalMachine\My -ExpiringInDays 30
06

5. Inspect IIS and HTTP.sys bindings

On an authorized IIS server, use Windows PowerShell 5.1 with IIS management tools to inspect bindings. Depending on configuration, elevation may be required; do not change server permissions merely to simplify monitoring.

Compare names, ports, stores, and fingerprints with inventory. SNI and centralized certificate-store modes need appropriate interpretation; an empty certificateHash does not prove that no certificate is used. Confirm through a service connection. Renewing a certificate in a store does not prove a binding was updated.

Read only — binding configuration
# Windows PowerShell 5.1, IIS management tools installed.
Import-Module WebAdministration
Get-WebBinding -Protocol https |
  Select-Object protocol, bindingInformation, sslFlags,
    certificateHash, certificateStoreName
# Read HTTP.sys certificate bindings; do not run "delete sslcert".
netsh http show sslcert
07

6. Match the probe to the protocol and trust model

HTTPS, LDAPS, and SMTP STARTTLS require different negotiation. Obtain approved-enterprise-ca.pem from your approved PKI: never trust a certificate solely because the server sends it. These probes do not test an LDAP login or email delivery.

NPS/RADIUS on UDP 1812 is not a direct TLS socket that s_client can probe. For an EAP certificate, inspect the certificate selected in NPS and test authentication with a representative client. VPNs similarly require product-specific protocol and configuration checks.

Read only — SMTP STARTTLS and LDAPS
# SMTP submission: negotiate STARTTLS, not implicit TLS.
timeout 15 openssl s_client -connect mail.example.com:587 \
  -starttls smtp -servername mail.example.com \
  -verify_hostname mail.example.com -verify_return_error </dev/null
# LDAPS uses implicit TLS on 636.
timeout 15 openssl s_client -connect dc01.example.com:636 \
  -servername dc01.example.com -verify_hostname dc01.example.com \
  -verify_return_error -CAfile approved-enterprise-ca.pem </dev/null
08

7. Separate expiry, chain, identity, and availability

An unexpired certificate can still fail because of an incorrect SAN, missing intermediate, untrusted CA, wrong client clock, or incompatible protocol. The basic OpenSSL examples are not complete CRL/OCSP checks. Validate revocation according to application mechanisms and organizational policy.

Compare the affected client path with the monitoring path. TLS interception may expose another certificate; record that path. Never disable TLS validation to make monitoring appear healthy.

SignalInterpretationNext step
Near expiryRenewal needs planningConfirm owner and method
Rejected chainTrust or chain issueCompare client and server
Rejected hostnameSAN or wrong SNI siteInspect destination and binding
Connection failureDNS, network, or serviceSeparate alert, not a healthy certificate
New fingerprint on one nodePotential partial deploymentTest every instance
09

8. Build alerts that lead to action

For relatively long-lived certificates, 60, 30, 14, and 7 days can be starting points. For shorter lifetimes, align thresholds with the renewal window and real response time. An alert that remains active from issuance is unlikely to help.

Schedule daily collection, a probe after renewal, and more frequent checks for critical services. Record DNS, port, UTC expiry, fingerprint, last success, error, and owner. Stale data and failed probes need separate alerts.

Deduplicate by endpoint, assign a ticket, and escalate unacknowledged deadlines. Dashboards must not contain PFX files, private keys, or DNS tokens. Monitoring licenses and costs depend on the chosen product; local OpenSSL and PowerShell commands do not imply a monitoring subscription.

10

9. Automate renewal and monitor deployment separately

ACME automates domain-control validation and issuance. HTTP-01 and DNS-01 have different prerequisites: Let’s Encrypt documents port 80 for HTTP-01 and TXT records for DNS-01. DNS-01 supports wildcard issuance; limit DNS credentials to the required scope.

Choose a maintained client compatible with the platform, protect its secrets, and test against the CA staging environment. Follow its limits and renewal scheduling, including ARI where supported by both client and CA. Do not hard-code an assumed certificate lifetime into monitoring.

Let’s Encrypt recommends automated renewal with operational margin. Add independent evidence: after issuance and deployment, a probe must see the new certificate on every node. Successful issuance and successful service reload are separate events.

11

10. Pilot renewal with a concrete rollback

This phase is a change. Record current bindings and dependencies, prepare the new certificate and chain through the product procedure, and check SANs, intended usage, and service access to its key. Keep private keys in secure storage, outside maintenance reports.

Test one node or service first. Apply the new binding and documented reload, then verify SNI, chain, expiry, and an application transaction from relevant networks. Do not prescribe a global restart as an automatic step.

Plan to restore the previous binding and configuration if the pilot fails, only when the previous certificate remains valid and acceptable. An expired or compromised certificate is not a rollback solution. Retain prior configuration for the approved period, then remove obsolete material according to policy.

12

Checklist before closing the ticket

If renewal depends on memory or repeated manual intervention, infrastructure consulting can establish inventory, monitoring, and deployment procedures. Securing internal CA templates and permissions remains a separate task; the related AD CS guide below covers that area.

  • Every endpoint has an owner, criticality, and renewal method.
  • Stored certificates and certificates actually served have been compared.
  • Every relevant node and TLS path presents the expected certificate.
  • Representative clients validate the hostname, chain, and application transaction.
  • The next deadline and monitoring failures generate assigned alerts.
  • Rollback is documented and secrets remain protected.