DEV Community: nine

Certificate Renewal: The Engineering Guide to Renewals at Scale

nine — Mon, 06 Apr 2026 10:21:41 +0000

Every team has a certificate renewal story that ends with a 2am page and a scramble through a wiki page last updated in 2019. The process sounds simple until you're managing certificates across three cloud providers, two CAs, and a Kubernetes cluster that somebody set up before they left the company. Certificate renewal at scale isn't a single operation. It's a category of operations, each with its own failure modes, and the industry is about to make all of them more frequent.

This guide covers what actually happens during renewal, how to automate it, and what breaks when you're responsible for more than a handful of certs. If you manage fewer than ten certificates, the vendor docs will serve you fine. If you manage fifty or more, keep reading.

What certificate renewal actually involves

Certificate renewal replaces an expiring TLS certificate with a new one for the same identity, but the mechanics vary significantly depending on the CA, cert type, and whether you reuse keys. Industry data indicates that roughly 60% of certificate-related outages trace back to renewal process failures, not initial provisioning. Understanding the distinction between renewal, reissuance, and rekeying prevents the confusion that leads to those outages.

TLS/SSL certificate renewal vs. reissuance

Renewal, reissuance, and rekeying are three distinct operations, though most CAs use the terms loosely:

SSL certificate renewal extends coverage with a new certificate and new validity period. The CA may or may not require a new CSR.
Certificate reissuance generates a new certificate mid-term, typically because you need to change SANs or your key was compromised.
Certificate rekeying specifically means generating a new key pair and getting a cert issued against it.

The practical difference matters when you're automating. If your pipeline assumes renewal never changes the key, you'll break certificate pinning configurations. If it assumes the SANs stay identical, you'll miss cases where a reissuance added a subdomain that your monitoring doesn't cover.

Certificate types and their renewal workflows

DV, OV, and EV certificates each follow different renewal workflows due to their validation requirements:

Certificate type	Automation level	Validation required	Typical renewal time
DV certs	Fully automatable via ACME	Domain control only (HTTP-01, DNS-01, or email)	Minutes
OV/EV certs	Partially automatable	Organization validation with human review (typically annual)	Hours to days
Internal/mTLS certs	Fully automatable with your own CA	Controlled by your step-ca or Active Directory CA policy	Minutes

DV certificates renew with domain validation only, which is why ACME automates them end to end. OV and EV certificates require organization validation steps involving human review, making full automation impossible. Internal PKI and mTLS certificates follow whatever policy your CA enforces — cert-manager or step-ca can automate these, but you own the root of trust and the rotation logic.

Why certificates expire (and why 90-day lifetimes are winning)

Certificates expire because revocation doesn't work reliably enough to be the only safety net. CRL distribution is slow, OCSP has availability problems, and according to Netcraft's measurements, OCSP stapling fails silently in roughly 8% of configurations. Short certificate lifetimes reduce the window during which a compromised key remains trusted. This isn't theoretical — it's the actual security model the industry has converged on.

The security case for short-lived certificates

Let's Encrypt set the standard at 90 days in 2015 and proved that short-lived certificates work at internet scale, now protecting over 360 million domains. The security logic is straightforward:

A 90-day certificate compromised on day one gives an attacker at most 90 days of exposure
A one-year certificate compromised on day one gives an attacker up to 365 days of exposure
Revocation mechanisms (CRL, OCSP) frequently fail to close that window in practice

If a key is compromised and revocation fails — which it often does — the exposure window is bounded only by the certificate's remaining validity period.

CA/Browser Forum changes and what's coming

The CA/Browser Forum passed ballot SC-081 in 2025, setting a phased reduction in maximum TLS certificate validity:

Effective date	Maximum certificate validity
Before March 2026	398 days
March 2026	200 days
March 2027	100 days
March 2029	47 days

The operational impact is significant. If you're renewing certificates manually today, you're doing it once a year per cert. By 2029, you'll be doing it roughly eight times per year per cert. For a fleet of 200 certificates, that's 1,600 renewal events annually. The math makes the case for automated certificate renewal better than any blog post can.

Manual certificate renewal: step by step

Manual TLS certificate renewal follows four steps: generate a CSR, submit it to your CA with validation, install the new cert, and verify the chain. The entire process takes 15–60 minutes per certificate depending on the validation type. Multiply that by your cert count to understand why this section exists mainly so you know what to automate.

