Getting a free SSL certificate with Let's Encrypt

A free SSL certificate from Let's Encrypt is the standard way to put HTTPS on a website, and it costs nothing beyond a few minutes of your time. How you get one depends entirely on what kind of hosting you have. On cPanel hosting it happens automatically, without you touching anything. On a self-managed VPS, you install a small piece of software called Certbot and run it yourself. Both routes issue the same certificates from the same source, Let's Encrypt: the only difference is who does the work.

Before you start

Work out which of these you have, because the rest of this guide splits on it:

• Shared, reseller or WordPress hosting with Hostworld runs on cPanel. Certificates are handled by a cPanel feature called AutoSSL, and there is no command to run.
• A Hostworld VPS gives you root access and no imposed control panel on the server itself (you manage the VPS, start, stop and rebuild it, through Virtualizor from the client area, but what runs inside it is up to you). Getting HTTPS on a VPS means installing and running Certbot yourself.

If you're on a VPS, this picks up from a server you can already reach over SSH, with a web server (Apache or Nginx) installed and your domain's DNS already pointing at it. If your domain uses our nameservers, that's ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk and ns4.serverworld.uk, set at your registrar. Either way, Let's Encrypt has to be able to see your site over the internet on port 80 before it will issue anything: it proves you control the domain by fetching a file from it, and a domain that doesn't resolve to your server yet, or a firewall with port 80 closed, will fail every time.

One more thing worth knowing before you start: Let's Encrypt limits how many certificates you can request for the same domain in a week. It's rarely a problem in normal use, but it catches people who run the issuing command repeatedly while troubleshooting something else. More on that below.

If you're on shared, reseller or WordPress hosting, you probably don't need to do anything

cPanel includes a feature called AutoSSL, which is built on Let's Encrypt. It checks the domains on your account, issues certificates for any that don't have a valid one, and renews them automatically before they expire. You don't run a command or click an "issue certificate" button for most sites: it happens in the background on a schedule set at server level.

There are a few conditions worth knowing, because they explain the situations where AutoSSL doesn't do what people expect:

• Your DNS has to actually point here first. AutoSSL proves you own the domain the same way Certbot does, by checking that the domain resolves to the server, either through nameservers or an A record pointing at the server's IP address. If you've just added a domain and DNS hasn't propagated yet, AutoSSL will skip it until it does, on the next scheduled run.
• Wildcard certificates aren't covered by default. AutoSSL doesn't secure wildcard domains (*.example.com) unless WHM is set as the DNS provider for that domain. If you're on a reseller account and need a wildcard, that's the detail to check first.
• An existing certificate won't be silently replaced. If a domain already has a certificate that wasn't issued by AutoSSL, for instance one you uploaded yourself and let expire, AutoSSL leaves it alone rather than overwriting it. It has to be removed before AutoSSL will issue a free one in its place, and doing that creates a short window with no HTTPS on the site until the new certificate is issued, so it's worth doing at a quiet time rather than assuming it's instant.
• One certificate covers up to 200 domains, and each domain or subdomain on it has to individually pass the domain validation check. A newly added addon domain that hasn't resolved yet is simply left off the certificate rather than blocking the others.

If a domain on your account isn't showing as secured and you've confirmed DNS is pointing at us correctly, open a support ticket and we'll check the AutoSSL status for that domain.

If you're on a VPS, here's how to issue a certificate with Certbot

The rest of this guide covers a self-managed VPS running AlmaLinux 9 or Ubuntu 24.04, using Certbot with the Nginx plugin as the example (the Apache plugin works the same way, with different package names, noted below).

Step 1: Confirm DNS is pointing at your VPS

Before running anything, check that your domain resolves to your VPS's public IP address. Certbot's default validation method fetches a file over HTTP from your domain to prove you control it, so if the domain still points somewhere else (an old host, a parked page, nothing at all), issuance will fail. If you're using Hostworld's nameservers, make sure the A record for your domain is set to your VPS's IP in whichever DNS management screen you're using. This step alone accounts for most failed certificate requests, so it's worth double-checking rather than assuming it's already correct.

Step 2: Open ports 80 and 443 in the firewall

A VPS is not managed on your behalf, so nobody else opens these ports for you. Port 80 is needed for the validation check itself, and port 443 for serving HTTPS afterwards.

AlmaLinux 9 (firewalld):

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Ubuntu 24.04 (ufw):

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Step 3: Install Certbot

On AlmaLinux 9, Certbot isn't in the base repositories, so EPEL has to be enabled first. This command adds the EPEL repository and then installs Certbot along with the Nginx plugin, which lets Certbot edit your Nginx configuration directly rather than you doing it by hand:

