Automating SSL Renewals

(Inspired by the automation setup shown in the post you shared — 47 SSL certificates renewed automatically, 32 engineer hours saved per year, and zero expired certificates.)

https://x.com/brankopetric00/status/1980779147635888396

The Pain We All Know

Every 90 days, the same calendar reminder would pop up:

“Renew SSL certificates.”

That used to mean two hours of tedious work — generating a new CSR, getting it signed, uploading it to our load balancer, and praying we didn’t break anything in production.

Multiply that by dozens of certificates across environments, and it becomes a full-time chore.

So when we finally automated the entire thing, saving 32 hours a year, it felt like magic. But to really appreciate why this automation matters, you have to understand what’s happening under the hood.

1. What’s an SSL Certificate Anyway?

When your browser connects to a website using HTTPS, it expects two things:

  1. The site is really who it claims to be (not an imposter).
  2. The connection is encrypted, so no one can snoop on the data in transit.

An SSL certificate solves both.

It’s a small digital file that:

  • Contains your domain name and public key.
  • Is digitally signed by a trusted organization (a Certificate Authority).
  • Lets browsers verify your identity and establish a secure encrypted channel.

Without it, you see those red “Not Secure” warnings — your browser refuses to trust the connection.

2. The Hidden Hero: Certificate Authority (CA)

But who gives you this certificate?

That’s the job of a Certificate Authority (CA) — a trusted company (like Let’s Encrypt, DigiCert, or GlobalSign) whose “signature” is recognized by browsers and operating systems.

When you request a certificate, the CA checks if you truly own the domain name you’re asking for. Once verified, they sign your certificate with their private key, effectively saying:

“We vouch that this public key belongs to this domain.”

Your browser trusts them because every OS and browser already includes a list of these trusted CAs.

3. What Is a CSR, and Why Do We Generate It?

To get a certificate, your server first creates something called a Certificate Signing Request (CSR).

The CSR contains:

  • Your public key
  • Your domain name and company info
  • A digital signature made using your private key

You send this CSR to the CA. They verify your details and issue a certificate that browsers will trust.

The private key stays on your server — never shared. It’s the secret that unlocks encrypted communication.

4. Where Are Certificates Installed?

Here’s where it all ties to your infrastructure.

When a user opens https://yourwebsite.com, the first thing they talk to is usually:

  • A load balancer, or
  • A reverse proxy (like Nginx, Traefik, or Caddy)

That’s the component that terminates HTTPS.

It’s the one presenting your SSL certificate during the TLS handshake.

So, when certificates expire or renew, these components must be updated with the latest certificate and private key. If not, users will see “expired certificate” errors — even if you already renewed it somewhere else.

In short:

Whoever speaks HTTPS to the outside world must have the latest certificate.

5. The Real Problem: Renewal Fatigue

Certificates expire (usually every 90 days with Let’s Encrypt).

That’s a security feature, but it also means:

  • You must remember to renew them.
  • You must re-upload them to every load balancer or proxy.
  • You must reload services so they pick up the new ones.

This process, repeated dozens of times a year, is error-prone and exhausting.

6. The Fix: Automation Through ACME

The breakthrough came with ACME — the Automatic Certificate Management Environment protocol.

It’s what made Let’s Encrypt’s “free and automatic SSL for everyone” possible.

ACME defines how a program (called an ACME client) can automatically:

  1. Generate your CSR and private key.
  2. Prove to the CA that you own the domain (via HTTP or DNS challenge).
  3. Receive the signed certificate.
  4. Install it and set up auto-renewal.

Common ACME Clients

  • Certbot — for standalone servers
  • cert-manager — for Kubernetes clusters
  • acme.sh — for lightweight shell-based automation
  • Caddy — built-in ACME client, does all this automatically

No human intervention, no forms, no tickets — just self-renewing SSL.

7. How the Automation Works (Behind the Scenes)

Imagine you’re using cert-manager on Kubernetes with Let’s Encrypt:

  1. You define a Certificate resource for your domain.
  2. cert-manager generates a private key and CSR.
  3. It talks to Let’s Encrypt (CA) via the ACME protocol.
  4. Let’s Encrypt asks you to prove domain ownership (ACME “challenge”).
  5. cert-manager creates a temporary file or DNS record automatically.
  6. Let’s Encrypt verifies it and issues a signed certificate.
  7. cert-manager stores the certificate and private key in a Kubernetes Secret.
  8. Your Ingress (reverse proxy/load balancer) uses that Secret — auto-reloads when updated.
  9. 60 days later, it renews silently in the background.

No Slack reminders. No downtime. No “who forgot to renew this cert?” panic.

8. The Payoff

After switching to this model, we achieved:

  • 47 certificates managed automatically
  • 32 engineer hours saved per year
  • Zero expired certificates
  • Zero manual renewals

That’s the magic behind the automation screenshot you saw at the start — a simple but elegant DevOps improvement that eliminated an entire class of production headaches.

9. The Takeaway

SSL certificates used to feel like chores — something you had to touch every 90 days.

Now, thanks to ACME, they’re just another background process quietly doing its job.

The less time you spend on renewals, the more time you can spend building what actually matters.