LFCE 104 🐧 Let's Encrypt — Concepts - KandZ

⏱️ Estimated read: 12 min | |

Let’s Encrypt is a free, automated, and open Certificate Authority (CA) that issues TLS certificates trusted by the major browsers and operating systems. The previous chapters covered OpenSSL and the manual certificate workflow; this chapter covers the CA that automates that workflow. The LFCE exam expects the candidate to configure the host-based and user-based security for a service, and Let’s Encrypt is the mechanism that makes the TLS practical at scale without the manual CSR signing and the certificate purchase.

Quick How-To Guides & Fast FixesNeed a quick fix or step-by-step solution? Browse our fast answers on HowTo.KandZ.me:

Operating Systems CLI →Dev Environment Languages →Web Network Tools →Security Accounts →Security Access Tech →Device Phone Basics →Social Messaging →Digital Files Media →

The CA is operated by the Internet Security Research Group (ISRG), and it issues the certificates through the ACME (Automated Certificate Management Environment) protocol . The ACME protocol is the standard that the client and the CA use to automate the domain validation, the certificate issuance, and the renewal. The client software runs on the web server, and it proves the control of the domain to the CA, requests the certificate, installs it, and renews it before the expiry. The result is the HTTPS that is configured once and maintained automatically.

Key point: The ACME protocol has two steps: the domain validation and the certificate issuance. In the validation, the client proves to the CA that it controls the domain, by provisioning either an HTTP resource under the /.well-known/acme-challenge/ path or a DNS TXT record . The validation cannot use the HTTPS, because the certificate is not yet issued; the CA mitigates the risk by performing the validation from the multiple network perspectives . In the issuance, the client sends a PKCS#10 CSR, and the CA returns the signed certificate.

Why Let’s Encrypt requires the ACME protocol

The manual-renewal problem.

The traditional CA requires the manual CSR generation, the payment, the identity documents, and the manual installation. The certificate is valid for a year or more, and the renewal is the manual repeat of the same process. The manual process is the reason the expired certificates are common, and the expired certificates are the reason the sites break. The ACME protocol automates the entire lifecycle, and the short validity period is the deliberate choice that forces the automation . The certificate is valid for 90 days, and the client renews it automatically before the expiry.

The cost problem.

The traditional certificates cost money, and the cost is the barrier for the small sites, the personal projects, and the internal services. Let’s Encrypt is free, which is the mechanism that makes the HTTPS the default rather than the premium feature. The CA is funded by the sponsors, and the certificates are the same technical quality as the paid ones.

The validation problem.

The CA must verify that the requester controls the domain before it issues the certificate. The ACME protocol defines the challenges that the client can complete to prove the control: the HTTP-01, the DNS-01, and the TLS-ALPN-01 . The HTTP-01 provisions a file on the web server, and the DNS-01 provisions a TXT record in the DNS zone. The challenge type is the mechanism that proves the control without the manual documents.

a. The domain validation and the challenges

The validation is the step where the client proves the domain control. The CA issues the challenges, and the client completes one of them.

# The HTTP-01 challenge file path
http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN>

The HTTP-01 challenge is the most common. The client puts a file with the token at the /.well-known/acme-challenge/<TOKEN> path, and the CA retrieves it from the multiple network perspectives . The challenge requires the port 80 to be open and reachable from the internet. The challenge cannot be used for the wildcard certificates.

The DNS-01 challenge provisions a TXT record at the _acme-challenge.<YOUR_DOMAIN> name . The challenge is harder to configure, but it works when the port 80 is blocked, and it is the only challenge that can issue the wildcard certificates. The challenge requires the DNS provider with the API for the automation.

# The DNS-01 challenge record
_acme-challenge.example.com. 300 IN TXT "<token-derived-value>"

The TLS-ALPN-01 challenge is the third type, and it uses the TLS handshake with the special ALPN value. The challenge is less common, and it is supported by the fewer clients.

b. The certificate issuance and the renewal

Once the domain is validated, the client sends the CSR, and the CA issues the certificate.

# The issued certificate files
/etc/letsencrypt/live/example.com/
├── cert.pem        # The server certificate only
├── chain.pem       # The intermediate certificates only
├── fullchain.pem   # The server certificate + the intermediates
└── privkey.pem     # The private key

The fullchain.pem is the file that the server should use, because it contains the server certificate and the intermediate chain. The privkey.pem is the private key, and it must be protected. The cert.pem and the chain.pem are the separate components, which are useful for the specific configurations .

The renewal is the repeat of the issuance: the client performs the domain validation again and requests the new certificate. The Certbot installs the systemd timer that attempts the renewal twice a day, and it renews the certificate when it is within the 30 days of the expiry . The renewal is the automatic, and the services that the Certbot plugin manages are reloaded automatically.

# Test the renewal without making changes
sudo certbot renew --dry-run

# Renew the certificate manually
sudo certbot renew

The --dry-run option performs the renewal process against the staging environment, which has the higher rate limits. The renew command renews the certificates that are within the renewal window.

c. The rate limits and the certificate lifetime