Step 1: Generate a CSR

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/CN=example.com/O=Your Org/L=City/ST=State/C=US"

If you're renewing with the same key (not recommended, but sometimes required by policy), drop -newkey rsa:2048 and use -key existing.key instead. Key reuse saves you from updating pinning configs but extends the exposure window if that key was ever compromised.

Step 2: Submit to your CA and validate

Upload the CSR to your CA's portal or API. Validation methods differ by cert type:

HTTP-01: Place a file on your webserver at a CA-specified path
DNS-01: Create a TXT record in your domain's DNS
Email: Respond to a verification email sent to a domain admin address
OV/EV: All of the above plus phone verification and document review

Step 3: Install the renewed certificate

The installation step is where most manual renewals fail. The cert file alone isn't enough — you need the full chain in the correct order.

# Combine cert and chain for Nginx
cat example.com.crt intermediate.crt > fullchain.pem

# Reload Nginx without downtime
nginx -t && systemctl reload nginx

For AWS ALB, upload via the CLI: aws acm import-certificate. For Kubernetes Ingress, update the TLS secret. The critical gotcha: forgetting to restart or reload the service after installing the new cert. After monitoring thousands of renewal events, I've seen teams update the file on disk and close the ticket, only to get paged when the old cert still in memory expires.

Step 4: Verify the chain and test

# Check cert dates and chain
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -issuer

# Verify the full chain
openssl verify -CAfile ca-bundle.crt fullchain.pem

Test from outside your network. CDNs and load balancers cache certificates, and a successful local test doesn't mean your edge nodes picked up the change.

Automated certificate renewal with ACME

The ACME protocol (RFC 8555) automates the entire certificate lifecycle: key generation, domain validation, certificate issuance, and installation. According to Let's Encrypt's published data, over 300 million certificates are currently managed via ACME through Let's Encrypt alone. If you're still renewing DV certs manually, this section is your exit ramp.

How the ACME protocol works

ACME is a challenge-response protocol that automates certificate issuance in four steps:

Client contacts the CA and requests a certificate for a specific domain
CA issues a challenge (HTTP-01 or DNS-01) to prove domain control
Client completes the challenge and notifies the CA
CA validates and issues the signed certificate over HTTPS with JSON payloads

The client handles CSR generation internally, removing the manual step entirely.

Certbot, acme.sh, and alternatives

Choosing an ACME client depends on your environment:

ACME client	Language	Best for	Key advantage
Certbot	Python	Traditional VM deployments	Reference client with Nginx/Apache plugins
acme.sh	Shell	Minimal or containerized environments	Zero dependencies, supports 70+ DNS providers
lego	Go	CI/CD pipelines	Single binary, easy to embed
step-ca	Go	Internal PKI	ACME for private certificates, not just public

A working Certbot renewal with hooks:

certbot renew --deploy-hook "systemctl reload nginx" \
  --pre-hook "echo 'Starting renewal' | logger" \
  --post-hook "echo 'Renewal complete' | logger"

The certbot renew command checks all managed certs and renews those within 30 days of expiry. Add it to a daily cron and the process runs unattended.

DNS-01 vs HTTP-01 challenge tradeoffs

HTTP-01 is simpler but requires port 80 access on every server. DNS-01 works for wildcard certs and servers behind firewalls, but introduces DNS API dependencies. At scale, DNS-01 has specific pain points:

Rate limits: Cloudflare limits API requests to 1,200 per 5 minutes
Propagation delays: TXT record propagation can cause validation timeouts
Credential sprawl: Managing DNS API credentials for multiple providers across environments adds complexity

For a deeper look at protocol mechanics, see our ACME protocol guide.

Certificate renewal in Kubernetes and cloud environments

cert-manager is the de facto standard for Kubernetes certificate renewal, running in over 40% of Kubernetes clusters according to CNCF survey data. It watches Certificate resources and renews at 2/3 of the certificate's lifetime by default. Cloud providers offer their own auto-renewal for managed certificates, but each has different behaviors and silent failure modes.

cert-manager for Kubernetes

cert-manager creates Certificate resources backed by Issuers (namespace-scoped) or ClusterIssuers (cluster-wide). When a cert reaches the renewal window, cert-manager automatically:

