Solution for enterprise IT and security

Find, automate and control certificate lifecycle risk

The certificate that causes the next outage is often not the one your PKI team knows about.

What this page answers

Enterprise certificate risk is an inventory problem first and an automation problem second. Teams that only automate the names they already issue will still be paged by the load-balancer leftover, the vendor SaaS upload, the marketing site on a forgotten host, and the appliance nobody wants to touch. sslcertificates.io is an API-first lifecycle layer: find what you can, issue and deploy where connectors exist, keep unsupported targets visible, and record who changed what. It is not a sensor grid that pretends to have scanned your entire WAN, and it is not a drop-in replacement for a Keyfactor or DigiCert Trust Lifecycle Manager estate built on agents.

Why this is getting harder now

Publicly trusted TLS subscriber certificates issued on or after 15 March 2026 may be valid at most 200 days. From 15 March 2027 the maximum is 100 days. From 15 March 2029 it is 47 days. Domain and IP validation reuse falls to 10 days on that 2029 date (CA/Browser Forum Baseline Requirements §§6.3.2 and 4.2.1). Existing certificates are not shortened. The operational meaning is: every known public name needs more changes, and every unknown name has less time between “still valid” and “outage.”

Vendor-sponsored surveys describe the same shape. In Keyfactor’s 2025 Wakefield research, 86% of surveyed organizations reported at least one certificate-related outage in the previous year; 42% cited staffing or expertise, 42% automation complexity, 42% shortening lifespans, 34% lack of visibility; only 17% reported complete real-time visibility. In DigiCert’s 2026 Omdia-commissioned research, 34% said they had a complete and current view of digital certificates. DigiCert’s 2026 Certificate Management Outlook reported 34% experienced an expiration-led service outage, 72% expected volume to increase, and 70% were preparing for shorter lifetimes. Those figures are not a census of your company. They are a reason to measure your own inventory instead of assuming the PKI team’s CA portal is the estate.

Pains that show up in large organizations

Incomplete inventory.

CA portals list what that CA issued. Cloud consoles list what that cloud issued. Spreadsheets list what someone remembered. The union is not automatically maintained.

Outages from expiry, not from cryptography.

The handshake still works until notAfter. Then a payment API, a VPN, or a partner integration fails. The war room opens around a name that was “someone else’s.”

Shorter lifetimes punish manual workflows.

A change-control process that assumes annual certificates cannot absorb 200-day then 100-day then 47-day maxima without automation or a larger staff.

Decentralized issuance.

App teams, agencies, and vendors buy or ACME their own leaves. Central PKI finds out from Certificate Transparency or from the incident.

Mixed public TLS and private PKI.

Different trust stores, same failure mode (something expired, someone was not paged). Treating them as one shopping cart is how private roots get pasted into public sites.

Uneven deploy automation.

Kubernetes may rotate. The F5 and the vendor portal do not. A program that only counts “percent automated” will hide the dangerous remainder.

Audit asks for evidence you do not have.

Who issued, who downloaded a key, who revoked. If the answer is a shared CA login, the control is theatrical.

Consequences

Customer-facing downtime, failed partner certifications, emergency vendor professional services, and a board slide that says “certificate outage” because that is easier to understand than “we did not know the name existed.”

Why common approaches fail

Spreadsheets (DigiCert/Omdia’s 2026 coverage also cited 47% spreadsheet tracking in that sample) do not notice a new name. One CA’s CLM may be excellent and still blind to the other CA and the shadow ACME. Email from the CA goes to a leaver. Buying another scanner without owners produces a PDF. Mandating “all certs on platform X” without an exception process produces shadow IT.

How sslcertificates.io participates

Need	What we actually do
See names	Import hostname/PEM, panel/cloud discover, CT for unexpected public issuance
Issue	REST + connected public CAs + sandbox
Deploy	Connectors with verify/rollback where implemented
Exceptions	Action Required, owners, runbooks — not fake 100% automation
Control	Organizations, roles, scoped keys, audit, optional SSO/SCIM
Private PKI	A separate product surface at /pki — not the lead story