The Let’s Encrypt has the rate limits that prevent the abuse and the runaway automation.

# The key rate limits
- Duplicate Certificate: 5 per exact set of domain names per 168 hours
- Certificates per Registered Domain: 50 per week
- New Orders per Account: 300 per 3 hours

The Duplicate Certificate limit is the one that the retry loops hit. A script that reissues the certificate on every failure can exhaust the 5-per-week budget in the minutes . The --dry-run and the staging environment are the mechanisms that avoid the production rate limits during the testing.

The certificate lifetime is the 90 days in the current production, with the plan to shorten it to the 64 days in the February 2027 and the 45 days in the 2028 . The shorter lifetime is the deliberate choice that limits the exposure from the compromised keys, and it increases the importance of the automated renewal. The ACME Renewal Information (ARI) is the mechanism that the CA uses to suggest the renewal window, and the renewals that follow the ARI window are exempt from the rate limits .

Complete Example Session

# ============================================
# PART 1: INSTALL CERTBOT
# ============================================
sudo apt install certbot python3-certbot-nginx

# ============================================
# PART 2: OBTAIN THE CERTIFICATE (NGINX)
# ============================================
sudo certbot --nginx -d example.com -d www.example.com

# ============================================
# PART 3: CHECK THE ISSUED FILES
# ============================================
sudo ls /etc/letsencrypt/live/example.com/
# cert.pem, chain.pem, fullchain.pem, privkey.pem

# ============================================
# PART 4: VERIFY THE CERTIFICATE
# ============================================
sudo openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -dates

# ============================================
# PART 5: CHECK THE RENEWAL TIMER
# ============================================
sudo systemctl status certbot.timer

# ============================================
# PART 6: TEST THE RENEWAL
# ============================================
sudo certbot renew --dry-run

# ============================================
# PART 7: THE WEBROOT MODE
# ============================================
sudo certbot certonly --webroot -w /var/www/html -d example.com

# ============================================
# PART 8: THE DNS-01 CHALLENGE
# ============================================
sudo certbot certonly --manual --preferred-challenges dns -d example.com -d "*.example.com"

# ============================================
# PART 9: THE STAGING ENVIRONMENT
# ============================================
sudo certbot --staging -d example.com

# ============================================
# PART 10: THE REVOCATION
# ============================================
sudo certbot revoke --cert-path /etc/letsencrypt/live/example.com/cert.pem

The ten parts demonstrate the Let’s Encrypt lifecycle: the installation, the certificate issuance, the file check, the verification, the timer, the renewal test, the webroot mode, the DNS-01 challenge, the staging environment, and the revocation. The critical verification is Part 6: the --dry-run confirms that the renewal process works without consuming the production rate limits.

Quick Reference

The ACME Challenges

Challenge	Mechanism	Wildcard	Port 80
HTTP-01	The file at `/.well-known/acme-challenge/`	No	Required
DNS-01	The TXT record at `_acme-challenge.`	Yes	Not required
TLS-ALPN-01	The TLS handshake with the special ALPN	No	443

The Certificate Files

File	Content
`cert.pem`	The server certificate only
`chain.pem`	The intermediates only
`fullchain.pem`	The server certificate + the intermediates
`privkey.pem`	The private key

The Rate Limits

Limit	Threshold
Duplicate Certificate	5 per exact set of names per 168 hours
Certificates per Domain	50 per week
New Orders per Account	300 per 3 hours

The Commands

Command	Purpose
`certbot --nginx -d`	Obtain and install with nginx
`certbot certonly --webroot`	Obtain without the web server config
`certbot certonly --manual --preferred-challenges dns`	The DNS-01 challenge
`certbot renew --dry-run`	Test the renewal
`certbot revoke`	Revoke the certificate

Best Practices

✅ Do This:

# Use the --dry-run before the production renewal
certbot renew --dry-run                                        # ✅

# Use the staging environment for the testing
certbot --staging -d example.com                               # ✅

# Use the DNS-01 for the wildcard
certbot certonly --manual --preferred-challenges dns -d "*.example.com" # ✅

# Keep the port 80 open for the HTTP-01 renewal
# The HTTP-01 requires the port 80                                # ✅

# Use the fullchain.pem in the server config
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem # ✅

# Check the renewal timer
systemctl status certbot.timer                                 # ✅

❌ Don’t Do This:

# Retry the failed issuance in a loop
# The Duplicate Certificate limit is exhausted in the minutes   # ❌

# Use the HTTP-01 for the wildcard
# The HTTP-01 cannot issue the wildcard                          # ❌

# Ignore the rate limits
# The repeated failures block the issuance for the week         # ❌

# Use the manual DNS-01 in the production automation
# The manual challenge is not automatable                        # ❌

# Forget the renewal
# The 90-day certificate expires                                  # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
The HTTP-01 fails	The port 80 is blocked	Open the port 80 or use the DNS-01
The rate limit hit	The retry loop	Stop the retries, use `--dry-run`
The wildcard fails	The HTTP-01 used	Use the DNS-01
The certificate not renewed	The timer disabled	Enable the `certbot.timer`
The chain incomplete	The `cert.pem` used	Use the `fullchain.pem`