Generates a new CSR
Completes the ACME challenge
Updates the Kubernetes Secret with the new certificate

The critical failure mode to watch for: if the Issuer's credentials expire or the DNS solver loses permissions, cert-manager logs errors but your certs silently age toward expiry. For the full setup, see our Kubernetes certificate renewal guide.

AWS ACM, GCP CAS, and Azure Key Vault auto-renewal

Provider	Service	Auto-renewal	Failure notification	Covers
AWS	ACM	Yes, for DNS-validated certs	CloudWatch event on failure	ALB, CloudFront, API Gateway
GCP	Certificate Manager	Yes, for Google-managed certs	Cloud Monitoring alert	Load Balancers
Azure	Key Vault	Yes, configurable at 80% lifetime	Event Grid notification	App Gateway, Front Door

The common trap: assuming "auto-renewal" means "never think about it." In practice, every provider has silent failure scenarios:

AWS ACM auto-renewal fails silently if the CNAME validation record gets deleted
Azure Key Vault won't renew if the cert policy doesn't match the issuer's requirements
GCP Certificate Manager requires the domain authorization to remain valid

Every cloud provider's auto-renewal has at least one scenario where it fails without an obvious alert.

Service mesh and mTLS certificate rotation

Istio and Linkerd handle mTLS certificate rotation for workload identities automatically, but the root CA and intermediate certs still require manual rotation. Istio's default root cert expires after 10 years, which sounds like someone else's problem until you realize your cluster is four years old and nobody documented the rotation procedure. Workload certificate rotation happens automatically; trust anchor rotation is a manual, high-risk operation.

Certificate renewal at scale: what breaks after 50 certs

Managing certificate renewal across a fleet means tracking expiration dates, CA relationships, and deployment targets for every cert in your certificate inventory. In our experience managing enterprise certificate estates, the average mid-market company has 15–20% more certificates than they think they do, and at least one will be a wildcard cert that somebody provisioned through a personal account three years ago.

Tracking expiration across multiple CAs and environments

The spreadsheet approach breaks down around 50 certificates. Beyond that threshold, you need programmatic discovery:

Prometheus blackbox exporter probes endpoints and exports probe_ssl_earliest_cert_expiry as a metric
Certificate Transparency logs via crt.sh provide a view of publicly issued certs for your domains
Network scanning catches certs on servers not exposed to external monitoring
CA API integration pulls renewal status directly from each certificate authority

Neither CT logs nor endpoint probing catches internal certs or certs sitting on servers that aren't exposed to your monitoring. For certificate monitoring that actually covers your full estate, you need a combination of all four approaches. This is the operational problem that motivated us to build CertPulse: the gap between "we have monitoring" and "we know about every cert."

Renewal failures you won't catch without monitoring

After monitoring certificate renewals across thousands of environments, these are the most common silent failure patterns:

Failure type	What happens	Why it's hard to detect
CDN cache masking	CDN serves cached cert after origin renewal fails	Everything looks fine until the CDN cache expires and clients see the expired cert
Intermediate chain rot	CA rotates intermediates; server still serves the old one	Android clients break first because they don't fetch intermediates automatically
Orphaned non-ACME certs	95% of certs auto-renew via Certbot; the five OV certs from a vendor portal three years ago do not	They're not in your automation inventory
DNS permission drift	ACME DNS-01 validation fails because someone tightened IAM policies	Renewal service silently lost write access to Route 53
Silent cert-manager failures	cert-manager logs `renewal failed` but no alert fires	Nobody configured alerting on CertificateRequest denied events

Building a renewal runbook

Your renewal runbook should answer three questions for every certificate in your fleet:

What's expiring? — Certificate identity, SANs, and expiration date
Who owns it? — Team, individual, and escalation path
What's the renewal method? — ACME automated, cloud managed, or manual with specific CA

Keep the runbook next to your incident response docs, not buried in a wiki. Include rollback procedures for the scenario where a renewed cert breaks clients.

Certificate renewal checklist

