Let’s Encrypt + Certbot vs. Enterprise CLM: Where the Line Is

---

Let’s Encrypt changed the internet. Before 2015, TLS certificates cost money, required manual validation, and expired annually. Today, Let’s Encrypt issues over 400 million active certificates — more than every commercial CA combined. It is, by any measure, one of the most impactful security projects ever built.

Certbot, the ACME client that automates Let’s Encrypt certificate lifecycle, works remarkably well for its designed purpose: automated TLS certificates for web servers. Install it. Run it. Forget about it. Certificates renew every 60-90 days without human intervention.

So why would anyone pay for certificate lifecycle management when Let’s Encrypt is free and automated?

Because Let’s Encrypt solves one problem — public web server TLS — and enterprise certificate needs extend far beyond that single use case. This post maps exactly where Let’s Encrypt excels, where it cannot help, and how to architect an environment that uses both appropriately.

---

What Let’s Encrypt Handles Perfectly

Let’s Encrypt, via ACME (RFC 8555), is the ideal solution for these specific use cases:

Use Case	Why It’s Perfect	Configuration
Public website TLS	DV is sufficient, auto-renewal works	certbot + web server plugin
API endpoint TLS	Same as websites — public, DV adequate	certbot + DNS plugin
Staging/dev environments	Free, automated, identical to production	certbot (any method)
Load balancer termination (self-managed)	HAProxy/Nginx with certbot hooks	certbot + deploy hooks
CDN origin certificates	Origin needs valid TLS, DV is fine	certbot on origin server
Container ingress (Kubernetes)	cert-manager with Let’s Encrypt issuer	cert-manager + ACME
Personal/small business websites	Free, no maintenance required	Hosting provider integration
Wildcard certificates (public)	DNS-01 challenge supports wildcards	certbot + DNS plugin

What Makes Let’s Encrypt Excellent

Attribute	Value
Cost	$0 (forever)
Automation protocol	ACME (RFC 8555) — open standard
Certificate lifetime	90 days
Renewal window	30 days before expiry (certbot default)
Validation methods	HTTP-01, DNS-01, TLS-ALPN-01
Issuance speed	Seconds (fully automated)
Rate limits	50 certs per registered domain per week
Wildcard support	Yes (DNS-01 only)
Multi-domain (SAN)	Up to 100 SANs per certificate
Transparency	All certificates logged to CT
Trust	Trusted by all major browsers and OS trust stores
Uptime	99.99%+ availability

Certbot: The Standard ACME Client

# Install certbot (Ubuntu/Debian)
sudo apt install certbot python3-certbot-nginx

# Obtain certificate for Nginx-served site
sudo certbot --nginx -d example.com -d www.example.com

# Obtain wildcard certificate via DNS challenge
sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d "*.example.com" -d example.com

# Verify auto-renewal is configured
sudo systemctl status certbot.timer

# Test renewal (dry run)
sudo certbot renew --dry-run

This works. For public web server TLS, this is genuinely the best solution available — better than commercial CAs for most use cases because it’s automated by default and costs nothing.

---

What Let’s Encrypt Cannot Handle

Here’s where the “just use Let’s Encrypt” argument breaks down:

1. Internal PKI Certificates

Let’s Encrypt validates domain ownership over the public internet. It cannot issue certificates for:

• server.corp.internal
• app.staging.local
• dc01.ad.company.com (internal AD domain)
• 192.168.1.50 (IP-based certificates)
• Any hostname not publicly resolvable

Internal services, Active Directory infrastructure, and private networks require a private CA.

2. Client Authentication Certificates (mTLS)

Let’s Encrypt issues server certificates only. It does not issue client certificates for:

• Mutual TLS between microservices
• User authentication via certificate
• Device identity certificates
• VPN client certificates
• 802.1X network authentication

Client certificates require a CA that can validate the entity (user, device, service) — not just domain ownership.

3. Code Signing Certificates

Let’s Encrypt does not issue code signing certificates. Code signing requires:

• Organization validation (OV) — proving the entity is a real organization
• Extended validation (EV) — additional legal entity verification
• Hardware-protected keys (HSM or hardware token)
• Different key usage extensions (digitalSignature, not keyEncipherment)

4. S/MIME Email Certificates

Email encryption and signing certificates require identity validation beyond domain control. Let’s Encrypt cannot issue S/MIME certificates because:

• S/MIME requires email address validation and binding to a named individual
• Let’s Encrypt validates domain ownership, not individual identity
• Email certificates need emailProtection key usage

5. VPN Certificates (Server and Client)

VPN infrastructure (IPsec, OpenVPN, WireGuard with certificates) requires:

• Server certificates for VPN concentrators (possible with LE for internet-facing)
• Client certificates for user authentication (impossible with LE)
• Certificate profiles specific to VPN use (custom extensions)
• Revocation that VPN appliances check reliably

6. Document Signing Certificates

Digital signatures on PDFs, contracts, and legal documents require:

• Identity-bound certificates (tied to a person or organization)
• Qualification under eIDAS (EU) or equivalent regulations
• Trust anchoring in Adobe Approved Trust List (AATL) or equivalent
• Long-term validation (signatures must verify for years/decades)

---

Rate Limits and Enterprise Implications

Let’s Encrypt imposes rate limits that matter at enterprise scale:

Limit Type	Value	Impact
Certificates per Registered Domain	50 per week	Large organizations with many subdomains may hit this
Duplicate Certificates	5 per week	Reissuance after misconfiguration is limited
Failed Validations	5 per account, per hostname, per hour	Misconfigured automation can lock you out
New Registrations (accounts)	10 per IP per 3 hours	Automated tooling at scale needs planning
Pending Authorizations	300 per account	Large batch operations may queue
New Orders	300 per account per 3 hours	High-volume issuance needs rate management

When Rate Limits Become a Problem

Scenario	Why It Hits Limits	Impact
Large-scale reissuance after key rotation	50/week per domain limit	Takes weeks to rotate all certs
Dynamic environments (auto-scaling with unique hostnames)	New certificates per instance	Hits duplicate or domain limits
Disaster recovery (recreating all certs)	All certs needed simultaneously	Cannot issue fast enough
Blue-green deployments with unique cert per deployment	Duplicate certificate limit	Deployment blocked by rate limit
Multi-tenant SaaS (custom domains per customer)	Each customer domain counts against limits	Onboarding blocked after 50 customers/week

Mitigations

• Use wildcard certificates where possible (one cert covers all subdomains)
• Implement certificate caching/reuse in automation pipelines
• Distribute across multiple registered domains if possible
• Contact Let’s Encrypt for rate limit increases (available for large deployments)
• Consider a commercial CA for high-volume scenarios with no rate limits

---

The DV-Only Limitation

Let’s Encrypt issues only Domain Validated (DV) certificates. This matters for enterprise trust requirements:

Validation Level	What It Proves	Who Issues It	Enterprise Use Case
DV (Domain Validated)	You control the domain	Let’s Encrypt, ZeroSSL, any ACME CA	Web servers, APIs, internal
OV (Organization Validated)	Domain control + real organization	DigiCert, Sectigo, Entrust	B2B portals, partner-facing APIs
EV (Extended Validation)	Domain + organization + legal entity	DigiCert, Sectigo, Entrust	Financial services, payment pages

When DV Is Insufficient

Requirement	Why DV Fails	What’s Needed
Regulatory mandate for OV/EV	Some regulations specify validation level	OV or EV from commercial CA
Customer contract requirements	Enterprise customers demand OV/EV for integrations	OV minimum
Internal security policy	Organization’s PKI policy mandates OV for production	OV from approved CA
Code signing	DV doesn’t verify organization identity	OV/EV code signing cert
Qualified electronic signatures (EU)	eIDAS requires qualified certificates	Qualified trust service provider
Payment card industry	PCI best practices recommend OV/EV for payment pages	OV or EV

When DV Is Completely Fine

For 80%+ of web server TLS use cases, DV provides identical cryptographic security to OV/EV. The encryption is the same. The key exchange is the same. The only difference is what the certificate asserts about the owner’s identity.

