SSL Certificate Management: Inventory, Monitoring and Automation

To manage SSL certificates, you need three things: an inventory of every certificate you run, monitoring that warns the right person before a certificate expires, and automation that renews and redeploys certificates without manual steps. Teams that skip one of the three usually learn about it through an outage. With public TLS certificate lifetimes shrinking every year until 2029, manual tracking in a spreadsheet no longer scales.

What is SSL certificate management?

SSL certificate management is the process of discovering, issuing, deploying, monitoring, renewing and retiring the SSL/TLS certificates an organization uses. It is also called TLS/SSL certificate lifecycle management, because every certificate moves through the same stages from request to replacement.

The goal is simple: no certificate expires unexpectedly, no unknown certificate runs in production, and every private key stays under control. Good certificate management also gives you a fast answer when something changes, such as a CA incident that forces mass replacement or a new industry rule on validity periods.

Key fact	What it means for you
Maximum lifetime (as of October 2026)	200 days for public TLS certificates issued since 15 Mar 2026, falling to 47 days by 15 Mar 2029 (CA/Browser Forum ballot SC-081)
Lifecycle stages	Discover, request, validate, issue, deploy, monitor, renew or revoke
Standard automation protocol	ACME (Automatic Certificate Management Environment), defined in RFC 8555
Main failure cause	Missed expiry dates on certificates nobody owns or knows about
Minimum toolset	Inventory, expiry alerts, ACME client or management platform, a way to verify deployment

Why monitor SSL certificates?

You monitor SSL certificates because an expired or misconfigured certificate breaks trust instantly: browsers show a full-page warning, API clients refuse to connect and mail servers may reject or downgrade connections. Monitoring turns a surprise outage into a planned task.

The risks go beyond expiry. Monitoring also catches certificates issued for your domains that you did not request, servers still presenting an old certificate after a renewal, missing intermediate certificates and weak configurations left on forgotten hosts. Each of these shows up in user-facing errors long before anyone reads a log.

Expiry problems tend to hit the systems people forget: a load balancer set up years ago, a staging host that became production, a mail gateway, a VPN portal or an embedded device with a web interface. That is why inventory comes before monitoring.

How do I keep track of dozens of SSL certificates across servers?

Keep track of many SSL certificates by combining automated discovery with a single inventory that records each certificate’s owner, location and expiry date, then attach alerts to that inventory. Once the list is complete, move as many certificates as possible to ACME or a certificate-as-a-service (CaaS) plan so renewals stop depending on people.

What to record for each certificate

An inventory is only useful if it answers “who fixes this, and where is it installed?” in seconds. Record at least these fields:

Field	Why it matters
Common name and all SAN entries	Shows exactly which hostnames break if the certificate fails
Issuer, product and validation type (DV, OV, EV)	Tells you which CA account and process renews it
Not-after date (expiry)	Drives all alerts and renewal planning
Endpoints and IP/port	Every server, load balancer or CDN that holds a copy
Owner and backup owner	A named team or person, not “IT”
Renewal method	ACME, platform API or manual, so gaps are visible

Scan your network for SSL certificates

A certificate discovery tool connects to IP ranges and common TLS ports (443, 8443, 465, 587, 636, 993, 995 and others you use) and reads the certificate each service presents. Scan internal networks from inside, and scan your public ranges from outside, because a load balancer may show a different certificate than the server behind it.

Also scan by hostname, not only by IP. Servers that host several sites use SNI (Server Name Indication, a TLS extension that tells the server which hostname you want), so a scan by IP alone sees just the default certificate.

Assign an owner to every certificate

Discovery finds certificates; ownership gets them renewed. Map each certificate to the team that runs the service, and route alerts to a shared channel or ticket queue rather than one person’s inbox. People change roles; queues do not.

Certificates on internal-only names deserve their own list. Public CAs have not issued certificates for internal names or reserved IP addresses since 2015, so those hosts rely on a private CA. The differences are covered in our guide to private and internal certificates.

How to monitor SSL certificate expiration

To monitor SSL certificate expiration, check every endpoint on a schedule, compare the certificate’s not-after date with today, and alert the owner at fixed thresholds well before expiry. Monitor the live endpoint, not only the inventory record, because a renewed certificate does nothing until it is deployed.