Step	Manual	ACME automated	Cloud managed
Pre-renewal
Inventory cert and confirm owner	Yes	Verify automation config	Verify auto-renewal enabled
Decide: new key or reuse	Yes	Client decides (default: new)	Provider decides
Check SAN list is current	Yes	Review Certbot config	Review ACM/Key Vault settings
During renewal
Generate CSR	`openssl req`	Automatic	Automatic
Complete validation	Manual DNS/HTTP/email	Automatic challenge	Automatic (if CNAME intact)
Install cert + full chain	Manual copy + reload	Deploy hook	Automatic propagation
Post-renewal
Verify chain externally	`openssl s_client`	Monitoring check	Endpoint probe
Confirm monitoring picks up new expiry	Update tracking	Auto-detected	CloudWatch/Event Grid
Document what changed	Update runbook	Commit config changes	Tag resource

FAQ

How far in advance should I renew a certificate?
Start renewal 30 days before expiry for manual renewals to leave room for validation delays and troubleshooting. Certbot defaults to renewing at 30 days remaining. cert-manager renews at 2/3 of the total lifetime — for 90-day certs, that means renewal happens around day 60.

Does certificate renewal generate a new private key?
It depends on your configuration. Certbot generates a new key by default on each renewal. Some CAs allow key reuse during renewal. Generating a new key is generally recommended because it limits the impact window if the previous key was compromised without your knowledge.

Will my site go down during certificate renewal?
No, not if you reload rather than restart your web server. Both Nginx and Apache support graceful reloads that swap the certificate without dropping active connections. The risk is in the gap between installing the cert and reloading the service — automate both steps together to eliminate it.

What happens if a certificate renewal fails silently?
The old certificate continues serving until it expires, then clients see ERR_CERT_DATE_INVALID or equivalent errors. If a CDN sits in front of your origin, the CDN's cached cert may mask the failure for hours or days. This is why external certificate expiration monitoring matters more than checking your ACME client's logs.

How do I handle certificate renewal for hundreds of certificates across multiple CAs?
You need three things: a complete inventory (discovered, not just documented), automated renewal for everything that supports it, and monitoring that alerts on expiry regardless of the renewal method. The ssl certificate management challenge isn't any single renewal — it's knowing that every renewal across your fleet actually succeeded.

SSL Certificate Checker: How to Audit, Debug, and Monitor Certificates at Scale

nine — Sun, 05 Apr 2026 10:28:58 +0000

An SSL certificate checker verifies whether a TLS certificate is valid, identifies why it might fail, and reveals what is about to break across different clients and environments. The most useful SSL checkers go beyond a simple pass/fail — they surface incomplete chains, expiring intermediates, SAN mismatches, and weak cipher suites that cause silent failures in non-browser clients like curl, Java, and Go. If you've ever been paged at 2am because an intermediate expired that Chrome gracefully handled but your partner's Java 8 client did not, you know the difference between "valid" and "actually working." This guide covers what an SSL certificate checker actually reveals, how to run checks from the command line, how to automate monitoring so you stop firefighting, and what changes when you're managing hundreds of certs across multiple clouds.

What an SSL Certificate Checker Actually Tells You

An SSL certificate checker returns certificate chain status, expiration dates, SAN coverage, protocol versions, OCSP stapling configuration, and key strength — each mapping directly to a specific production failure mode. Most tools dump this information without context, so here's what each field means operationally and what breaks when it's wrong.

Certificate chain validation

An incomplete certificate chain is the single most common TLS issue in production. When you check an SSL certificate chain, you verify that every link from the leaf cert to a trusted root is present and correctly ordered. According to Netcraft's 2024 SSL survey, roughly 5% of certificates observed on the public web have chain issues.

The reason incomplete chains are so insidious:

Chrome and Firefox (desktop) silently download missing intermediates via AIA (Authority Information Access) fetching
Safari also performs AIA fetching
Android < 7.0 hard fails with no AIA fetching
Java (default trust manager) hard fails
Go net/http hard fails
Python requests hard fails
curl (with system CA bundle) hard fails