Real-World Examples

1. Obtain with nginx

certbot --nginx -d example.com

2. Obtain with webroot

certbot certonly --webroot -w /var/www/html -d example.com

3. The DNS-01 for the wildcard

certbot certonly --manual --preferred-challenges dns -d "*.example.com"

4. Test the renewal

certbot renew --dry-run

5. The staging

certbot --staging -d example.com

6. The certificate files

ls /etc/letsencrypt/live/example.com/

7. The verification

openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -dates

8. The revocation

certbot revoke --cert-path /etc/letsencrypt/live/example.com/cert.pem

9. The timer

systemctl status certbot.timer

10. The nginx config

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Visual

The ACME Flow

┌──────────────────────────────────────────────────────────────┐
│  THE TWO STEPS: VALIDATION AND ISSUANCE                      │
│                                                              │
│  Client                              CA                      │
│  ┌─────────┐                        ┌─────────┐              │
│  │         │── the challenge ──────▶│         │              │
│  │         │◀── the challenge ──────│         │              │
│  │         │── the completion ──────▶│         │              │
│  │         │                        │         │              │
│  │         │◀── the validation ─────│         │              │
│  │         │                        │         │              │
│  │         │── the CSR ─────────────▶│         │              │
│  │         │◀── the certificate ─────│         │              │
│  └─────────┘                        └─────────┘              │
│                                                              │
│  The validation proves the domain control; the CSR asks for   │
│  the certificate.                                            │
└──────────────────────────────────────────────────────────────┘

The Challenge Types

┌──────────────────────────────────────────────────────────────┐
│  THE HTTP-01 VS THE DNS-01                                   │
│                                                              │
│  HTTP-01:                                                    │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ The file at /.well-known/acme-challenge/<TOKEN>        │  │
│  │ The CA retrieves it over the HTTP                       │  │
│  │ Requires the port 80                                    │  │
│  │ Cannot issue the wildcard                               │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  DNS-01:                                                     │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ The TXT record at _acme-challenge.<DOMAIN>             │  │
│  │ The CA queries the DNS                                  │  │
│  │ No port requirement                                     │  │
│  │ Can issue the wildcard                                  │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘

The Certificate Lifetime

┌──────────────────────────────────────────────────────────────┐
│  THE LIFETIME IS SHORTENING                                  │
│                                                              │
│  2026: 90 days                                               │
│  2027: 64 days (the plan)                                    │
│  2028: 45 days (the plan)                                    │
│                                                              │
│  The shorter lifetime increases the importance of the        │
│  automated renewal. The ARI exempts the qualifying renewals  │
│  from the rate limits.                                       │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
CA	Let’s Encrypt (ISRG)
Protocol	ACME
Client	Certbot, acme.sh, lego
Validation	HTTP-01, DNS-01, TLS-ALPN-01
Certificate lifetime	90 days (64 in 2027, 45 in 2028)
Certificate files	`/etc/letsencrypt/live/<domain>/`
Server file	`fullchain.pem`
Key file	`privkey.pem`
Renewal	`certbot renew` (twice-daily timer)
Test	`certbot renew --dry-run`
Rate limit	5 duplicate certs per 168 hours

Key takeaways:

Let’s Encrypt is the free, automated CA. It issues the certificates through the ACME protocol, and the client on the web server performs the domain validation, the issuance, and the renewal without the human intervention . The certificates are trusted by the major browsers, and they are the same technical quality as the paid ones.
The ACME protocol has two steps: the validation and the issuance. In the validation, the client proves the domain control by completing one of the challenges. In the issuance, the client sends the CSR, and the CA returns the signed certificate . The validation cannot use the HTTPS, because the certificate is not yet issued.
The HTTP-01 is the most common challenge, and the DNS-01 is the one for the wildcard. The HTTP-01 provisions a file on the port 80, and the DNS-01 provisions a TXT record . The DNS-01 is the only challenge that can issue the wildcard certificates.
The certificate lifetime is 90 days, and it is shortening. The plan is 64 days in the February 2027 and the 45 days in the 2028. The shorter lifetime limits the exposure from the compromised keys, and it increases the importance of the automated renewal .
The Certbot installs the renewal timer. The systemd timer attempts the renewal twice a day, and it renews the certificate when it is within the 30 days of the expiry. The --dry-run tests the renewal against the staging environment .
The rate limits prevent the abuse. The Duplicate Certificate limit is 5 per exact set of names per 168 hours, and the retry loop can exhaust it in the minutes. The --dry-run and the staging environment are the mechanisms that avoid the production rate limits during the testing .

Remember: Let’s Encrypt is the CA that makes the HTTPS practical at scale. The ACME protocol automates the validation and the issuance, and the Certbot client performs the renewal. The HTTP-01 is the common challenge, and the DNS-01 is the one for the wildcard. The certificate lifetime is short and shortening, and the renewal is the automated. The result is the TLS that is configured once and maintained without the manual intervention, which is the difference between the HTTPS that expires and the HTTPS that works.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!