With shorter lifetimes, fixed “30 days before expiry” rules become less useful. A practical approach is to alert when about one third of a certificate’s lifetime remains, escalate at a few days, and treat any certificate under 72 hours as an incident.

Remaining validity	Action	Who gets notified
About one third of lifetime	Automation should already have renewed; if not, open a ticket	Certificate owner queue
14 days	Investigate why automation failed; renew manually if needed	Owner plus team lead
7 days	Escalate; schedule deployment	On-call engineer
Under 72 hours	Treat as an incident	On-call and service manager

How to continuously monitor SSL/TLS certificates

Continuous monitoring means more than an expiry countdown. Each check should also confirm that the hostname matches, the chain is complete, the certificate has not been revoked and the endpoint presents the certificate you expect. For a one-off check of a single site, use our SSL checker; for an estate, schedule checks every few hours.

What tools can monitor SSL certificate expiry for free?

You can monitor SSL certificate expiry for free with a scheduled script that reads each endpoint’s certificate, with a free Certificate Transparency log alert service, or with the certificate check built into many uptime monitors. Free options work well for tens of certificates; beyond that, ownership, reporting and renewal integration become the limiting factor.

A minimal scripted check uses OpenSSL, which ships with most Linux and macOS systems:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -enddate -checkend 1209600

The -checkend value is in seconds (1,209,600 seconds is 14 days); the command returns a non-zero exit code if the certificate expires within that window, which a cron job or CI pipeline can turn into an alert.

Whatever you choose, judge an SSL certificate monitoring tool by these criteria:

• Checks by hostname with SNI, on any port, from inside and outside your network
• Reads the live certificate, not just a stored record
• Alerts to shared channels (email list, chat, ticketing, paging) with escalation
• Validates the full chain, hostname match and revocation status
• Exports data or offers an API, so your inventory stays the single source of truth
• Watches Certificate Transparency logs for unexpected issuance on your domains

Tip: Add a CAA DNS record (Certification Authority Authorization, which lists the CAs allowed to issue for your domain) to every domain you own. Combined with Certificate Transparency monitoring, it limits and exposes certificates issued outside your approved process.

SSL certificate automation with ACME

ACME is an open protocol that lets software request, validate, install and renew certificates without human steps; it is standardized as RFC 8555 by the IETF. An ACME client on your server or in your pipeline talks to the CA’s ACME server and handles the whole renewal cycle on a schedule.

The flow is the same with every ACME-capable CA:

1. The client registers an account with the CA’s ACME directory URL.
2. It places an order for one or more hostnames.
3. The CA issues challenges, usually an HTTP file (http-01) or a DNS TXT record (dns-01), to prove domain control.
4. The client completes the challenges and submits a CSR (certificate signing request).
5. The CA issues the certificate; the client installs it and reloads the service.

What is ACME and can I use it with a paid certificate?

Yes. Many commercial CAs, including Sectigo and DigiCert, support ACME for paid certificates by using External Account Binding (EAB), which links your ACME client to your paid account. The CA gives you a key identifier and an HMAC key; you enter both when you register the client, and every certificate it requests is billed to and governed by that account.

Paid ACME adds what free services leave out: a support contact, account-level policy and reporting, and in some offerings OV certificates once the organization is pre-validated. Check the product details before you plan OV or EV through ACME, because availability differs by CA and product.

Integrate SSL certificates into DevOps workflows

Treat certificates like any other deployable artifact. In practice that means:

• Request and renew certificates from the pipeline or the platform, never from a laptop.
• Store private keys in a secrets manager or hardware module, never in source control.
• Use the dns-01 challenge for load-balanced or internal-facing services that cannot answer HTTP challenges.
• Define certificates in infrastructure-as-code so every environment gets them the same way.
• Add a post-deployment test that fails the build if the endpoint serves the wrong or an incomplete chain.

Containers and orchestrated platforms usually work best with an ACME controller that issues certificates for each service and stores them as secrets. Pick one that supports EAB if you use a paid CA.

Manage SSL certificates on Windows

IIS (Internet Information Services) does not renew public certificates on its own. Use an ACME client built for Windows, or a management agent, that writes renewed certificates to the local machine store and updates the site bindings. For farms of IIS servers, the IIS Central Certificate Store lets several servers load certificates from one shared location.

