Free certs are great until they aren't
Friday afternoon. Production certificate expired because someone forgot to set up auto-renewal on a new subdomain. No big deal, right? Just issue a new one through Let's Encrypt. Except you already issued 50 certificates for that domain this week during that migration project. And now you're locked out for 7 days.
Your options are: wait a week, or explain to the CEO why the customer portal is down because you saved $200 on certificates.
I've watched this exact scenario play out at three different companies. Not variations of it. The exact scenario. Friday deploys and Let's Encrypt rate limits have a special relationship.
The rate limits nobody reads until it's too late
Let's Encrypt publishes their rate limits clearly. Nobody reads them until they hit one. Here's what actually matters:
50 certificates per registered domain per week. Sounds like plenty. Then you remember that "registered domain" means example.com, not api.example.com. Every subdomain cert counts against the same bucket. That staging environment with 30 microservices, each with its own cert? Yeah, that's 30 of your 50.
5 duplicate certificates per week. Reissued the same cert because certbot threw a weird error and you weren't sure if it worked? Congrats, you burned one of five. Did it four more times because ops was panicking? You're done for the week on that specific certificate.
300 new orders per account per 3 hours. Most people never hit this. Unless you're doing something clever with automation that goes sideways.
# Check how many certs you've issued recently
# Let's Encrypt doesn't give you a dashboard for this
# You have to check Certificate Transparency logs
curl -s "https://crt.sh/?q=%.example.com&output=json" | \
jq '[.[] | select(.not_before > "2026-03-11")] | length'
# If this number is approaching 50, slow downThe staging environment trap is brutal. Development teams spin up preview environments, each one gets a cert, nobody tracks the total. By Wednesday you've used 40 certificates. Thursday someone needs to add a new production subdomain. Good luck.
When commercial CAs actually make sense
"Just use Let's Encrypt" has become the default answer. Usually it's correct. But there are situations where paying for certificates is the obviously right choice, and people still argue against it for ideological reasons.
High-stakes environments where downtime costs real money. If your site being down for 4 hours costs more than $500, maybe the $300/year DigiCert cert with phone support and instant reissuance is worth it. Math isn't hard here.
Wildcard certificates for large subdomain counts. Let's Encrypt supports wildcards. But if you have 200 subdomains and something goes wrong with renewal, a single commercial wildcard cert means one renewal to fix instead of 200. Yes, wildcards have their own problems. Sometimes the tradeoff works out.
Extended Validation for specific compliance requirements. EV certs are mostly theater. The green bar is gone. But some enterprise contracts and compliance frameworks still require them. Fighting that battle costs more than the certificate.
Environments where ACME automation is genuinely hard. Legacy systems. Weird network topologies where the DNS challenge can't work and HTTP-01 requires firewall changes that take 6 weeks to approve. Internal PKI that needs to integrate with stuff that only speaks PKCS#12. Sometimes throwing money at the problem is faster than engineering around it.
The hybrid approach most teams actually use
Here's what works in practice: Let's Encrypt for everything that can easily automate renewal, commercial certs for the handful of critical things that can't fail.
# Production critical: commercial wildcard
*.example.com - DigiCert, 2 year validity, auto-renewal alerts
# Everything else: Let's Encrypt with cert-manager
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: staging-wildcard
spec:
secretName: staging-tls
issuerRef:
name: letsencrypt-staging # USE STAGING FOR TESTING
kind: ClusterIssuer
dnsNames:
- "*.staging.example.com"Notice the staging issuer comment. Use Let's Encrypt staging for testing. Always. The staging environment has much higher rate limits (30,000 certs per week). The only difference is browsers won't trust the certs, which is fine for testing renewal automation.
Most teams miss this. They test against production Let's Encrypt because "we need to verify it actually works" and burn through their rate limits before they even go live.
The 90-day validity problem is real
Let's Encrypt certs expire in 90 days. Commercial certs used to be 3 years, then 2 years, now 1 year max (thanks, Apple). 90 days is still significantly more operational overhead.
"But automation handles it." Yes. When it works.
Certbot cron jobs get deleted during server migrations. Kubernetes cert-manager gets uninstalled when someone is "cleaning up" the cluster. DNS credentials rotate and nobody updates the ACME client config. The automation that was working for 8 months silently fails, and you find out when the cert expires.
With 90-day certs, you have maybe 30 days of buffer if you renew at 60 days remaining (the default). With a 1-year cert, you have months to notice the monitoring alert before anything bad happens. Neither is "right," they're different risk profiles.
// A pattern that saves people: certificate inventory
// Know what you have before it surprises you
const criticalCerts = [
{ domain: 'api.example.com', ca: 'digicert', expires: '2027-01-15' },
{ domain: 'app.example.com', ca: 'letsencrypt', expires: '2026-05-20' },
// ...
];
// Check daily, alert at 30 days, panic at 14
criticalCerts.forEach(cert => {
const daysLeft = daysBetween(new Date(), new Date(cert.expires));
if (daysLeft < 14) sendPagerDuty(cert);
else if (daysLeft < 30) sendSlack(cert);
});Whatever CA you use, monitor expiration independently of the renewal process. The renewal is supposed to happen. The monitoring catches when it doesn't.
DigiCert vs Sectigo vs the others
If you decide commercial certs make sense for some of your infrastructure, which CA?
DigiCert: Expensive. Generally reliable. Their support is actual humans who understand PKI. If you're spending enterprise money and need enterprise support, this is the boring safe choice. Owned by Thoma Bravo now, which usually means cost cutting eventually, but so far nothing has visibly degraded.
Sectigo (formerly Comodo): Cheaper. Hit or miss on support. Their control panel feels like it was designed in 2008 because it was. But the certs work fine. For "we just need a cert and don't want to think about it" use cases, they're adequate.
GlobalSign: Solid middle ground. Good API if you're doing automation anyway. Less aggressive pricing than DigiCert, more coherent experience than Sectigo.
AWS Certificate Manager: Free for AWS services. Can't export private keys. If everything is behind ALB or CloudFront, this is free and automatic. The moment you need the cert on an EC2 instance or anywhere outside AWS, useless.
Honestly? For most use cases the specific CA doesn't matter that much. All major CAs are trusted by all major browsers. Pick based on price, API quality if you need automation, and support quality if you expect to actually use support.
The actual decision framework
Use Let's Encrypt when:
- You can fully automate renewal (most cases)
- Hitting rate limits won't cause an emergency (test with staging first)
- You don't have compliance requirements mandating specific CA types
- The cost of cert-related downtime is acceptable relative to engineering time saved
Consider commercial CAs when:
- Rate limits are a realistic concern for your scale
- You need SLA-backed support for certificate issues
- Automation is genuinely difficult in your environment
- Compliance or contracts require it
- A single long-lived wildcard is operationally simpler than managing many short-lived certs
Most teams should use Let's Encrypt for 90% of their certs and keep one commercial wildcard for the stuff that absolutely cannot fail. That's the pragmatic answer. Not exciting, but it works.
Don't learn this the hard way
Whatever you choose, test it before you need it. Issue a cert on a random subdomain. Verify renewal works. Check your rate limit headroom. Do this on a Tuesday, not during a Friday deploy when everything is on fire.
The engineers who get burned by Let's Encrypt rate limits aren't stupid. They just never tested the failure modes because everything worked fine for months. Then it didn't, and they had no backup plan.
Free is good. Free with a backup plan is better.