Certbot and Let's Encrypt: renew HTTPS automatically without breaking your website
Published on 2026-10-26 by frfrand
Free certificates, automatic renewal and TLS diagnostics in Nginx
Your site shows the green padlock today, but what happens in two months? Public certificates expire and must be renewed. Let's Encrypt allows you to obtain free certificates and Certbot can automate much of the process.
We are going to turn it into a procedure you can use on a real VPS. The goal is to understand why it works, how to test it, and what problem appears if one part is misconfigured.
What Certbot and Let's Encrypt mean and when you need them
Let's Encrypt is a certificate authority and Certbot is an ACME client that requests and renews certificates. To issue them, domain control must be verified through a compatible challenge (for example HTTP-01 or DNS-01). Automation depends on DNS and services remaining configured correctly.
Before changing anything in production, note the current status: IP, domain, port, affected service, and time of the last deploy. An isolated modification is easy to verify; five simultaneous changes make it harder to reconstruct what happened.
Configuration or example commands
sudo nginx -t
sudo certbot certificates
sudo certbot renew --dry-run
systemctl list-timers | grep -i certbot
# Verificar certificado público desde otra máquina
openssl s_client -connect ejemplo.com:443 -servername ejemplo.com </dev/nullDomains, IP addresses, paths, and names are illustrative. Do not copy an entire configuration over the current one without comparing first. In examples that include ports or firewall, make sure to preserve administrative access.
How I would do it step by step
- Preparation. Check that the DNS points to the correct server and the domain is accessible via the chosen challenge.
- Step 2. Install Certbot using the recommended method for your distribution.
- Step 3. Request the certificate with the compatible plugin and verify the hostname.
- Step 4. Test renewal with
--dry-runwithout waiting for it to expire. - Verification. Configure expiration monitoring and verify service reload after renewal.
When finished, check the actual operation from another connection. For example, for an API it is not enough to open the browser: run a read request, a write to a test database, and check the process logs.
Example of a real project
A reservation API uses HTTPS on api.cliente.com. The certificate expires on a Sunday and payment requests start failing from the browser. A periodic renewal test would have detected the configuration problem earlier.
The lesson is simple: an infrastructure configuration does not live isolated from the application. The frontend, the server, the database, and the workers connect, so measuring where the failure starts is more useful than restarting everything.
The error to avoid
Do not disable TLS validation to "fix" the error. Check the name, chain, system time, and certificate served by Nginx. Certbot cannot fix a misdelegated DNS zone.
When working with client servers, keep a backup or rollback procedure before changes that affect data, network, or certificates. And if you don't know what permissions an operation needs, avoid running it as root just to stop errors from showing.
How does it relate to ArduMaker?
ArduMaker includes domain and SSL management in the VPS environment. Even so, verify actual renewal and alerts: a configured certificate does not equal one that is always valid.
In a typical case you can create a VPS for the application, deploy from Git, associate an HTTPS domain, and manage the backend and necessary databases. Tools help centralize operations, but you need to understand which port and process fulfills each function.
Questions that arise when you try it
How do I know if the failure is DNS or the service? Check resolution first, then connection to the port, and finally the application response. That order avoids confusing different problems.
Can I expose a database to make it easier to maintain? Better design private access or authenticated tunnels when possible. Exposing a port does not replace engine permissions or the firewall.
What should I document? The expected configuration, how to verify it, and how to return to the previous state. That document helps you more than a list of commands without context.
References
In summary: a good network or server configuration is one that you can explain, verify, and recover when something fails.