To list certificates in the local machine store that expire within 30 days, run this in PowerShell:

Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.NotAfter -lt (Get-Date).AddDays(30) } |
  Select-Object Subject, NotAfter, Thumbprint

How should we prepare our certificate processes for 47-day lifetimes?

Prepare for 47-day lifetimes by putting ACME (or a CaaS plan) on every endpoint you can, automating domain control validation (DCV), and finishing a complete inventory before each new limit takes effect. Anything still renewed by hand in 2029 will need renewal roughly every six weeks.

As of October 2026, the CA/Browser Forum schedule caps public TLS certificates at 200 days, then 100 days from 15 Mar 2027 and 47 days from 15 Mar 2029. The full timeline and what it means for plan terms is explained in our guide to how long SSL certificates last.

Milestone	Readiness goal
Now (200-day limit)	Complete inventory and owners; expiry monitoring on every endpoint
Before 15 Mar 2027 (100 days)	ACME or CaaS on all standard web servers and load balancers
During 2027–2028	Automate DCV through DNS provider APIs; cover appliances and legacy hosts
Before 15 Mar 2029 (47 days)	Manual renewals limited to documented exceptions; domain validation reuse drops to 10 days, so DCV must run automatically

Automate domain control validation

Validation reuse windows shrink along with lifetimes, so DCV becomes as frequent as renewal. Give your ACME client scoped API access to your DNS provider for dns-01 challenges, or make sure every web host can serve http-01 challenge files. Email-based validation does not automate well and should become the exception.

Handle systems that cannot run ACME

Some appliances, older applications and embedded devices cannot run an ACME client. Put them behind a reverse proxy or load balancer that terminates TLS and can be automated, replace them on your hardware roadmap, or track them on a short “manual renewal” list with stricter alerts.

How to manage SSL certificates at scale (thousands of certificates)

At thousands of certificates, you manage SSL certificates through policy and a central platform, not individual tickets: one approved set of CAs, one inventory, automated issuance through ACME or APIs, and role-based access for each team. The work shifts from renewing certificates to enforcing standards.

When you evaluate SSL certificate management software, compare these capabilities:

Capability	What to look for
Discovery	Network, cloud and CT log discovery that feeds one inventory automatically
Automation	ACME with EAB, REST API, and agents or connectors for servers and load balancers
Policy control	Approved CAs, key types and sizes, allowed domains, approval workflows
Access control	Role-based permissions per team, business unit or domain
Reporting and audit	Expiry reports, issuance history and exportable audit logs
Multi-CA support	Ability to switch or combine CAs quickly after a CA incident

Organizations buying at this scale usually combine a management platform with volume agreements. See our enterprise SSL options for bulk ordering, OV and EV at scale, and account-based automation.

Manage multiple SSL certificates with ACME plans

The easiest way to manage multiple SSL certificates is to buy them as an automation plan instead of as individual certificates. You get an account, connect your ACME client once, and let it renew certificates for as long as the plan runs.

• Sectigo ACME Certificate-as-a-Service (DV) and Sectigo PositiveSSL ACME Certificate-as-a-Service (DV) issue Sectigo (formerly Comodo CA) DV certificates through ACME with External Account Binding.
• RapidSSL Plan + Automate and GeoTrust DV Plan + Automate are DV plans from DigiCert-owned brands, designed for automated issuance and reissue during the plan term.

All four are domain-validated, so they suit web servers, APIs and internal-facing services with public hostnames. For OV or EV certificates at scale, use an account-based enterprise setup.

Renewal is part of management, not a separate project

Even with automation, someone needs to know how a manual renewal works when a client breaks or a new system arrives. Our step-by-step guide shows how to renew an SSL certificate without downtime, and you can install an SSL certificate on each server type with the matching guide.

Common SSL certificate management mistakes

• Tracking expiry in a spreadsheet that nobody owns.
• Sending alerts to one person’s mailbox.
• Renewing the certificate but not deploying it to every load balancer, CDN or node.
• Forgetting the intermediate certificate, which breaks the certificate chain on some clients.
• Reusing the same private key for years across many servers.
• Leaving expired and replaced certificates in server stores, where they get bound by mistake.