If your users are accessing your service via a known URL (they typed it or clicked a trusted link), DV is sufficient. The certificate proves you control that domain, which is all TLS needs to establish a secure channel.

---

Coverage Comparison: 25+ Use Cases

Use Case	Let’s Encrypt	Enterprise CLM	Notes
Public website TLS	✓	✓	LE is ideal
Public API TLS	✓	✓	LE is ideal
CDN/edge TLS	✓	✓	Most CDNs integrate LE natively
Kubernetes ingress TLS	✓ (cert-manager)	✓	cert-manager + LE issuer
Load balancer TLS (cloud)	✓ (cloud provider)	✓	ACM/equivalent preferred for cloud LBs
Staging/dev environments	✓	✓	LE is ideal (free, automated)
Internal web applications	✗	✓	Internal hostnames need private CA
Microservice mTLS	✗	✓	Client certs needed
Active Directory/LDAPS	✗	✓	AD CS or private CA required
VPN server certificates	Partial (if internet-facing)	✓	Depends on hostname accessibility
VPN client certificates	✗	✓	Client identity certs needed
Wi-Fi 802.1X (RADIUS)	✗	✓	NPS/RADIUS server certs from private CA
Device identity certificates	✗	✓	Managed device enrollment
Code signing	✗	✓	OV/EV required
Document signing	✗	✓	Identity-bound certificate
S/MIME email encryption	✗	✓	Email address validation needed
Database TLS (internal)	✗	✓	Internal CA typically
IoT device certificates	✗	✓	Device provisioning protocol needed
SSH certificates	✗	✓	SSH CA (different protocol entirely)
Windows smartcard login	✗	✓	AD CS user certificates
SCEP/EST enrollment	✗	✓	Mobile device management
OCSP responder certificates	✗	✓	CA-issued for OCSP signing
Timestamp authority certificates	✗	✓	Specialized CA issuance
OV/EV public certificates	✗	✓	Commercial CA required
Qualified electronic signatures	✗	✓	QTSP required (eIDAS)
IP-based certificates	✗	✓	LE doesn’t issue for IP addresses

Let’s Encrypt coverage: 6 of 25 use cases (24%)

For organizations with only public web servers and APIs, Let’s Encrypt covers 100% of needs. For enterprises with internal infrastructure, the coverage drops dramatically.

---

When Certbot Is the Right Tool

Certbot is the right choice when:

Condition	Why Certbot Works
All servers run Linux/Unix with shell access	Certbot designed for this
Certificates serve public domains only	ACME validation works over internet
Team is comfortable with CLI tooling	Certbot is CLI-first
Budget is zero	Free certificates, free client
Certificate count is under 50	Manual certbot management is feasible
Web server is Nginx or Apache	Certbot has native plugins
DNS provider has ACME plugin	Wildcard and DNS validation automated
No compliance reporting needed	Certbot doesn’t generate audit reports
Single team manages all certs	No RBAC or delegation needed

Certbot Configuration Best Practices

# /etc/letsencrypt/cli.ini — Global certbot configuration
# Recommended settings for enterprise use

# Use RSA 4096 for compatibility, or ECDSA for performance
key-type = ecdsa
elliptic-curve = secp384r1

# Ensure OCSP stapling-friendly renewal
preferred-challenges = dns
dns-propagation-seconds = 60

# Safety settings
must-staple = false
hsts = false
redirect = false

# Notification
email = security-team@example.com

# Renewal settings (applied to all managed certificates)
renew-hook = /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh

# /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh
#!/bin/bash
# Executed after successful renewal

set -euo pipefail

# Reload web servers
systemctl reload nginx 2>/dev/null || true
systemctl reload apache2 2>/dev/null || true
systemctl reload haproxy 2>/dev/null || true

# Verify the new certificate is serving
for domain in "$RENEWED_DOMAINS"; do
  if ! openssl s_client -servername "$domain" -connect "$domain:443" \
    </dev/null 2>/dev/null | openssl x509 -noout -checkend 86400; then
    echo "WARNING: $domain not serving renewed certificate" >&2
    # Alert via webhook
    curl -s -X POST "${ALERT_WEBHOOK}" \
      -d "{\"text\":\"Certificate deployment failed for $domain\"}"
  fi
