Installation Guides
The padlock, in about five minutes
A certificate from Let’s Encrypt is free, automated and trusted by every browser. On an offshore hosting account with a panel it is usually one click. On a plain VPS it is one command. Neither costs anything.
What actually goes wrong is rarely the certificate itself. It is DNS not pointing at the server yet, port 80 being closed, or a renewal that silently stopped working three months ago. This guide covers all three.
Two things to check first
Certbot proves you control the domain by serving a file over HTTP. So two things have to be true before it can work.
DNS points at this server:
dig +short yourdomain.comThat must return this server’s IP. If it returns your old host, issuing will fail with an authorisation error, and the error message will not say why.
Port 80 is open. Even if your site only serves HTTPS, the validation happens over port 80. Close it and validation cannot complete:
ufw status | grep 80Issuing the certificate
apt install certbot python3-certbot-nginx -y
certbot --nginx -d yourdomain.com -d www.yourdomain.comUse python3-certbot-apache and --apache on Apache. Certbot edits the vhost for you, adds the certificate paths and sets up the HTTP to HTTPS redirect.
Include both the bare domain and www. They are separate names as far as a certificate is concerned, and leaving one out means half your visitors get a warning.
Verifying it
Do not just look for the padlock. Read what the server is actually serving:
echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates
Check the subject matches your domain and that notAfter is in the future. This command is also the fastest way to answer “is the certificate about to expire”, which is worth checking now and then even with auto renewal on.
Then confirm HTTP redirects to HTTPS rather than serving both:
curl -sI http://yourdomain.com | head -3You want a 301 to the https address. Serving the same page on both is a duplicate content problem as well as a security one.
Renewal, the part that actually breaks
Certificates last 90 days. Certbot installs a timer that renews at around 60 days, so in theory you never think about it again. In practice renewals fail quietly, and you find out when a visitor tells you the site is showing a warning.
certbot renew --dry-runThat runs the whole renewal without actually renewing. If it passes, renewal works. Run it once now, and again any time you change the web server config.
The two things that break renewals later:
- Port 80 got closed after the fact, often during a firewall tidy up. Validation needs it.
- The vhost changed and certbot can no longer find the webroot it used the first time.
Add an expiry alert to your monitoring so this cannot surprise you. Our monitoring guide covers what to alert on.
If you use Cloudflare
You still need a certificate on your own server. Cloudflare’s padlock covers the visitor to Cloudflare hop. The Cloudflare to your server hop is separate, and it is controlled by the SSL mode setting.
Set it to Full (strict), which requires a valid certificate on the origin. Flexible means Cloudflare talks to your server in plain HTTP while showing visitors a padlock, and it causes redirect loops on any server that forces HTTPS. Our Cloudflare guide covers the setting.
One catch: with the orange cloud on, certbot’s HTTP validation can fail because the request goes through Cloudflare rather than to your server. Either turn the proxy off for a few minutes while you issue, or use a DNS challenge instead.
How to test
- Load the site over HTTPS in a private window. No warnings.
curl -I http://yourdomain.comreturns a 301 to https.- Test www and the bare domain separately.
- Read the certificate with the openssl command above and check the dates.
certbot renew --dry-runpasses.- Run an SSL Labs test and look for the full chain rather than just a green padlock.
When something breaks
| What you see | Why | Fix |
|---|---|---|
| Authorisation failed during issuing | DNS not pointing here, or port 80 closed | Check with dig, then open 80 |
| Warning on www but not the bare domain | www was not included in the certificate | Reissue with both -d flags |
| Too many redirects | Cloudflare SSL mode is Flexible | Switch to Full (strict) |
| Certificate expired despite auto renewal | Renewal has been failing silently | certbot renew --dry-run to see the real error |
| Padlock shows but some images are blocked | Mixed content. Pages still reference http resources | Search and replace http with https in the database |
| Rate limit error from Let’s Encrypt | Too many issue attempts for the same domain | Wait an hour, and use --dry-run while testing |
Checklist
- DNS confirmed pointing at this server.
- Port 80 open for validation.
- Certificate issued for both the bare domain and www.
- HTTP redirecting to HTTPS with a 301.
- Certificate read back with openssl and dates checked.
certbot renew --dry-runpassing.- Cloudflare, if used, set to Full (strict).
- An expiry alert in your monitoring.
Want SSL without the command line?
Every OffshoreKaka hosting plan includes a free certificate that issues and renews on its own, so Full (strict) works from day one.
FAQ
Is a free certificate as good as a paid one?
For encryption, identical. Both use the same algorithms and browsers treat them the same. Paid certificates sell you a warranty, organisation validation showing your company name in the details, and support. For a normal website none of that changes anything a visitor sees.
Why only 90 days?
Short lifetimes limit the damage if a private key leaks, and they force renewal to be automated rather than a yearly manual chore. Since certbot handles it, the length is not something you have to think about, as long as you have tested that renewal works.
Does HTTPS help my ranking?
It is a genuine, confirmed ranking signal, though a very small one. The bigger reason is that browsers mark HTTP pages as Not Secure, and visitors leave. Treat it as required rather than as an optimisation.
Do I need a certificate on a subdomain too?
Yes, each hostname needs to be covered. Add it with another -d flag, or issue a wildcard certificate for *.yourdomain.com, which needs a DNS challenge rather than the HTTP one. If you are setting up a staging subdomain, our staging guide covers it.