Your monitoring says green. Then a non-browser client hits the same endpoint and gets a hard failure. A checker should show you exactly which certificates are served and whether the root is unnecessarily included (it adds bytes to every TLS handshake but isn't functionally required since clients already have it in their trust store).

Expiration and renewal status

An SSL certificate expiration check should return days-to-expiry as a number, not just a date string requiring mental math. A cert expiring in 29 days is fine if you have ACME automation. It's a crisis if it's a manually provisioned OV cert and the person who ordered it left the company. The operational question is renewal cadence relative to your automation posture.

Cipher suite and protocol negotiation

A good SSL checker tests which TLS versions and cipher suites the server actually accepts. Key findings to watch for:

TLS 1.0 negotiation indicates a compliance problem
CBC-mode ciphers create BEAST/Lucky13 risk that scanners flag
Qualys SSL Labs grades cipher configuration thoroughly via its web interface
nmap --script ssl-enum-ciphers and testssl.sh provide equivalent analysis with scriptable CLI output

SAN coverage and mismatches

The Subject Alternative Names (SANs) field determines which hostnames a certificate covers. A name mismatch error means a client requested api.example.com but the cert only covers example.com and www.example.com. Critical SAN facts that catch teams off guard:

A wildcard *.example.com does not cover example.com itself
A wildcard *.example.com does not cover *.sub.example.com
Post-2017, browsers ignore the CN field entirely and only check SANs, per CA/B Forum Baseline Requirements

For more on these tradeoffs, see our guide on wildcard vs. SAN certificates.

Field	What breaks when it's wrong	Severity
Chain completeness	Android, curl, Java, Go clients fail silently	High
Expiration	Total outage for all clients	Critical
SAN coverage	Specific hostname requests fail	High
Protocol version	Compliance scanners flag, old clients fail	Medium
OCSP stapling	Slower handshakes, potential soft-fail revocation gaps	Low-Medium
Key size	< 2048-bit RSA rejected by modern browsers	High

How to Check SSL Certificates from the Command Line

The fastest way to check an SSL certificate from the command line is with openssl s_client, which works on any Linux system without installing additional tools. CLI-based checks matter because half the environments where you actually need to debug TLS don't have a browser — bastion hosts, CI runners, air-gapped networks, containers running as non-root. According to the 2023 Stack Overflow survey, 87% of DevOps professionals use Linux as their primary work environment.

openssl s_client: the essential commands

Check SSL certificate details including the full chain:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

The -servername flag is critical — without it, you're not sending the SNI extension, and on any server hosting multiple certificates, you'll get the default cert instead of the one you're testing. This is the single most common reason people say "openssl shows a different cert than my browser."

Check SSL certificate expiration and get a machine-parseable date:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate

Dump the full certificate chain for inspection:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Verify against a specific CA bundle (useful for mutual TLS or private CAs):

openssl s_client -connect example.com:443 -servername example.com -CAfile /path/to/ca-bundle.crt

curl verbose output for quick checks

For a fast pass/fail with certificate context:

curl -vI https://example.com 2>&1 | grep -A6 'Server certificate'

This is faster to type than the openssl equivalent and gives you the essentials. Add --resolve example.com:443:10.0.0.1 to test a specific backend server behind a load balancer without DNS changes.

cfssl and certigo for structured JSON output

For scripting SSL checks, cfssl (from Cloudflare) and certigo (from Square) output JSON, which pipes cleanly into jq and downstream tooling:

cfssl certinfo -domain example.com | jq '.not_after'
certigo connect example.com:443 --json

Both tools handle edge cases better than raw openssl — certigo warns about SHA-1 intermediates and weak keys automatically without manual output parsing.

Automating SSL Certificate Checks in CI/CD and Monitoring

SSL certificate monitoring must be automated to scale beyond approximately 12 endpoints before someone inevitably misses a renewal. According to the Ponemon Institute's 2023 report, the average cost of a certificate-related outage is $300,000. Effective automation has three layers, and most teams only implement one.

Pre-deploy certificate validation in pipelines

A CI/CD pipeline deploying a TLS-terminating service should validate the certificate before the deploy completes. This catches the "someone uploaded a staging cert to production" class of errors. At minimum, the pipeline gate should verify:

The certificate isn't expired (and won't expire within 7 days)
The SANs match the expected hostnames for the target environment
The chain is complete, including all intermediates

This requires a 10-line shell script using the openssl commands above, or a single step using the step CLI from Smallstep. A pipeline gate that takes 2 seconds to run is the cheapest insurance against a $300,000 outage.

Prometheus ssl_exporter for ongoing monitoring

For continuous SSL certificate expiration monitoring, the Prometheus ssl_exporter is the standard open-source approach. It probes endpoints on a schedule and exposes ssl_cert_not_after as a gauge metric, feeding Grafana dashboards and Alertmanager rules. The Nagios check_ssl_cert plugin serves the same function for teams in the Nagios/Icinga ecosystem. For more on building a monitoring strategy, see our guide on TLS certificate expiration monitoring.

The important principle: SSL certificate monitoring should exist as a distinct concern, not bolted onto your HTTP health checks.

Alerting: time-based vs. error-based

Most teams get SSL alerting wrong by relying solely on time-based expiry warnings. The standard 30/14/7-day alert cadence creates alert fatigue when you have 500 certificates and 90-day Let's Encrypt certs renewing constantly. A better alerting model:

30 days before expiry: informational notification to the cert owner (not the on-call channel)
14 days before expiry: warning to the team channel if ACME renewal hasn't already succeeded
7 days before expiry: page the on-call, because something is actually broken
Immediately on error: alert on any invalid chain, expired cert, or handshake failure, regardless of time remaining

A cert that expires in 25 days is a task. A cert serving an incomplete chain right now is an incident. The distinction between time-based and error-based alerting is what separates functional monitoring from noise.

Common SSL Certificate Errors and How to Fix Them

Four root causes account for approximately 60% of SSL certificate errors encountered in production. Here's each one with diagnosis and fix.

Incomplete chain: the most common production issue

Symptom: site works in Chrome and Firefox on desktop, fails on Android < 7.0, fails in curl without --cacert, fails in Java with PKIX path building failed
Root cause: server sends the leaf certificate but omits one or more intermediates; desktop browsers mask this with AIA fetching, but non-browser clients don't
Fix: configure your web server to send the full chain using cat leaf.pem intermediate.pem > fullchain.pem
- nginx: set the ssl_certificate directive to the fullchain file
- Apache 2.4.8+: bundle intermediates with SSLCertificateFile
- Apache (older): use SSLCertificateChainFile separately

After monitoring thousands of endpoints, incomplete chains remain the most frequent issue because browser AIA fetching hides the problem from the people most likely to notice it.

Name mismatch and SAN coverage gaps

Symptom: clients report "ssl certificate not trusted" or ERR_CERT_COMMON_NAME_INVALID
Root cause: the certificate's SANs don't include the requested hostname; post-2017, browsers ignore the CN field entirely per CA/B Forum Baseline Requirements
Fix: reissue the cert with the correct SANs; audit your SAN list against your actual DNS records before ordering

Our guide on wildcard vs. SAN certificates covers the tradeoffs in detail.

Expired intermediates that don't show in browsers

Symptom: openssl shows an expired intermediate in the chain, but browsers continue working
Root cause: browsers cache a cross-signed version of the intermediate with a later expiry date; server-side clients use the chain file as served
Canonical example: the Let's Encrypt DST Root CA X3 expiry in September 2021 broke millions of API integrations while browsers continued working
Fix: update your chain file to use the current intermediate; monitor intermediate expiry dates, not just leaf cert dates

Certificate transparency logs can help you track when CAs issue new intermediates.

Mixed content and HSTS preload failures

After deploying a valid certificate, mixed content warnings and HSTS preload issues are the most common follow-up problems. These aren't certificate errors per se, but they appear in the same debugging session. HSTS preload list requirements:

Certificate must cover the bare domain and the www subdomain
max-age must be at least 31,536,000 seconds (1 year)

Managing SSL Certificates at Scale: What Changes After 50 Certs

Certificate lifecycle management breaks down after approximately 50 certificates, when individual checks stop being sufficient and fleet-level visibility becomes the core challenge. According to a 2024 Keyfactor survey, 62% of organizations don't know exactly how many certificates they have.

Certificate inventory and ownership tracking

You can't monitor what you don't know about. The first step is discovery — scanning networks, cloud provider APIs, and load balancer configs to build a certificate inventory. Every certificate needs:

An owner — a person or team responsible for renewal
A purpose — what service or endpoint it protects
A criticality level — what breaks if it expires

Without this, expiry alerts fire into a void where nobody knows whose problem it is.

Wildcard vs. SAN vs. per-service certs

Wildcard certificates reduce operational overhead (one cert covers all subdomains) but increase blast radius (one compromised key exposes everything)
Per-service certificates are more secure but multiply renewal burden
Recommended approach: use wildcards for internal services behind your perimeter; use per-service certs for anything internet-facing

See our full comparison for the details.