done

echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) Renewal deploy hook completed for: $RENEWED_DOMAINS" \
  >> /var/log/certbot-deploy.log

---

When You’ve Outgrown Let’s Encrypt

Signals that your organization needs more than certbot:

Signal	What It Indicates
You have internal services needing TLS that aren’t publicly accessible	Need private CA
You need client certificates for mTLS or VPN	Need identity certificates
Multiple teams need certificate visibility without server access	Need centralized platform
Auditors ask for certificate inventory and lifecycle evidence	Need CLM reporting
You’ve had outages from certbot renewal failures nobody noticed	Need monitoring platform
You’re managing certbot on 20+ servers with different configurations	Need centralization
You need code signing or document signing certificates	Need commercial CA relationship
Your compliance framework requires certificate inventory (PCI, ISO)	Need CLM platform
Developer teams request certificates without involving ops	Need self-service portal
You manage certificates across AWS, Azure, and on-premises	Need cross-environment visibility

---

ACME for Internal CAs: The Best of Both Worlds

The ACME protocol isn’t exclusive to Let’s Encrypt. Several internal CA solutions support ACME, bringing Let’s Encrypt-style automation to internal certificates:

step-ca (Smallstep)

Open-source certificate authority with native ACME support:

# Initialize step-ca
step ca init --name "Internal CA" --dns ca.internal.example.com \
  --address :443 --provisioner admin

# Enable ACME provisioner
step ca provisioner add acme --type ACME

# Clients can now use standard ACME clients against your internal CA
sudo certbot certonly --server https://ca.internal.example.com/acme/acme/directory \
  -d app.internal.example.com

Feature	step-ca
ACME support	Full (RFC 8555)
Certificate types	Server, client, device
Deployment	Single binary, Docker, Kubernetes
Key storage	Software, YubiKey, Cloud KMS, PKCS#11 HSM
Cost	Open source (free)
Short-lived certificates	Yes (down to 5-minute lifetimes)
mTLS support	Yes (client certificate issuance)
SSH certificates	Yes (in addition to X.509)

HashiCorp Vault PKI Secrets Engine

Enterprise secret management with built-in PKI:

# Enable PKI secrets engine
vault secrets enable pki
vault secrets tune -max-lease-ttl=87600h pki

# Generate root CA
vault write pki/root/generate/internal \
  common_name="Internal Root CA" \
  ttl=87600h

# Configure intermediate CA
vault secrets enable -path=pki_int pki
vault write pki_int/intermediate/generate/internal \
  common_name="Internal Intermediate CA"

# Issue certificate via API
vault write pki_int/issue/webserver \
  common_name="app.internal.example.com" \
  ttl="720h"

Vault doesn’t natively support ACME, but third-party bridges exist (e.g., vault-acme-proxy).

AD CS with ACME Bridge

For organizations committed to AD CS as their internal CA, ACME bridge solutions exist:

Solution	Approach	Maturity
Keyfactor ACME Proxy	Bridges ACME requests to AD CS	Production
Certbot AD CS plugin (community)	Direct AD CS enrollment via certbot	Experimental
win-acme (WACS)	Windows ACME client for AD CS integration	Production
step-ca as RA (registration authority)	step-ca fronts AD CS as ACME endpoint	Production

EJBCA (PrimeKey/Keyfactor)

Enterprise-grade CA with full ACME support:

# EJBCA ACME endpoint configuration
# Certificates issued via standard ACME protocol against EJBCA CA
certbot certonly --server https://ejbca.internal.example.com/acme/directory \
  --preferred-challenges http \
  -d internal-app.example.com

---

Architecture Patterns: Using Both Let’s Encrypt and Internal CA

Pattern 1: Split by Network Boundary

Public Network (Internet-facing):
  └── Let's Encrypt (via certbot/cert-manager)
      ├── Public websites
      ├── Public APIs
      ├── CDN origins
      └── Customer-facing portals

