How to Use ACME and CertBot for SSL/TLS Certificate Automation?

Three seconds. That’s all it takes for a visitor to encounter a browser message, freak out, and never return.

Nobody sticks around for “Your connection is not private“. They close the tab. They don’t come back. And the worst part? It’s not a new phishing attack or some other technical security problem. It was a forgotten renewal date.

This isn’t rare. In fact, a recent one even hit Microsoft, preventing Teams from working and locking out thousands of users. If it happens to a company with security engineers, it’s no surprise that a small, entrepreneurial team might forget.

Manually managing SSL is asking for trouble. You have a slew of CSRs (Certificate Signing Requests), expiries, CA (Certification Authority) portals, and server configs to deal with – all by hand, all the time, all across multiple domains. It’s not a matter of if. It’s when.

And that’s why we have ACME. The Automated Certificate Management Environment protocol defines how servers can request, verify, and renew certificates – automatically, securely, with no need for human intervention.

ACME’s accomplice is Certbot. It’s free, open source, and easy to use – and does all the hard work of managing your certificates.

They transform managing SSL from a tedious task to automation you don’t think about because it “just works”.

A Little Bit of History of ACME

The Automated Certificate Management Environment (ACME) protocol automates the management of the issuance and renewal of SSL/TLS certificates.

Before ACME, each certificate request required manual processes such as key creation, domain verification, waiting for the CA to issue a certificate, and then manual configuration. ACME makes all those steps unnecessary.

ACME is standardised by the Internet Engineering Task Force (IETF) in RFC 8555 of 2019. This is important – it keeps any compliant ACME client compatible with any compliant Certificate Authority (CA) – not just Let’s Encrypt.

The process is simple: your ACME client (such as Certbot) communicates with a CA’s ACME server. The client authenticates your domain. The CA issues the certificate. No human involvement required.

So, it’s like OAuth for certs – a consistent process that eliminates the need for any paperwork.

ACME Building Blocks

Five key components comprise ACME:

• Account: Your identity with a CA and key pair.
• Order: A request for a certificate for specific domains.
• Authorisation: The CA’s Signal that you need to demonstrate domain control.
• Challenge: The way to prove. The ACME protocol supports HTTP-01, DNS-01, and TLS-ALPN-01 challenges.
• Issuing Your Certificate: After challenges are resolved, your certificate is immediately signed and issued by the CA.

All steps are linear. Each is mandatory – if you miss one, it doesn’t work.

ACME Certification Automation Under the Hood (The ACME Flow)

Demystifying the ACME flow. Here’s what will occur when Certbot acquires a certificate on your behalf:

Step 1. Account Registration:

Certbot gets a key pair and sets up an account with the CA (e.g., Let’s Encrypt). This happens once. Your public key is stored by the CA as your identity.

Step 2. Order Creation:

Certbot asks for a certificate for your domain(s). The CA sends back authorisations to be completed.

Step 3. Challenge Request:

The CA sends a challenge – usually either HTTP-01 (put a token file somewhere on your site) or DNS-01 (set a TXT record in DNS). This demonstrates domain ownership.

Step 4. Challenge Validation:

Automatic challenge by Certbot. The CA verifies it. Success or failure – nothing in between.

Step 5. Certificate Issuance:

The CA successfully validates your certificate and issues it to you. No waiting. No email threads.

Step 6. Installation:

Certbot writes the certificate to your machine and restarts the web server. Done.

What is Certbot, and why Does it Matter in 2026?

Certbot is an open source ACME client that automates SSL/TLS certificate management (issuance and renewal) without user intervention.

It’s developed by the Electronic Frontier Foundation (EFF). It’s not a one-person show. Certbot is developed, maintained and backed by well-established organisations, with years of experience serving millions of websites.

It’s primarily used with Let’s Encrypt – the free, automated CA now used to secure more than 300 million websites. They make HTTPS available to all, not just those with money to pay security vendors.

Three Reasons Why Certbot is so Popular:

• Easy to Use: One command to issue a certificate on most Linux servers. No editing of configuration files.
• Plugin Ecosystem: Apache, Nginx and DNS provider plugins automatically configure servers.
• Renewal Automation: Certbot creates a cron job or systemd timer upon installation, which renews certificates before they expire – each 90-day cert has 60 days left when it renews.

What’s Needed to Run Certbot

Before you install Certbot and run any commands, make sure you have the following four elements:

• A domain name that resolves to your server’s IP address. Domain ownership is verified – localhost or unresolved hostnames won’t work.
• An open firewall for ports 80 and 443. If you use the HTTP-01 challenge, you need port 80; HTTPS needs 443.
• SSH access with sudo rights to your server. Many Certbot commands require sudo.
• Familiarity with the command line – you don’t need to be a Linux wizard to get by, but you need to know how to enter commands and read output.

How to Automate Certificates with Certbot?

Step 1: Install Certbot

Snap is the preferred installation – it automatically updates Certbot:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Prefer apt? On Ubuntu/Debian, run sudo apt install certbot. Snap is preferred in most production environments as it doesn’t depend on your OS packages.

Step 2: Get an SSL Certificate

Nginx or Apache plugin – fastest. Certbot makes it easy to automate setup:

sudo certbot --nginx -d example.com -d www.example.com
sudo certbot --apache -d example.com

Webroot method (useful for manual config of server):

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

Wildcards – add as many -d flags as you want. It’s free and works across multiple domains.

Domain Validation Methods

Certbot can use one of three methods of challenge – choose based on your server:

• HTTP-01: Puts a token file on http://yourdomain/.well-known/acme-challenge/. Easiest, works on most setups. Requires port 80 to be open.
• DNS-01: Creates a TXT record in your DNS zone. Ideal for wildcard certificates and behind firewalls.
• TLS-ALPN-01: Challenge on port 443 with a special TLS handshake. Rarely used, for special proxies.

HTTP-01 is the best for all newcomers.

Automating Renewals

Let’s Encrypt certificates are valid for 90 days – on purpose, to be automated. Certbot sets up a systemd timer. Verify it’s active:

sudo systemctl status snap.certbot.renew.timer

Dry run your renewal config (no changes to certificates):

sudo certbot renew --dry-run

Do this before you trust the new install. It’s a good time to catch permission and other errors.

Post-Renewal Hooks

It’s not useful to renew a certificate if your web server isn’t using it. Automatically reload with deploy hooks:

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

Store scripts in /etc/letsencrypt/renewal-hooks/deploy/ to run them automatically every time.

Advanced Automation Use Cases

Wildcard Certificates

Keeping up with api.example.com, staging.example.com, and a new subdomain every sprint? Multiple certificates can be cumbersome.

A wildcard certificate (*.example.com) is issued across all subdomains: a single renewal, no costs per subdomain.

The requirement: DNS-01 validation only, HTTP-01 can’t validate uncreatable subdomains. For dynamic use cases, DNS-01 is not a workaround; it’s the only scalable option.

DNS Automation

DNS-01 creates a conundrum: you automate certificates, but then every 90 days you have to log on to your DNS provider and enter a TXT record. This is “slow” manual work.

DNS API plugins fix this. Certbot directly supports Cloudflare, Route 53, and DigitalOcean:

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

The plugin sets and removes the TXT record. No DNS configuration.

Multi-Server Environments

Certbot only stores certificates locally – no auto-deployment to load balancers, application nodes, or CDNs.

We’ve seen approaches that scale: NFS mounts for fewer servers, Vault or AWS Secrets Manager for medium-sized teams, cert-manager for Kubernetes. At scale, Certbot issues certs. Distributing is up to you.

Best Practices for Production Setup

Dry Run on Staging

Until now, Let’s Encrypt rate limits have locked you out for hours. These tests will always be tested with staging first.

Monitor Independently

Timers break. Hooks fail silently. Monitor with Uptime Kuma or Checkly and set up alerts 30 and 14 days before expiry.

Lock Down Private Keys

sudo chmod 700 /etc/letsencrypt/live/

Root access only. A leaked private key is equivalent to a leaked database password.

Make Sure Renewals Work

sudo certbot renew --dry-run

Rerun after each server or renewal upgrade. Failure indications are silent until expiration.

Common Challenges and Pitfalls

There are always common ways a good Certbot setup can fail. Here’s what to watch for:

Port Blocking:

HTTP-01 challenge will silently fail when port 80 is blocked. If you’re getting this error, check the port before you run Certbot.

On UFW: sudo ufw allow 80

DNS Failures:

DNS-01 challenges don’t work if TXT records are not properly propagated. Make sure your changes have propagated with dnschecker.org before you validate. Skipping it uses up valuable rate limit quota.

Renewal Failures:

Systemd timers malfunction after OS upgrades and re-installs. Don’t assume it’ll work; run a dry run after all major changes.

Deployment Gaps:

Your certificate gets automatically renewed, but your server is still serving the old certificate. This is a problem with (or lack of) deploy hooks. Make sure to check the new certificate with:

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

ACME + Certbot: What they do (and do not)

Certbot is mighty, but it’s well targeted. This stops you from getting carried away.

What it solves well:

Issuance: Obtain valid certificates from trusted CA’s like Sectigo, DigiCert or Let’s Encrypt in minutes, not days.

Renewal: Automates the 90-day cycle, with no human intervention.

Validation: Successfully demonstrates domain ownership using the HTTP-01 or DNS-01 challenges.

Where it stops short:

Clustered Deployment: Certbot doesn’t cluster certificates. You’ll need your own tools.

Monitoring: No notifications for renewals or expiry. Blind spots form fast in production.

Lifecycle Management: Certbot doesn’t support certificate revocation, policy enforcement and audit logs.

For single-host deployments, Certbot provides all you need. In an infrastructure as code environment, it’s the issuance component – and it’s up to you to build the rest of your process around it.

Conclusion

It’s no secret that manual certificate management is a risk. Certificates can expire, flags can go up, and websites can go down – all in a truly avoidable manner.

ACME and Certbot provide an out-of-the-box foundation. Free certificates, daily renewals, and consistent validation – all with little to no human intervention. That’s more than sufficient for most single-node applications.

But automation isn’t everything. Certificates expire. Timers fail. Hooks misconfigure. Without understanding your certificate’s health, you won’t know until it fails – usually in the middle of the night.

It’s not about automation. It’s assured automation – when you know your certificates are good, you’re renewing, and users never get warned.

Build the framework with Certbot. Then layer in oversight for true security.

Take Your SSL Automation Further

Certbot handles issuance. It doesn’t handle visibility.

If you have production tasks to run, you don’t just want certbot’s automatic renewals; you want instant monitoring of the certificates, expiry notices, and instantaneous failure notification.

Our SSL Monitoring Solution integrates with your existing Certbot deployments to fill the gap:

• Expiry alerts at 30, 14, and 7 days — before users notice
• Uptime monitoring based on certificate status
• Real-time alerts via Slack, email, or PagerDuty if it doesn’t work

Certbot automates the work. We make sure it’s actually working.