Kokil Thapa - Professional Web Developer in Nepal
Freelancer Web Developer in Nepal with 15+ Years of Experience

Kokil Thapa is an experienced full-stack web developer focused on building fast, secure, and scalable web applications. He helps businesses and individuals create SEO-friendly, user-focused digital platforms designed for long-term growth.

Certificate Lifecycle Management

By Kokil Thapa | Last reviewed: September 2026

Certificate Lifecycle Management is the operational discipline of tracking every TLS certificate from issuance through renewal, deployment, monitoring, and revocation. A single expired cert can take down HTTPS, break API clients, and trigger browser warnings that cost real leads. On production stacks I maintain—Laravel apps on Ubuntu with Apache or Nginx—SSL/TLS certificates are not a one-time install task. They are living credentials with hard expiry dates. This guide walks through a practical CLM workflow you can run on a small team without enterprise budget.

What is Certificate Lifecycle Management and why does it matter?

Certificate Lifecycle Management (CLM) covers six phases: discovery, issuance, deployment, monitoring, renewal, and revocation or decommission. Each phase has owners, tools, and failure modes. Skip one phase and you inherit silent risk.

TLS certificates bind a public key to a domain or service identity. Browsers and API clients trust them through a certificate chain of trust anchored at a public CA. That trust expires when the leaf certificate expires—often in 90 days with Let's Encrypt, or up to 398 days with some commercial CAs under current CA/Browser Forum baseline requirements.

On legal-tech portals and booking systems I've shipped, HTTPS is baseline hygiene. Clients upload documents. Payment callbacks depend on TLS. A cert outage during filing season is not a cosmetic bug. It is lost revenue and damaged trust.

Certificate Lifecycle Management PhasesDiscoverInventory all certsIssueCSR and CA signDeployWeb server bindMonitorExpiry alertsRenewBefore expiry dateRevokeKey compromiseRetireDecommission hostContinuous loop — not a one-time installMap each phase to an owner, tool, and runbook
Certificate Lifecycle Management spans discovery through retirement — each phase needs a defined owner and tool.

CLM differs from simply installing Certbot once. Installation is a single event. Lifecycle management is ongoing governance. You know what certs exist, who owns them, when they expire, and how they get replaced without a midnight SSH session.

Business impact of poor CLM

  • Browser warnings that block form submissions and checkout flows
  • Mobile apps with certificate pinning that hard-fail on unexpected rotation
  • Webhook delivery failures when partner APIs reject expired TLS
  • SEO signals hurt when crawlers cannot fetch HTTPS pages reliably
  • Compliance gaps when audit trails for key usage are missing

For background on PKI foundations, read the PKI and certificate management basics primer first. It explains roots, intermediates, and trust stores that CLM builds on.

How do you build a certificate inventory before renewal failures hit production?

Discovery is the first CLM phase most teams skip. They remember the main domain cert on the web server. They forget the mail server, staging subdomain, internal API gateway, and the old wildcard on a decommissioned load balancer.

Start with an asset list tied to DNS. Every A, AAAA, and CNAME record is a candidate endpoint. Scan from outside and inside your network. External scans catch public-facing certs. Internal scans find mTLS, database TLS, and service mesh sidecars.

Manual discovery commands

Query a live endpoint and inspect the presented chain:

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

# Scan common ports on a host
for port in 443 8443 9443; do
  echo "=== Port $port ==="
  echo | openssl s_client -connect example.com:$port -servername example.com 2>/dev/null \
    | openssl x509 -noout -subject -enddate
done

Parse certificate fields systematically. The anatomy of an X.509 certificate article explains Subject, SAN, Key Usage, and Extended Key Usage fields you should capture in inventory.

Minimum inventory fields

  1. Common Name and Subject Alternative Names (SANs)
  2. Issuer and certificate type (DV, OV, EV, wildcard, mTLS)
  3. Serial number and fingerprint (SHA-256)
  4. Not Before and Not After dates
  5. Private key location and storage (filesystem, HSM, vault)
  6. Deployment target (Nginx vhost, Apache VirtualHost, load balancer)
  7. Renewal method (ACME, manual CSR, vendor portal)
  8. Business owner and technical owner

Store this in a spreadsheet if you have fewer than twenty certs. Move to a dedicated tracker or CMDB once you pass that threshold. On shared EC2 hosts where I run multiple Laravel sites via Deployer 7, one missed staging cert has caused production deploy anxiety because CI health checks hit the wrong hostname.