Private Network (Internal):
  └── Internal CA (step-ca/Vault/AD CS)
      ├── Microservice mTLS
      ├── Database TLS
      ├── Internal web apps
      ├── VPN certificates
      └── Device certificates

Certificate Lifecycle Management Platform:
  └── Unified visibility across both
      ├── Discovery (both public + internal)
      ├── Alerting (all certificates)
      ├── Compliance reporting
      └── Ownership tracking

Pattern 2: ACME Everywhere (Internal + External)

ACME Protocol (RFC 8555) as universal interface:

External certificates:
  └── Let's Encrypt (public ACME server)
      └── Certbot/cert-manager as ACME client

Internal certificates:
  └── step-ca or EJBCA (private ACME server)
      └── Same certbot/cert-manager as ACME client

Benefits:
  - Uniform automation tooling
  - Same renewal mechanics for all certificates
  - Reduced operational complexity
  - Team learns one protocol, applies everywhere

Pattern 3: CLM Platform as Orchestration Layer

CLM Platform (central control):
  ├── Manages Let's Encrypt certificates
  │     └── Via built-in ACME client
  ├── Manages commercial CA certificates
  │     └── Via DigiCert/Sectigo API
  ├── Manages AD CS certificates
  │     └── Via ADCS integration
  ├── Manages cloud certificates
  │     └── Via AWS ACM / Azure APIs
  └── Provides:
        ├── Single inventory
        ├── Unified alerting
        ├── Compliance reporting
        └── Policy enforcement across all CAs

---

Cost Comparison: Let’s Encrypt vs. Enterprise CLM

Cost Category	Let’s Encrypt + Certbot	Enterprise CLM Platform
Certificate issuance (public)	$0	$0 (LE) or commercial CA cost
Certificate issuance (internal)	N/A (can’t do internal)	Internal CA cost (varies)
Client software	$0 (certbot)	Included in platform
Server/infrastructure	Existing servers	SaaS or dedicated servers
Annual license	$0	$30,000 - $200,000+
Monitoring/alerting	DIY (scripts)	Built-in
Compliance reporting	DIY (manual)	Built-in
Discovery	DIY (scripts)	Built-in
Multi-CA management	N/A (single CA)	Built-in
Audit trail	Log files	Immutable audit log
Total (public web only)	$0	$30,000 - $200,000
Total (full enterprise needs)	$0 + gaps unfilled	$30,000 - $200,000 (complete)

The comparison isn’t “free vs. expensive.” It’s “solves 20% of the problem for free” vs. “solves 100% of the problem for a cost.” If your problem is only 20% (public web TLS), Let’s Encrypt wins absolutely. If your problem is 100% (all enterprise certificates), Let’s Encrypt is one component of the solution, not the solution itself.

---

Enterprise Implications of Let’s Encrypt Rate Limits

For large organizations, rate limits create operational constraints:

Scenario: Major Key Rotation Event

After a potential key compromise, an organization needs to reissue all 200 certificates for *.example.com:

Approach	Time to Complete	Constraint
Let’s Encrypt (50/week limit)	4 weeks	Rate limited
Commercial CA (DigiCert)	Hours	No meaningful rate limit
Internal CA (step-ca)	Minutes	No rate limit
CLM platform (multi-CA)	Hours	Routes around any single CA limit

Scenario: Disaster Recovery

Organization’s primary region fails. All certificates need reissuance in the DR region:

• With Let’s Encrypt only: Constrained to 50/week per domain. Full recovery for 300 certs takes 6 weeks.
• With commercial CA: Immediate reissuance via API. Full recovery in hours.
• With CLM platform: Orchestrated reissuance across multiple CAs, prioritized by business criticality.

Scenario: Multi-tenant SaaS Onboarding

SaaS platform where each customer gets a custom domain certificate:

Customers Onboarding per Week	Let’s Encrypt Feasibility	Alternative Needed
1-10	✓ Fine	No
10-30	✓ Manageable	No
30-50	⚠ Approaching limit	Plan for it
50+	✗ Rate limited	Commercial CA or multi-domain SAN strategy

