The Certificate That Renews Itself

That is the entire argument for automatic certificates, and it is a good argument. Everything after this is about which kind of automation you pick, and what you give up for it.

What "automatic" actually means

A certificate is just a signed statement: this public key belongs to this hostname. The signing part is a certificate authority. The automatic part is everything around it — the request, the domain validation, the installation, the renewal.

You can automate any one of those steps and still call it automatic. A shell script with `certbot renew` in cron is automatic. An MDM profile that installs a client certificate at first boot is automatic. A Kubernetes controller that watches an Ingress resource and provisions a certificate before the pod is even ready is automatic.

They are not the same thing, and they do not cost the same thing.

The ACME path

The most common answer is ACME, the protocol behind Let's Encrypt. An ACME client talks to the CA, proves you control the domain, and receives a signed certificate. Then it does it again in sixty days, because Let's Encrypt certificates last ninety.

On a plain Linux server, that is `certbot` or `acme.sh` and a timer:

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

```bash certbot renew --quiet ```

Two commands, a systemd timer, and you are done. The cost is that the webroot path has to stay writable and the DNS or HTTP challenge has to keep working. If you move the site and forget to update the webroot, renewal fails quietly in the background until it doesn't.

That is the trade. Simple to set up, and it depends on a config file that nobody looks at again until something breaks.

When you have more than one server

One server with one certificate is a cron job. Forty servers behind a load balancer is a different problem. Now you need the certificate to exist in more than one place, and you need it to be the same certificate, and you need the renewal to happen everywhere at once or not at all.

This is where people reach for configuration management, or a secrets store, or a small internal service that hands out certificates. All three work. All three are more moving parts than `certbot renew`.

The honest version: if you have forty servers and no configuration management, you have a bigger problem than certificates. Automating the certificates will not fix it. It will just move the failure to the next layer up.

Kubernetes and cert-manager

In a cluster, the certificate is not really yours. It belongs to an Ingress or a Service, and the controller that manages that resource should manage the certificate too.

`cert-manager` does this. You install it, you create a `ClusterIssuer` pointing at Let's Encrypt, and you annotate your Ingress. The controller requests the certificate, stores it in a Secret, and renews it before expiry. You never touch a file.

The cost is that `cert-manager` is now part of your critical path. If it stops reconciling, certificates stop renewing, and you find out the same way you always find out. It also needs its own RBAC, its own CRDs, and its own upgrade cycle. You have traded a cron job for a controller you now have to operate.

That is usually the right trade in a cluster. It is not obviously the right trade on three VMs.

The MDM and endpoint side

Automatic certificates are not only a server thing. On managed laptops, a configuration profile can carry a client certificate and install it at enrolment. The user never sees it.

```bash sudo profiles install -path ~/certificate.mobileconfig ```

Pushed through Jamf, Intune or SimpleMDM, that happens on first boot and again whenever the profile changes. The certificate then authenticates the device to Wi-Fi, VPN or internal services. No password, no prompt, no user decision.

This is the model behind things like geteduroam, where a federated identity is exchanged for a client certificate without anyone typing credentials into a supplicant. It works well, and it means the certificate is now tied to the device lifecycle. Wipe the device, lose the certificate. That is a feature until it is a support ticket.

What the closed options do well

AWS Certificate Manager issues and renews certificates for load balancers and CloudFront distributions and charges nothing for the certificate itself. You cannot export the private key, which is exactly why it is simple — there is nowhere for it to leak from.

That is a real advantage, and it is worth saying plainly. The open path gives you portability and control. The closed path gives you fewer decisions and fewer ways to get it wrong. If you are already on AWS and you do not need the key elsewhere, ACM is the shorter road.

The price is that leaving is not free. A certificate you cannot export is a certificate you cannot take with you.

The part nobody automates

Renewal is the easy half. The hard half is knowing whether it worked.

An ACME client that fails at 02:00 will retry, and retry, and eventually give up. You will not get an email unless you configured one. The certificate will sit there, valid, until it is not.

So whatever you pick, monitor the expiry date from outside the system that renews it. A check that connects to your hostname and reads the certificate is ten lines and catches every failure mode above. It does not care whether you used Certbot, cert-manager or ACM. It only cares whether the thing your users connect to is still trusted.

That check is the actual automation. The rest is plumbing.

Where it depends on

If you run one server and one domain, `certbot` and a timer is correct and anything more is decoration. If you run a cluster, `cert-manager` is correct and a cron job is a liability. If your endpoints are managed, push the certificate with the profile and stop thinking about it.

The thing that decides it is not which tool is better. It is how many places the certificate has to exist, and who finds out first when it does not.