Include non-web certificates. SMTP STARTTLS, Redis TLS, MySQL 9.7 encrypted connections, and PostgreSQL 18 client certs all belong in the same inventory. A Linux system administration engagement often starts with this audit because nobody documented what was installed over the years.

How do you automate certificate issuance and renewal on Linux servers?

Manual CSR generation and email reminders do not scale. ACME automation is the default CLM approach for public-facing HTTPS in 2026. The Let's Encrypt client options documentation lists maintained ACME clients; Certbot remains the most common on Ubuntu.

Certbot with Nginx or Apache on Ubuntu

Install Certbot and obtain a certificate with automatic web server configuration:

sudo apt update
sudo apt install certbot python3-certbot-nginx

sudo certbot --nginx -d example.com -d www.example.com \
  --non-interactive --agree-tos -m admin@example.com

sudo certbot renew --dry-run

Certbot installs a systemd timer or cron job for renewal. Verify it exists:

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

After renewal, the web server must reload to pick up the new cert. Certbot deploy hooks handle this:

sudo certbot renew --deploy-hook "systemctl reload nginx"

On Apache + PHP-FPM stacks—the setup I use daily—the reload pattern is identical. PHP-FPM does not need a restart for cert rotation. Nginx or Apache must reload to bind the new files. See the step-by-step install SSL certificates on Ubuntu guide for vhost-specific paths.

ACME Renewal FlowCertbot timerACME clientHTTP-01 challengeLet's Encrypt CANew cert files/etc/letsencrypt/live/Deploy hookreload nginxVerify with openssl s_clientConfirm new Not After date on live port 443
ACME automation in Certificate Lifecycle Management — Certbot renews, deploy hooks reload the web server, then you verify the live chain.

Wildcard and DNS-01 challenges

HTTP-01 works for single-host certs when port 80 is reachable. Wildcard certs require DNS-01 validation. You create a _acme-challenge TXT record through your DNS provider API. Certbot plugins exist for Cloudflare, Route53, and others.

sudo apt install python3-certbot-dns-cloudflare
sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d example.com -d *.example.com

Protect API token files with mode 600. Never commit credentials to Git. Treat DNS API tokens as CI/CD secrets with rotation policy.

Multi-server and load-balanced deployments

ACME proves domain control, not server count. If three Nginx nodes terminate TLS, all three need the renewed cert. Options include:

  • Shared storage for /etc/letsencrypt mounted on each node
  • Post-renewal sync via rsync triggered by deploy hook
  • Terminate TLS at a load balancer and renew only there
  • Store certs in HashiCorp Vault or cloud KMS and pull on boot

On zero-downtime Deployer releases, symlink swaps do not replace cert files in /etc/letsencrypt. Keep cert paths outside the release directory. Reference them from Nginx site configs in /etc/nginx/sites-enabled.

Which certificate lifecycle management tools should you use in 2026?

Tool choice depends on cert count, environment complexity, and budget. Small agencies running Laravel and WordPress 7.1 sites rarely need full enterprise CLM on day one. They need reliable automation plus expiry alerting.

Tool / approachBest forStrengthsWeaknesses
Certbot + cron/timer1–20 Linux VPS hostsFree, simple, Let's Encrypt nativeNo central dashboard, weak multi-team visibility
acme.shDNS-01, embedded devices, custom deploy hooksLightweight, many DNS APIsSelf-managed inventory and alerting
Smallstep / step-caInternal mTLS, dev/staging PKIPrivate CA, short-lived internal certsNot a replacement for public web PKI alone
HashiCorp Vault PKIMulti-service, dynamic certsAPI-driven issuance, audit logOperational overhead, needs HA setup
Enterprise CLM (DigiCert, Sectigo, Venafi)500+ certs, compliance auditsDiscovery, workflow, policy enforcementCost (often USD 5,000+/year, ~Rs 670,000+)
Cloud-native (AWS ACM, Azure Key Vault)Cloud LB–terminated TLSAuto-renewal when DNS validatedVendor lock-in, limited export for self-hosted

For Nepal-based businesses on budget VPS hosting, Certbot plus a monitoring script covers most cases. Move to Vault or cloud PKI when you run microservices with mTLS or need centralized audit trails. The automate certificate rotation guide covers rotation patterns beyond simple web TLS.

Manual vs Automated CLMManual CLM• Spreadsheet expiry tracking• Email reminders ignored• Weekend outage on expiry• Unknown shadow certs• No revocation runbookHigh riskAutomated CLM• ACME auto-renewal• Central inventory scan• 30/7-day alert pipeline• Deploy hooks on renew• Documented revoke stepsLow risk
Automated Certificate Lifecycle Management replaces spreadsheet tracking with ACME renewal, inventory scans, and alert pipelines.