Inventory maturity model

Level 0 — Memory

People know the important names. Outages educate the rest.

Level 1 — Spreadsheet / mailbox

Dates and some issuers. No discovery. No handshake check. Rotates when the file owner changes jobs.

Level 2 — CA portal

Accurate for one issuer. Blind to others, to vendor uploads, and to forgotten appliances.

Level 3 — Observed inventory

Named endpoints, imports, CT, panel discovery. Owners assigned. Still many manual installs.

Level 4 — Automated path plus exceptions

Issue → deploy → verify on supported targets. Everything else is a managed exception with a runbook. This is the honest target.

Level 5 — Continuous control

SSO/SCIM joiners and leavers, audit on key download, webhook into ITSM, regular CT review. Not “no humans.” Humans handle exceptions.

Original asset: 47-day readiness checklist

Use this before 15 March 2029. Several items are already due because the 200-day cap is in force.

List every public hostname you are willing to have page an executive. If a name is not on the list, decide that explicitly.
Record issuer, terminator, owner, and validation method for each. Empty owner is a defect.
Pull CT for your registered domains and reconcile unexpected leaves. Observation ≠ compromise; it is a ticket.
Measure current lifetime mix. How many names still assume ~398-day habits?
Pick the automation path for names you terminate (API + connector, or in-cluster ACME, or cloud-native). One path per name.
Write the exception runbook for vendor appliances. Include who can log in at 02:00.
Verify deploy — fingerprint after install — on the automated path. Issuance is not done.
Shorten change windows in ITSM now (200-day), not in 2029.
Check CAA so emergency issuer changes are possible or forbidden on purpose.
SSO/SCIM for the people who can download keys. Shared CA logins fail joiner/leaver.
Sandbox the API so app teams can integrate without minting public trust in a sprint crunch.
Do not tell auditors you are “on 47-day certificates” unless you chose that validity. The mandate date is 15 March 2029.

Workflow

Start with discovery of named endpoints, not with a purchase of every CA logo. Assign owners. Split the list into automated vs exception. Connect the CAs you already have. Issue replacements for the automated set; prove the handshake. Pipe certificate.renewal_failed into the same ITSM you use for other P1s. Review CT monthly. Private PKI stays a parallel program with its own trust store. SSO belongs under Organization → Security, not in the certificate integration directory.

Before and after

Before

Three CA portals, a spreadsheet last updated for an audit, and a war room for a name marketing launched on a cheap host.

After

Observed inventory, automated renew/verify on what you terminate, exceptions with owners, audit on key material, shorter-lifetime math in the change calendar.

Getting started

Import twenty hostnames you already know. The gaps appear immediately.
Connect one CA or use sandbox. Issue for a non-production name.
Turn on SSO if you are on Scale, Business or Enterprise.
Schedule the CT review. Assign the first exception owner.

Pricing · SSO · Unmanaged monitoring · CT

Security and trust

Roles and scoped keys. CSR mode so private keys never leave your HSM. Audited downloads when the platform generates a key. Webhook HMAC. We do not claim SOC 2, ISO 27001, an uptime percentage, or a customer count on this page. If you need those reports, ask — do not read them into the marketing copy.

Honest limitations

No claim of complete network discovery comparable to DigiCert sensors or Keyfactor orchestrators.
No claim that we replace an existing enterprise CLM.
Unsupported targets remain manual. That is the product, not a temporary gap we hide.
Production public issuance follows operator ACME policy and your CA credentials.
Private PKI is available and secondary. Do not buy this as “the new corporate root.”

Related docs, tools and academy

Questions enterprise security and platform teams actually ask

How do we find certificates we did not issue here?

