That padlock in a browser does not appear just because a certificate file exists somewhere under Let’s Encrypt makes this free and automatable. On most Linux VPSs, I use Certbot with Nginx. Apache follows much the same route, but it needs a different plugin. Before running anything, find out which web server is active. The right command on the wrong machine is still the wrong command.<\/p>\n Check DNS before starting. I normally start in the terminal rather than in a hosting panel:<\/p>\n The first command should show the VPS’s IPv4 address. The second should show the IPv6 address, if one is configured. An empty result can mean the record is missing or that the DNS change has not reached the resolver you are using yet. Depending on the TTL, you may need to wait. Running Certbot repeatedly will not make DNS update faster.<\/p>\n Next, see what is listening:<\/p>\n Let’s Encrypt needs to reach TCP port 80 from the internet when you use HTTP-01 validation. Port 443 must also be reachable for normal HTTPS traffic. With UFW, this profile opens both ports:<\/p>\n This changes the firewall on the VPS. If your provider has a security group, or you also use nftables or an external firewall, allow the same traffic there. Opening a port in UFW does not open a port blocked by the provider’s network rules.<\/p>\n On Debian and Ubuntu, Certbot and its web-server plugins are available through the distribution package manager on many supported releases. Some Ubuntu installations use Snap instead. I generally prefer First identify the operating system and the web server:<\/p>\n If one of the web-server commands is not installed, it will print an error. That is fine; it is still useful information.<\/p>\n For Nginx on Debian or Ubuntu:<\/p>\n For Apache, install its plugin instead:<\/p>\n The plugins can read your virtual host configuration and make certificate installation easier. I still back up the configuration before allowing an automated tool to edit a production server. A small mistake can affect an unexpected site, especially on a VPS hosting several domains.<\/p>\n You should see Make sure the domain is present in an Nginx server block. This is a small HTTP-only example:<\/p>\n Save it as, for example, Checking the hostname before changing Nginx in production is not theoretical advice for me. I once changed a server I thought was staging and found out, rather late, that it was production. That was the day I started using a red shell prompt on production systems. I still run Now run Certbot with the Nginx plugin:<\/p>\n Certbot asks for an email address, acceptance of the terms, and whether HTTP traffic should be redirected to HTTPS. For a normal public site, I choose the redirect. For an application behind a proxy, I first check how After a successful run, inspect the certificate:<\/p>\n The files under Certbot normally adds these directives itself. If you configure them manually, use On an Apache VPS, the process is similar. Confirm that the domain is defined in the virtual host, then run:<\/p>\n Certbot can add the SSL configuration to the Apache virtual host and redirect HTTP traffic to HTTPS. Test the configuration after the change:<\/p>\n For a Docker VPS, decide where the reverse proxy will live before adding containers. Instead of distributing separate certificates to every container, let Nginx Proxy Manager, Traefik, or Nginx on the host terminate TLS for incoming traffic. The port-checking approach in How to Install Docker on a VPS and Run Your First Container<\/a> is useful here, particularly before the first container starts competing for ports.<\/p>\n After installation, check the certificate endpoint and the redirect from the terminal:<\/p>\n The first command will usually return OpenSSL can show the certificate details:<\/p>\n The Let’s Encrypt certificates are short-lived, so installing one on a VPS is only half the job. Test renewal before the expiry date becomes somebody’s emergency:<\/p>\n After renewal, confirm that Nginx or Apache loads the new certificate. The files can change while the running process continues serving the old certificate from memory. Certbot normally handles the reload, but a custom setup may need a deploy hook:<\/p>\n Make the hook executable:<\/p>\n The hook runs during Certbot’s deploy phase, after a certificate has actually been renewed. I would rather connect the reload to that renewal flow than add a cron line that reloads Nginx unnecessarily every day.<\/p>\n Do not assume renewal works because a timer exists. I monitor the result of Certbot uses challenge methods to prove that you control the domain. For a standard Nginx setup, HTTP-01 is usually the simplest. Let’s Encrypt tries to fetch a temporary file under HTTP-01 does not support wildcard certificates. For Do not put the token in shell history or in a playbook that everyone can read. The DNS API token should have only the permission to create and delete TXT records in the relevant zone. Small permissions matter when a token leaks.<\/p>\n This usually points to network access, not to the certificate. First confirm that DNS returns the right IP, then check port 80 in both the VPS firewall and the provider security group. Nginx listening only on If IPv4 works but IPv6 does not, and the domain has a bad If you use a proxy such as Cloudflare, its SSL mode must agree with the origin server’s HTTPS configuration. A proxy can accept HTTPS externally and connect to the VPS over HTTP, while the VPS redirects that request back to HTTPS. That combination creates a loop. Make sure the application interprets proxy headers correctly.<\/p>\n Do not repeat failed requests over and over. Let’s Encrypt applies validation and certificate limits in production. Test the flow against its staging environment first:<\/p>\n Staging certificates are not trusted by browsers; they are only for testing the installation flow. After testing, check that the staging certificate has not been left in the live configuration.<\/p>\n Certbot may obtain the certificate successfully while the Nginx reload fails because of an unrelated configuration error. Start with:<\/p>\n Restarting before reading the logs was one of my early-career mistakes. When certificate installation goes wrong, I test the configuration and inspect the relevant logs before restarting anything. That avoids cutting existing connections for no reason.<\/p>\n Certbot’s defaults are a sensible starting point for most sites. Before writing a custom cipher list, understand the application’s client requirements. If you do not need support for old devices, TLS 1.2 and TLS 1.3 are a reasonable baseline:<\/p>\n Do not rush into HSTS. The Before enabling HSTS, check the site’s assets, API endpoints, and third-party content. Images, JavaScript, or fonts loaded over HTTP will create mixed-content warnings. The browser’s developer console is a quick way to find these references.<\/p>\n An SSL certificate encrypts the connection between the client and the server and helps verify the domain. It does not mean that the operating system is patched, SSH is safely configured, or the application has no vulnerabilities.<\/p>\n Handle firewall rules, updates, separate users, SSH keys, and intrusion monitoring as separate tasks. The baseline checks in 10 Essential Steps to Secure and Harden Your Linux Server<\/a> are a useful starting point, but adjust them to the risks of your own VPS. Changing the SSH port is not security by itself; without log monitoring, it mostly moves the noise somewhere else.<\/p>\n\/etc<\/code>. For me, it means the entire path is working: DNS points to the right machine, the web server answers on the expected ports, HTTP validation can reach the VPS, and renewal will happen before the certificate expires.<\/p>\nPrepare the domain and the VPS<\/h2>\n
example.com<\/code> and, if you use it, www.example.com<\/code> should point to the VPS’s public IPv4 address. If you use IPv6, check the AAAA<\/code> record too. An old or incorrect AAAA<\/code> record can send validation requests to another server while IPv4 appears perfectly healthy.<\/p>\ndig +short example.com A\ndig +short example.com AAAA\ndig +short www.example.com A<\/code><\/pre>\nsudo ss -tulpn | grep -E ':(80|443)b'\nsudo ufw status verbose<\/code><\/pre>\nsudo ufw allow 'Nginx Full'\nsudo ufw status<\/code><\/pre>\nInstall Certbot<\/h2>\n
apt<\/code> on Debian systems so package management stays consistent with the rest of the server, but check the instructions for the operating system you actually run.<\/p>\ncat \/etc\/os-release\nnginx -v\napache2 -v<\/code><\/pre>\nsudo apt update\nsudo apt install certbot python3-certbot-nginx<\/code><\/pre>\nsudo apt install certbot python3-certbot-apache<\/code><\/pre>\nsudo cp -a \/etc\/nginx \/etc\/nginx.backup.$(date +%F)\nsudo nginx -t<\/code><\/pre>\nsyntax is ok<\/code> and test is successful<\/code> in the nginx -t<\/code> output. If you do not, stop there and fix the configuration first.<\/p>\nUse Let’s Encrypt with Nginx<\/h2>\n
server {\n listen 80;\n listen [::]:80;\n server_name example.com www.example.com;\n\n root \/var\/www\/example.com\/public;\n index index.html index.php;\n\n location \/ {\n try_files $uri $uri\/ =404;\n }\n}<\/code><\/pre>\n\/etc\/nginx\/sites-available\/example.com<\/code>, then enable it:<\/p>\nsudo ln -s \/etc\/nginx\/sites-available\/example.com \/etc\/nginx\/sites-enabled\/example.com\nsudo nginx -t\nsudo systemctl reload nginx<\/code><\/pre>\nreload<\/code> makes Nginx reread its configuration without dropping existing connections. Before requesting the certificate, open the domain over HTTP and confirm that the expected site appears. If you see the default Nginx page, the hostname match is not correct yet.<\/p>\nhostname<\/code> before editing a configuration file.<\/p>\nsudo certbot --nginx -d example.com -d www.example.com<\/code><\/pre>\nX-Forwarded-Proto<\/code> is handled so I do not create a redirect loop.<\/p>\nsudo ls -l \/etc\/letsencrypt\/live\/example.com\/\nsudo certbot certificates<\/code><\/pre>\nlive<\/code> are symbolic links to the current certificate version, not separate permanent copies. Pointing Nginx at these paths means you do not need to edit the configuration after every renewal:<\/p>\nssl_certificate \/etc\/letsencrypt\/live\/example.com\/fullchain.pem;\nssl_certificate_key \/etc\/letsencrypt\/live\/example.com\/privkey.pem;<\/code><\/pre>\nfullchain.pem<\/code> for the certificate. Using only cert.pem<\/code> can cause intermediate-chain problems with some clients.<\/p>\nApache takes a different plugin<\/h2>\n
sudo certbot --apache -d example.com -d www.example.com<\/code><\/pre>\nsudo apachectl configtest\nsudo systemctl reload apache2<\/code><\/pre>\nSyntax OK<\/code> means the configuration is syntactically valid. If your application runs on PHP-FPM, Node.js, or Docker behind Apache, the certificate usually belongs on the public-facing Apache or Nginx layer, not inside the application itself.<\/p>\nCheck the HTTPS redirect<\/h2>\n
curl -I http:\/\/example.com\ncurl -I https:\/\/example.com<\/code><\/pre>\n301<\/code> or 308<\/code> with a header such as Location: https:\/\/example.com\/<\/code>. A 200<\/code> from the second request is a good sign, although an application may return a different status on its login page. The useful checks are that the TLS handshake succeeds and that the intended certificate is being served.<\/p>\necho | openssl s_client -connect example.com:443 -servername example.com 2>\/dev\/null | openssl x509 -noout -subject -issuer -dates<\/code><\/pre>\n-servername<\/code> option matters. When several domains share one IP address, testing without SNI may show the default virtual host’s certificate instead. Check notBefore<\/code>, notAfter<\/code>, subject<\/code>, and issuer<\/code> in the output.<\/p>\nRenewal automation is the part that matters<\/h2>\n
systemctl list-timers | grep certbot\nsystemctl status certbot.timer\nsudo certbot renew --dry-run<\/code><\/pre>\n--dry-run<\/code> tests the renewal path without replacing the live certificate. A successful run is a good indication that DNS validation, port access, and the web-server reload all work. If it fails, fix it now. The day a certificate expires is a poor time to discover that a timer has been disabled.<\/p>\nsudo install -d -m 0755 \/etc\/letsencrypt\/renewal-hooks\/deploy\nsudo vim \/etc\/letsencrypt\/renewal-hooks\/deploy\/reload-nginx.sh<\/code><\/pre>\n#!\/bin\/sh\nsystemctl reload nginx<\/code><\/pre>\nsudo chmod 0755 \/etc\/letsencrypt\/renewal-hooks\/deploy\/reload-nginx.sh<\/code><\/pre>\ncertbot renew --dry-run<\/code> and check the served certificate separately. An availability alarm that only checks the HTTP status can report the site as healthy while the certificate is already expired.<\/p>\nHTTP-01 and DNS-01 validation<\/h2>\n
http:\/\/example.com\/.well-known\/acme-challenge\/...<\/code>. Completely blocking port 80, or rejecting every HTTP request in the application layer, can break validation.<\/p>\n*.example.com<\/code>, use DNS-01 instead. Certbot plugins for DNS providers can create the required TXT record through an API. If you use the Cloudflare DNS plugin and store its API credentials in a file, restrict the permissions:<\/p>\nsudo chmod 0600 \/root\/.secrets\/certbot\/cloudflare.ini<\/code><\/pre>\nCommon failures and how I diagnose them<\/h2>\n
Timeout or connection refused<\/h3>\n
127.0.0.1:80<\/code> will also prevent external validation.<\/p>\nsudo ss -ltnp | grep ':80'\ncurl -4 -I http:\/\/example.com\ncurl -6 -I http:\/\/example.com<\/code><\/pre>\nAAAA<\/code> record, correct DNS. I hit this during a VPS migration: I updated the A record and missed the old AAAA record. Clients using IPv6 continued visiting the previous server.<\/p>\nToo many redirects<\/h3>\n
Rate-limit errors<\/h3>\n
sudo certbot certonly --staging --nginx -d example.com<\/code><\/pre>\nThe web server cannot reload<\/h3>\n
sudo nginx -t\nsudo journalctl -u nginx -n 80 --no-pager<\/code><\/pre>\nHarden TLS carefully<\/h2>\n
ssl_protocols TLSv1.2 TLSv1.3;<\/code><\/pre>\nStrict-Transport-Security<\/code> header tells browsers to use HTTPS for the domain. Do not enable includeSubDomains<\/code>, and especially not preload<\/code>, until every subdomain is ready for HTTPS. A forgotten subdomain can become unexpectedly difficult to reach.<\/p>\nA certificate is not server security<\/h2>\n