---

Certbot Failure Modes and Enterprise Impact

Certbot is reliable — but it’s not monitored by default. When it fails, it fails silently unless you’ve built alerting:

Failure Mode	Cause	Detection Without Monitoring	Enterprise Impact
Renewal failed (DNS propagation)	DNS challenge response not visible	None until cert expires	Outage 60-90 days later
Renewal failed (port 80 blocked)	Firewall change, HTTP-01 blocked	None until cert expires	Outage 60-90 days later
Renewal succeeded but deploy hook failed	Service didn’t reload	Users see old cert until restart	Security gap (old cert, old key)
Certbot package broken after OS upgrade	Python dependency issue	Errors in cron log (nobody reads)	All certs expire simultaneously
Let’s Encrypt intermediate change	Chain update requires certbot update	Clients reject incomplete chain	Partial outage (older clients)
DNS credentials expired	API key for DNS-01 no longer valid	Renewal silently fails	Outage after expiry
Server decommissioned without cert removal	Cert exists but server gone	Monitoring shows expiry alert, nobody acts	Noise in monitoring
Rate limit hit during legitimate renewal	Too many recent issuances	Renewal postponed, may expire	Outage if buffer insufficient

The Monitoring Gap

Certbot doesn’t include alerting infrastructure. A CLM platform does. The difference:

Certbot alone: Certificate expires → service breaks → users report error → team investigates → finds expired cert → manually renews → 2-4 hour outage.

Certbot + CLM monitoring: CLM detects certbot renewal failure → alerts via Slack/PagerDuty → team fixes root cause → certificate renews → zero outage.

The CLM platform doesn’t replace certbot — it watches certbot and catches failures before they become outages.

---

Decision Framework: When to Use What

Your Situation	Recommended Approach
5 web servers, one team, no compliance	Certbot only (sufficient)
20 web servers + 5 internal services	Certbot (public) + step-ca (internal)
50 servers + compliance requirements	Certbot + CLM platform for monitoring
100+ servers + internal PKI + multiple teams	CLM platform orchestrating all CAs including LE
Enterprise (500+ certs, regulated, hybrid)	CLM platform as primary, LE as one CA source
Enterprise with OV/EV requirements	CLM platform + commercial CA + LE for DV needs

---

The Honest Summary

Dimension	Let’s Encrypt + Certbot	Enterprise CLM
Best at	Free, automated public web TLS	Unified lifecycle management across all cert types
Worst at	Everything except public web TLS	Cost (expensive for simple environments)
Right size	1-50 public certificates, technical team	500+ certificates, multiple types, compliance needs
Wrong size	Enterprise with internal PKI, compliance, multi-team	Startup with 10 web server certs
Relationship	Component (the CA for public DV)	Platform (manages all CAs including LE)

Let’s Encrypt is not in competition with CLM platforms. It’s a CA — one of potentially several that a CLM platform manages. The question isn’t “Let’s Encrypt OR enterprise CLM.” It’s “Let’s Encrypt alone, or Let’s Encrypt as part of a managed ecosystem.”

For organizations whose certificate needs are exclusively public web TLS — Let’s Encrypt + certbot is the correct, complete answer. No additional tooling required.

For organizations whose certificate needs extend beyond public web TLS — and that’s most enterprises — Let’s Encrypt remains the right choice for public DV certificates, wrapped inside a CLM platform that also handles internal PKI, commercial CA relationships, compliance reporting, and cross-environment visibility.

---

About QCecuring

QCecuring integrates with Let’s Encrypt and ACME-enabled CAs alongside commercial CAs, AD CS, and cloud provider certificate services. We don’t replace certbot — we give you visibility into whether certbot is doing its job, alongside every other certificate in your environment.

Use the right tool for each job. Let us connect them all.

See your full certificate landscape →

---

Tags: Let’s Encrypt, Certbot, ACME, RFC 8555, Certificate Lifecycle Management, CLM, Internal PKI, Enterprise Security, cert-manager, step-ca, HashiCorp Vault, AD CS, DV Certificates, TLS Automation, Certificate Authority, PKI