sudo dnf install epel-release -y
sudo dnf install certbot python3-certbot-nginx -y

If you're running Apache instead, install the Apache plugin and mod_ssl in place of the Nginx package:

sudo dnf install certbot python3-certbot-apache mod_ssl -y

On Ubuntu 24.04, there are two ways to install Certbot, and it's worth choosing deliberately rather than following the first instruction you find. The Certbot project itself recommends installing via snap, because the snap version tracks upstream releases closely. But Ubuntu's own apt package also produces a fully working, publicly trusted certificate, and it's patched through Ubuntu's normal security updates rather than a separate release channel. Some VPS environments have reported the snap store being unreachable on a freshly built server, which leaves the snap method stuck with no certificate at all. For a VPS, the straightforward option is apt:

sudo apt update
sudo apt install certbot python3-certbot-nginx -y

If you'd rather use the snap package, that's a supported route too:

sudo apt install snapd -y
sudo snap install core
sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Pick one method and stick with it. Installing Certbot both ways on the same server leaves two separate copies, each with its own renewal schedule, both pointed at the same certificate files. Nothing breaks immediately, but the copy you forgot about is the one that stops renewing, and you won't notice until the certificate has expired.

Step 4: Issue the certificate

This command asks Certbot to obtain a certificate for your domain, configure Nginx to use it, and set up the redirect from HTTP to HTTPS. It's the same on both AlmaLinux 9 and Ubuntu 24.04, because Certbot's plugin handles the operating system differences internally:

sudo certbot --nginx -d example.com -d www.example.com

Replace example.com with your actual domain, and add every subdomain you want covered as a separate -d flag. If you're using the Apache plugin instead, replace --nginx with --apache.

Certbot writes the certificate files under /etc/letsencrypt/archive/, but it also creates a live/ folder containing symlinks that always point at the current certificate. Your web server configuration should reference the live/ path, never archive/ directly: Certbot's plugin sets this up correctly on its own, but if you or a script edit the Nginx configuration by hand later and point it at a dated file inside archive/, the site will keep working right up until that specific certificate expires in 90 days, at which point it fails with no warning.

A standard certificate secures the exact hostnames you list. If you want one certificate to cover a domain and every subdomain under it (a wildcard, *.example.com), that needs a different validation method: there's no single web address to fetch a file from for a wildcard, so Certbot has to prove ownership by publishing a DNS record instead, which means giving it API access to whichever DNS service manages the domain. That's a separate setup from the command above and outside the scope of this guide.

Step 5: Confirm renewal actually works

Let's Encrypt certificates are valid for 90 days and are meant to renew automatically, not be reissued by hand each time. When you install via apt on Ubuntu, a cron job is added under /etc/cron.d/certbot that checks for renewals once a day. The snap install sets up a systemd timer that runs twice a day. On AlmaLinux, check that a timer or cron entry exists rather than assuming it does; some installs need it added manually.

Rather than waiting three months to find out if renewal works, test it now with a dry run, which goes through the whole process without actually replacing your live certificate:

sudo certbot renew --dry-run

If that completes without errors, renewal is set up correctly and you don't need to think about this again. If it fails, the error output tells you what's wrong, usually a firewall or DNS issue rather than anything to do with Certbot itself.

Why you shouldn't keep re-running the issue command

Let's Encrypt limits how many new certificates it will issue for the same registered domain (the part you bought from your registrar, so example.com covers everything under it) within a week. Renewals of an existing certificate don't count against that limit, but they have their own tighter cap, and requesting a fresh certificate repeatedly while testing something, rather than letting renewal run on schedule, is the way people accidentally use it up. There's a separate, even tighter limit on duplicate certificates covering the exact same set of domain names.

If you do hit a limit, there's no way to have it reset early. It clears itself gradually over the following week rather than all at once. The practical takeaway: if a certificate request fails, fix the actual problem (DNS, firewall, wrong domain name) before trying again, rather than repeating the same command and hoping.

What next

With HTTPS running, the next thing worth checking on a VPS is that your firewall isn't left wider open than it needs to be, and that automatic updates are keeping the rest of the server patched. Have a look at our VPS guides for what to check next on a freshly configured server. If you're still deciding between managing a server yourself and having certificates handled for you, our Linux VPS plans and cPanel-based hosting both start from a domain that already resolves correctly, which is the one thing every route above depends on.

If a certificate isn't issuing and you've checked DNS, ports and the install method above, open a support ticket and we'll look at what Let's Encrypt is actually reporting back.