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.
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.
| Field | Fictional example | Purpose |
|---|---|---|
| DNS / SNI / port | portal.example.com / 443 | Select the intended virtual site |
| Path | Internet → proxy → origin | Identify every TLS termination |
| Owner / criticality | Applications team / critical | Route alerts |
| Issuer / SAN / expiry | Approved CA / expected names / UTC | Check identity and remaining lifetime |
| Renewal / deployment | ACME / proxy reload | Separate issuance from activation |
| Nodes / evidence | Two nodes / SHA-256 fingerprint | Confirm coverage |
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.
# 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 $?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.
# 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.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.
# 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 305. 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.
# 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 sslcert6. 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.
# 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/null7. 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.
| Signal | Interpretation | Next step |
|---|---|---|
| Near expiry | Renewal needs planning | Confirm owner and method |
| Rejected chain | Trust or chain issue | Compare client and server |
| Rejected hostname | SAN or wrong SNI site | Inspect destination and binding |
| Connection failure | DNS, network, or service | Separate alert, not a healthy certificate |
| New fingerprint on one node | Potential partial deployment | Test every instance |
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.
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.
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.
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.