Projects like Mijar Law Associates and Notary Nepal depend on always-on HTTPS for document uploads and lead forms. Automated renewal is cheaper than one weekend emergency.

How do you monitor SSL certificate expiry and prevent outages?

Automation fails. DNS breaks. Deploy hooks stop running after a server migration. Monitoring is your safety net, not a substitute for renewal automation.

Build a layered alert strategy

  1. Local check: Cron script parsing certbot certificates or openssl output
  2. External check: Third-party or self-hosted monitor hitting public URLs daily
  3. Application check: Health endpoint verifying TLS handshakes on dependent services
  4. Log watch: Alert on Nginx SSL handshake errors spiking after rotation

Simple bash monitor you can cron every morning:

#!/bin/bash
DOMAIN="example.com"
DAYS_WARN=30
EXPIRY=$(echo | openssl s_client -connect ${DOMAIN}:443 -servername ${DOMAIN} 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))

if [ "$DAYS_LEFT" -lt "$DAYS_WARN" ]; then
  echo "WARNING: ${DOMAIN} cert expires in ${DAYS_LEFT} days (${EXPIRY})"
fi

Send output to email, Slack webhook, or your existing uptime monitor. Alert at 30 days and again at 7 days. Escalate at 3 days to a human with shell access.

Expiry Monitoring PipelineDaily scanCron + opensslInventory DBDays until expiryAlert rules30 / 7 / 3 daysEmail / SlackAuto-renew retryEscalate to on-call engineer if renewal fails twiceCross-check with external uptime monitor
Certificate Lifecycle Management monitoring — scan daily, alert at threshold windows, and escalate failed renewals before expiry.

Validate chain completeness, not just expiry. A cert with missing intermediate breaks Android clients but works in desktop Chrome. Use SSL Labs or test from multiple user agents after every rotation. The testing and optimization service includes post-deploy TLS verification on client sites.

Technical SEO also depends on clean HTTPS. Crawlers that hit certificate errors drop pages from indexation. Treat TLS health as part of your search engine optimization checklist, not only infra.

How do you handle certificate revocation and key compromise in CLM?

Renewal gets most attention. Revocation is the phase teams discover only after a breach or key leak. If a private key is exposed—committed to Git, copied to the wrong server, or stolen—you must revoke the certificate and reissue with a new key pair.

Understand the difference between CRL and OCSP revocation methods. Public CAs publish revocation status. Browsers check OCSP stapling when configured. Revocation is not instant worldwide, but it is still required for compliance and incident response.

Revocation runbook steps

  1. Identify affected serial numbers from inventory
  2. Revoke via CA portal or certbot revoke --cert-path /path/to/cert.pem
  3. Generate new key pair—never reuse a compromised private key
  4. Issue and deploy replacement certificate
  5. Audit logs for unauthorized use during exposure window
  6. Update inventory with new serial, fingerprint, and dates

For Let's Encrypt, revocation is documented in the Certbot revocation guide. Act fast. Automated scanners hunt for leaked keys within hours of a public Git push.

Avoid certificate pinning unless you have a rotation plan. Pinning without backup pins has caused major app outages when CAs rotate intermediates.

Decommissioning hosts and domains

When you retire a subdomain or shut down a staging server, remove its cert from inventory and revoke if the key still exists on disk. Old VPS snapshots often contain valid private keys for domains you no longer control. Destroy snapshots or revoke certs before decommission.

Domain migrations need explicit CLM planning. The website migration process should include re-issuance on the new host, DNS cutover validation, and a 48-hour monitoring window on the new chain.

What does production-grade Certificate Lifecycle Management look like on real projects?

On sister sites sharing Deployer 7 + GitLab CI on EC2—legal portals like Court Marriage In Nepal—CLM is boring by design. Certbot timers renew LE certs. Nginx reload hooks fire after renewal. A weekly cron emails days-to-expiry for every vhost. Inventory lives in a shared doc updated at onboarding.

For Laravel 13.x apps behind Nginx, force HTTPS in middleware and set secure session cookies. Certificate rotation does not require application deploys when TLS terminates at the web server. API integrations using mTLS need coordinated rotation on both sides.

Store strong passwords for keystore exports using a proper generator—never reuse admin passwords across services. A password generator helps, but production key material belongs in a vault with access logging.

