A Let's Encrypt certificate takes minutes to get and renews itself. What people get wrong comes afterwards: the redirect, the TLS versions and HSTS, the header that tells browsers never to try plain HTTP again.
Let's Encrypt is a certificate authority that issues free certificates automatically through the ACME protocol. certbot proves you control the domain by answering a request on port 80 (HTTP-01) or through a DNS record (DNS-01, required for wildcards). Certificates last 90 days precisely so that renewal gets automated. The certbot package installs a systemd timer that tries to renew twice a day; check that it runs and add an external alert on the expiry date.
The Strict-Transport-Security header tells the browser to use only HTTPS for your domain for the duration of max-age, even if the user types http:// or follows an old link. It closes the window in which an attacker on the same network can intercept the very first HTTP request. The risk runs the other way: if a subdomain has no valid certificate and you set includeSubDomains, browsers block it for a year. So roll HSTS out in steps: a small max-age, then one year, then includeSubDomains and, last, preload.
| Directive | Recommended value | Effect | When to add it |
|---|---|---|---|
| max-age | 31536000 (1 year) | The browser forces HTTPS for this duration | Once the whole site works over HTTPS; start with a small value |
| includeSubDomains | present | Also applies to every subdomain | Only when each subdomain has a valid certificate |
| preload | present | Allows inclusion in the browsers' preloaded list | The last step; practically irreversible in the short term |
sudo certbot --nginx -d example.ro -d www.example.ro --redirect
sudo certbot renew --dry-run
systemctl list-timers | grep certbotserver {
listen 443 ssl;
http2 on;
server_name example.ro www.example.ro;
ssl_certificate /etc/letsencrypt/live/example.ro/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.ro/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
# Start with max-age=300, watch for a week, then raise it to 31536000.
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}
server {
listen 80;
server_name example.ro www.example.ro;
return 301 https://$host$request_uri;
}The certificate had been installed by hand and nobody noted the date. It expired on a Saturday, and on Monday clients saw a security warning. Moving to certbot with its timer and an external expiry alert removed the problem for good.
It enabled HSTS with includeSubDomains on the main domain and forgot that the staging subdomain had a self-signed certificate. The team could no longer open staging in their own browsers. The fix was a low max-age step before the final value.
Yes, but only through DNS-01 validation: certbot creates a TXT record in your domain's zone through the DNS provider's API. The certificate covers every first-level subdomain. Use it when you have many dynamic subdomains; otherwise separate certificates per subdomain are easier to track.
Browsers show a full-page warning and most visitors leave. API clients refuse the connection. With HSTS active, users cannot even click through the warning. That is why automatic renewal and an external expiry alert are not optional.
For high-traffic sites with a stable structure, yes: the first visit is protected. For a site that changes subdomains or has internal services without certificates, the risk of locking something out for months is real. Start without preload and decide after a few months of stable HSTS.
A production server starts getting attacked within minutes of receiving a public IP address, however small the project is. This guide ranks the controls by impact, from SSH access to incident response, with the Romanian rules that apply along the way. Every topic has its own page with a short answer, examples and ready-to-use configuration.