Import a hostname or PEM, use panel/cloud discovery where a connector exists, and watch Certificate Transparency for unexpected public names. That builds an inventory of observed certificates. It is not the same as a network sensor grid that scans every internal port. Name the endpoints you care about; do not ask the product to invent a map of an unannounced Class-B.

Are vendor outage statistics a reason to buy?

Treat them as vendor-sponsored evidence of a common failure mode, not as a census of your estate. Keyfactor’s 2025 Wakefield survey reported 86% of respondents had at least one certificate-related outage in the prior year, and only 17% claimed complete real-time visibility. DigiCert’s 2026 Omdia-commissioned research reported 34% had a complete current view. Use the numbers to brief leadership; use your own discovery to brief operations.

When do 47-day certificates become mandatory?

Publicly trusted TLS subscriber certificates issued on or after 15 March 2029 must not exceed 47 days. That date is in the CA/Browser Forum Baseline Requirements §6.3.2. Certificates are not limited to 47 days today. The in-force maximum from 15 March 2026 is 200 days; from 15 March 2027 it is 100 days. Existing leaves keep their original notAfter. Plan automation now; do not tell auditors you are “already on 47-day certs” unless you chose that lifetime yourself.

Can we run public TLS and private PKI side by side?

Yes as separate product surfaces. Public DV/OV issuance follows CA/Browser Forum rules and public trust stores. Private PKI is a different trust store for mTLS and internal names. Do not mix them casually (a private root will not make Chrome happy on a public site). The operating model is the same: inventory, owner, expiry, deploy path, exception list.

How does role-based access work?

Organizations have owner, admin, developer and viewer. API keys are scoped with abilities (domains, certificates, webhooks, integrations). Viewers should not download platform-generated private keys. Scale, Business and Enterprise can require SSO and use SCIM for joiner/leaver under Organization → Security.

What if we cannot automate a vendor appliance?

Keep it in inventory with an owner, a next-expiry date, a documented install path and Action Required when renewal produces a PEM nobody installed. That exception list is the mature state — not a hole you hide because a sales deck said “100% automated.”

Do you replace Keyfactor or DigiCert Trust Lifecycle Manager?

Not as a drop-in for agent/sensor estates and deep private-PKI operations. This product is an API-first lifecycle layer: issue, inventory, webhook, deploy where connectors exist, monitor named endpoints. Enterprises that already run a CLM still use a REST issuance/inventory plane for the applications they build. Enterprises that do not should not expect a sensor fabric we do not ship.

Can we keep using more than one public CA?

Yes. Connect the CA accounts you already pay for. CAA records on your zones must allow the issuers you pick. Routing is chosen per order; we do not swap issuer mid-challenge. If a name must stay on a specific commercial issuer for procurement, put that constraint on the certificate record so an emergency renewal does not silently move it to Let’s Encrypt.

How do we evidence changes for audit?

Every mutating API call can write an audit event: who issued, renewed, revoked, or downloaded a key. Webhook deliveries are recorded. That is operational evidence. It is not a SOC 2 report — we do not publish a SOC 2 or ISO 27001 claim on this page.

What should we automate first?

Names that terminate customer traffic and have a connector or an ACME-capable target. Then the public sites still on calendars. Then vendor appliances as monitored exceptions. The 47-day readiness checklist on this page is the order of operations, not a shopping list.

Does discovery mean you store our private keys?

No. Watching a hostname’s presented certificate, or importing a PEM leaf, does not require the private key. Platform-generated keys exist only when you asked the API to generate them. CSR mode never transmits the key.

Find the names you are willing to be paged for

Inventory first. Automate the path you terminate. Keep every other certificate on an exception list with an owner.

Start free Monitor unmanaged certificates

Sources and fact-check

Time-sensitive claims on this page were checked on 2026-09-20. Validity dates follow the CA/Browser Forum TLS Baseline Requirements — not a vendor blog.

fact_checked_at=2026-09-20 · solution=enterprise