When clients ask for managed hosting, CLM is part of domain registration and hosting and ongoing support and maintenance. Expiry should never be the client's problem to discover via Twitter complaints.

Enterprise Laravel builds with many subdomains benefit from enterprise application development practices: environment-specific cert policies, staging certs that mirror production SANs, and CI gates that fail if test endpoints present expired chains.

JSON config exports from inventory tools can be validated in pipeline with a JSON formatter before loading into monitoring. Small quality checks prevent garbage alert thresholds.

Key Takeaways

  • Certificate Lifecycle Management covers discovery, issuance, deployment, monitoring, renewal, revocation, and retirement—not just initial Certbot setup.
  • Build a complete inventory with SANs, serial numbers, owners, and renewal method before automating anything.
  • Use ACME (Certbot or acme.sh) with deploy hooks and verify with certbot renew --dry-run after every server change.
  • Layer monitoring with 30-day and 7-day alerts independent of renewal automation.
  • Maintain a revocation runbook for key compromise and revoke decommissioned certs instead of leaving them on disk.
  • Match tool tier to cert count: Certbot for small VPS fleets, Vault or enterprise CLM when mTLS and audit trails are mandatory.

People Also Ask

How often should TLS certificates be renewed?

Public CA certificates should renew automatically well before expiry—typically at 30 days remaining for 90-day Let's Encrypt certs. Commercial one-year certs should enter renewal workflow at 60 days. Never wait until the final week unless you enjoy emergency maintenance.

What is the difference between certificate management and certificate lifecycle management?

Certificate management often means issuing and installing certs. Certificate Lifecycle Management adds inventory, ongoing monitoring, automated renewal, revocation procedures, and decommissioning. CLM is the full operational system; cert management is one phase inside it.

Can Let's Encrypt certificates be used for production eCommerce sites?

Yes. Let's Encrypt DV certificates provide the same TLS encryption as paid DV certs. Trust comes from the CA being in browser root stores, not from price. WooCommerce 11.1 and custom Laravel carts use LE certs in production worldwide. OV or EV may be a business branding choice, not a technical encryption requirement.

What happens if an SSL certificate expires?

Browsers display security warnings and block form submission on most pages. API clients with strict TLS validation fail connections. Search crawlers may drop HTTPS URLs from indexation. Payment gateway callbacks can fail silently. Recovery requires issuing a new cert, deploying it, reloading the web server, and verifying the live chain.

Build Certificate Lifecycle Management before expiry finds you first

Certificate Lifecycle Management is insurance against the most preventable production outage on the web. Inventory what you have, automate renewal with ACME, monitor expiry independently, and document revocation before you need it under pressure. On stacks from WordPress to Laravel 12/13.x, the pattern is the same: discover, automate, verify, repeat.

If your sites still rely on calendar reminders or an undocumented Certbot install from two years ago, treat CLM as the next infrastructure task—not a someday project. For help auditing TLS across your hosting fleet or automating renewal on Ubuntu production servers, contact us or review our web development services. Read related guides on Azure Key Vault certificates and multi-cloud secrets management when you outgrow single-server Certbot.

Frequently Asked Questions

CLM is the end-to-end process of discovering, issuing, deploying, monitoring, renewing, and revoking digital certificates before expiry or compromise causes HTTPS outages.

The six phases are discovery, issuance, deployment, monitoring, renewal, and revocation or decommission. Each phase needs defined owners, tools, and failure modes. Skip discovery and you miss staging subdomains and mail server certs. Skip monitoring and automated renewal failures go unnoticed until browsers show warnings. On production Laravel stacks I maintain, treating CLM as ongoing governance—not a one-time Certbot install—is what prevents midnight SSH emergencies.

Expired certs trigger browser warnings that block form submissions and checkout flows. Mobile apps with certificate pinning hard-fail on unexpected rotation. Partner webhook APIs reject expired TLS, breaking payment callbacks. Search crawlers that cannot fetch HTTPS reliably lose indexation signals. Compliance audits also flag missing key-usage trails. On legal-tech portals where clients upload documents, a cert outage during filing season is lost revenue, not a cosmetic bug.

Start with DNS: every A, AAAA, and CNAME record is a candidate endpoint. Scan externally for public-facing certs and internally for mTLS, database TLS, and service mesh sidecars. Query live endpoints with openssl s_client against ports 443, 8443, and 9443. Include non-web certs—SMTP STARTTLS, Redis TLS, MySQL encrypted connections. On shared EC2 hosts running multiple Laravel sites via Deployer 7, one missed staging cert has caused production deploy anxiety because CI health checks hit the wrong hostname.