Multi-cloud certificate sprawl

Running services across AWS, GCP, and Azure means certificates live in three different systems, each with its own renewal mechanism and failure modes:

Cloud Provider	Certificate Service	Auto-Renewal Caveat
AWS	ACM (AWS Certificate Manager)	Only renews if DNS validation records still exist
GCP	GCP Managed Certificates	Doesn't support wildcards in all configurations
Azure	Azure Key Vault	Integrates with its own CA ecosystem

A unified view across providers is the core challenge of multi-cloud certificate management.

ACME automation and its limits

Let's Encrypt and ACME protocol automation solved certificate renewal for internet-facing HTTP services. However, ACME falls short in several scenarios:

Internal services unreachable by the CA
DNS validation in split-horizon DNS setups
Certificates requiring OV/EV validation for compliance
Environments where an ACME client can't run

Industry data indicates roughly 30% of certificates in a typical mid-market environment can't be automated with ACME alone.

Comparing SSL Certificate Checkers: Web Tools, CLIs, and Platforms

The best SSL certificate checker depends on your use case — one-off diagnosis, pipeline automation, or fleet-level management. Here's an honest breakdown by category.

Free web-based checkers — Qualys SSL Labs, DigiCert SSL Tools, SSL Shopper:

Best for one-off deep analysis; Qualys SSL Labs is the gold standard for grading
Limitation: no API access, no bulk checking, no alerting

Open-source CLI tools — openssl, testssl.sh, cfssl, certigo, step:

Best for pipeline integration and automation; full control, scriptable, works in restricted environments
Limitation: you build and maintain the monitoring infrastructure yourself

Certificate management platforms — CertPulse, Keyfactor, Venafi, Sectigo:

Best for fleet-level visibility, automated discovery, ownership tracking, and multi-cloud inventory
This is where the check ssl certificate command line approach stops scaling and a centralized system becomes necessary

Capability	Web Tools	CLI Tools	Platforms
Single cert check	Yes	Yes	Yes
Bulk/fleet checks	No	Scriptable	Native
API access	Rarely	N/A	Yes
Chain validation depth	Good	Full	Full
Expiry alerting	No	DIY	Built-in
Ownership tracking	No	No	Yes
Cost	Free	Free	Paid

Most teams end up using all three categories: web tools for quick one-off checks, CLI tools in their pipelines, and a platform when they realize the spreadsheet tracking 200 certs has three different "Owner" columns and none of them are current.

FAQ

What's the fastest way to check if an SSL certificate is expired?
Run openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate from any terminal. This returns the exact expiration date in one line without needing a browser or web tool.

Why does my SSL certificate work in Chrome but fail in curl or Java?
Chrome and Firefox use AIA (Authority Information Access) fetching to silently download missing intermediate certificates. Non-browser clients — including curl, Java, Go, and Python — do not perform AIA fetching. If your server isn't sending the complete certificate chain, browser users won't notice but API consumers will get hard failures. According to Netcraft's 2024 SSL survey, approximately 5% of public web certificates have chain issues that cause exactly this behavior.

How often should I check SSL certificates for expiration?
Check every 6–12 hours with automated monitoring. Alert at 30 days (informational to cert owner), 14 days (warning if auto-renewal hasn't fired), and 7 days (page the on-call). Separately, run error-based checks that alert immediately on invalid chains or handshake failures regardless of expiry date. According to the Ponemon Institute's 2023 report, certificate-related outages cost an average of $300,000, making frequent automated checks the cheapest insurance available.

Do wildcard SSL certificates cover the base domain?
No. A wildcard certificate for *.example.com covers sub.example.com and www.example.com, but it does not cover example.com itself. You need to include the bare domain as a separate SAN entry. Additionally, *.example.com does not cover multi-level subdomains like api.staging.example.com.

What's the difference between an SSL checker and a certificate management platform?
An SSL checker (like Qualys SSL Labs or openssl) tells you the current state of a single certificate. A certificate management platform (like CertPulse, Keyfactor, or Venafi) provides inventory, ownership tracking, automated discovery, expiry alerting, and renewal tracking across your entire certificate fleet. The first is a diagnostic tool; the second is an operational system. According to a 2024 Keyfactor survey, 62% of organizations don't know exactly how many certificates they have — a gap that checkers alone cannot close.