Capture Common Name and Subject Alternative Names, issuer and certificate type such as DV, OV, EV, wildcard, or mTLS, serial number and SHA-256 fingerprint, Not Before and Not After dates, private key storage location, deployment target like Nginx vhost or Apache VirtualHost, renewal method whether ACME or manual CSR, and both business and technical owners. A spreadsheet works for fewer than twenty certs; move to a dedicated tracker or CMDB once you exceed that threshold.

Install Certbot with the Nginx or Apache plugin on Ubuntu, obtain certs with certbot --nginx or certbot --apache, and verify the systemd timer or cron job exists via systemctl list-timers. Run certbot renew --dry-run after setup. Configure a deploy hook to reload the web server after renewal, for example systemctl reload nginx. PHP-FPM does not need a restart for cert rotation—only Nginx or Apache must reload to bind the new certificate files.

HTTP-01 works for single-host certs when port 80 is reachable from the public internet. Wildcard certificates require DNS-01 validation because ACME must prove control over the entire domain namespace, not just one hostname. You create a _acme-challenge TXT record through your DNS provider API using Certbot plugins for Cloudflare, Route53, or similar. Protect API token credential files with mode 600 and never commit them to Git—treat DNS API tokens as CI/CD secrets with a rotation policy.

ACME proves domain control, not server count. If three Nginx nodes terminate TLS, all three need the renewed cert. Options include shared storage for /etc/letsencrypt mounted on each node, post-renewal sync via rsync triggered by a deploy hook, terminating TLS at a load balancer and renewing only there, or storing certs in HashiCorp Vault or cloud KMS and pulling on boot. On Deployer zero-downtime releases, symlink swaps do not replace cert files—keep cert paths outside the release directory and reference them from Nginx site configs.

For one to twenty Linux VPS hosts, Certbot plus a cron timer or systemd job covers most Nepal-based businesses on budget VPS hosting. Add a monitoring script for expiry alerting rather than jumping to enterprise platforms. acme.sh suits DNS-01, embedded devices, and custom deploy hooks. HashiCorp Vault PKI fits multi-service dynamic cert needs but adds operational overhead. Enterprise CLM from DigiCert, Sectigo, or Venafi targets five hundred plus certs with compliance audits—overkill for typical agency WordPress 7.1 and Laravel sites on day one.

Enterprise CLM platforms often start around USD 5,000 per year, roughly Rs 670,000+, before implementation and training costs.

Build a layered strategy: local cron scripts parsing certbot certificates or openssl output, external monitors hitting public URLs daily, application health endpoints verifying TLS handshakes, and log watches for Nginx SSL handshake errors after rotation. A simple bash script can check days remaining via openssl s_client and email or Slack results. Validate chain completeness too—a cert with a missing intermediate breaks Android clients while desktop Chrome still works. Use SSL Labs or test from multiple user agents after every rotation.

Alert at 30 days and again at 7 days before expiry. Escalate to a human with shell access at 3 days remaining.

Installing Certbot is a single event that obtains a certificate. Certificate Lifecycle Management is ongoing governance—you know what certs exist, who owns them, when they expire, and how they get replaced without emergency intervention. CLM includes discovery of forgotten endpoints, inventory tracking, monitoring when automation fails, coordinated multi-server deployment, revocation after key compromise, and decommissioning retired domains. Automation handles renewal, but monitoring remains the safety net when DNS breaks or deploy hooks stop after a server migration.

Revoke the affected certificate immediately and reissue with a new key pair—never reuse a compromised private key. Identify affected serial numbers from your inventory, revoke via the CA portal or certbot revoke, then issue and deploy a replacement certificate. Audit logs for unauthorized use during the exposure window and update inventory with the new serial, fingerprint, and dates. Automated scanners hunt leaked keys within hours of a public Git push, so act fast. For Let's Encrypt, follow the documented Certbot revocation workflow.

On sister sites sharing Deployer 7 and GitLab CI on EC2—legal portals like Court Marriage In Nepal—CLM is boring by design. Certbot timers renew Let's Encrypt certs, Nginx reload hooks fire after renewal, and a weekly cron emails days-to-expiry for every vhost. Inventory lives in a shared doc updated at onboarding. For Laravel 13.x apps behind Nginx, force HTTPS in middleware and set secure session cookies. Certificate rotation does not require application deploys when TLS terminates at the web server. Expiry should never reach the client via social media complaints.

Share this article

0 Comments

Leave a comment

Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.

Quick Contact Options
Choose how you want to connect me: