This article is meant to teach you how to install a free SSL certificate on your cPanel shared hosting website using Certbot, run from your own computer. By the end you will have a real, browser-trusted Let’s Encrypt certificate on your site, and you will understand how to keep it renewed, without ever needing root or SSH access to the hosting server itself.
The reason this approach exists is simple. Most Certbot guides assume you can run it directly on the web server, which on shared hosting you usually cannot, because you do not have administrator access to that machine. The method here sidesteps that completely: you run Certbot on your own Mac (or other computer), prove you control the domain through a DNS challenge, and then paste the resulting certificate into cPanel by hand. The instructions below lead with macOS, since that is the most common setup, and cover Linux and Windows afterward.
One thing to be upfront about, because it shapes the whole guide: the simplest version of this method cannot renew itself automatically, and Let’s Encrypt certificates last only about ninety days. We cover the simple manual method first because everyone should understand it, then explain exactly why automation is awkward on registrars like Namecheap and NameSilo, and finally show the one approach that genuinely does automate it for them.
What a DNS challenge is, and why it suits shared hosting
Before a certificate authority like Let’s Encrypt issues a certificate, it has to confirm you actually control the domain. There are several ways to prove this, and the one that works no matter where your site is hosted is the DNS challenge. Instead of placing a file on the web server, you prove control by creating a special TXT record in your domain’s DNS. Because you manage DNS separately from your hosting — through your registrar or a dedicated DNS provider — you can complete this challenge from anywhere, including your own computer. That is precisely why it works for shared hosting: it avoids the server entirely.
Step one: install Certbot on macOS
On a Mac, the cleanest way to install Certbot is through Homebrew, the popular macOS package manager. If you do not already have Homebrew, install it first from brew.sh, then run:
brew install certbot
That is all macOS needs. You can confirm it installed by running certbot --version, which should print a version number. Note that Certbot needs administrator rights on whatever machine it runs on, and on your own Mac you legitimately are the administrator — which is the entire reason this method works where running it on the shared host would not.
Installing Certbot on Linux or Windows
If you are on Linux rather than a Mac, install Certbot through your distribution’s package manager. On Debian or Ubuntu that is:
sudo apt update && sudo apt install certbot
On Windows, the simplest path is to use WSL (the Windows Subsystem for Linux), which gives you a real Ubuntu environment where the Linux command above works exactly as written. Install WSL from an elevated PowerShell with wsl --install, open the Ubuntu shell it provides, and follow the Linux instructions from there. On any system with Python available, pip install certbot is also an option. Whichever OS you use, the rest of this guide is identical from this point on.
Step two: request the certificate with a manual DNS challenge
With Certbot installed, request a certificate for your domain using the manual DNS method. On macOS, Homebrew-installed Certbot may not need sudo; if you get a permissions error, add sudo in front. On Linux it generally does need sudo:
certbot certonly --manual --preferred-challenges dns -d example.com -d www.example.com
Replace example.com with your own domain. The certonly part tells Certbot to obtain the certificate but not try to install it into a web server, which is correct here since the server is elsewhere. The --manual flag means Certbot will pause and ask you to complete the challenge by hand, and --preferred-challenges dns selects the DNS method.
Certbot will print something like “Please deploy a DNS TXT record” and show you two things: a record name that looks like _acme-challenge.example.com, and a long string of characters that is the record’s value. Leave this terminal window open and do not press Enter yet, because the next step happens elsewhere.
Step three: create the TXT record in your DNS
Log in to wherever your DNS is managed. For most shared-hosting users this is your registrar — Namecheap, NameSilo, GoDaddy, and the like. In Namecheap this lives under Domain List, then Manage, then the Advanced DNS tab; in NameSilo it is on the domain’s page under the DNS Records section. Wherever it is, add a new record: the type is TXT, the name or host is the _acme-challenge value Certbot gave you (some providers want the full _acme-challenge.example.com and some only the _acme-challenge part, since they append the domain automatically), and the value is the long string Certbot displayed.
Save the record. DNS changes can take a few minutes to propagate, so wait a short while before continuing. On macOS or Linux you can confirm the record is live with dig +short TXT _acme-challenge.example.com, or use an online tool such as whatsmydns.net. Only once you can see the TXT record returned should you go back to the Certbot terminal and press Enter. Certbot then asks Let’s Encrypt to check the record, and if it matches, your certificate is issued.
Step four: find your certificate files
On success, Certbot saves your certificate and key to a folder on your computer and prints the exact path. On macOS with Homebrew this is typically under /opt/homebrew/etc/letsencrypt/live/example.com/ (or /usr/local/etc/letsencrypt/... on Intel Macs); on Linux it is usually /etc/letsencrypt/live/example.com/. Inside that folder are the files you need:
cert.pem— your domain’s certificate (this goes in the CRT field in cPanel)privkey.pem— the private key (this goes in the KEY field)chain.pem— the certificate authority bundle (this goes in the CABUNDLE field)fullchain.pem— the certificate and chain combined, which some setups prefer
Open each of the three files you need in a plain text editor. On a Mac you can reveal the folder quickly with open /opt/homebrew/etc/letsencrypt/live/example.com/ in Terminal. Each file’s contents begin with a -----BEGIN----- line and end with a matching -----END----- line, and you must include those header and footer lines when you copy.
Step five: install the certificate in cPanel
Log in to cPanel and, in the Security section, open SSL/TLS. Under “Install and Manage SSL for your site (HTTPS),” click Manage SSL sites. You will see a form with a domain dropdown and three large text boxes.
Select your domain from the dropdown, then fill the three boxes from the files you opened: paste the contents of cert.pem into the Certificate (CRT) box, privkey.pem into the Private Key (KEY) box, and chain.pem into the Certificate Authority Bundle (CABUNDLE) box. Including the BEGIN and END lines in each is important, because cPanel reads those markers to know where each block starts and ends. When all three are filled, click Install Certificate. cPanel confirms with a success message, and your site is now served over HTTPS with a trusted certificate.
At this point you can delete the temporary TXT record from your DNS; it was only needed to prove control during issuance.
Checking how many days until your certificate expires
Since the manual method relies on you remembering to renew, it helps to know exactly how much time you have left. You can check the expiry date straight from your own machine using OpenSSL, which is already installed on macOS and Linux.
On macOS, the quickest check is to query your live site directly, which tells you what visitors are actually seeing:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate
That prints a line like notAfter=Sep 12 14:30:00 2026 GMT, which is the exact moment the certificate stops being valid. You can run the same command on Linux, and on Windows inside your WSL Ubuntu shell, unchanged.
If you would rather check the certificate file sitting on your computer instead of the live site, point OpenSSL at the cert.pem Certbot saved:
openssl x509 -enddate -noout -in /opt/homebrew/etc/letsencrypt/live/example.com/cert.pem
To go one step further and have your Mac tell you whether the certificate will still be valid at some point in the future, OpenSSL can answer a yes/no question. The command below checks whether the certificate has more than thirty days left — the number is given in seconds, so thirty days is 2592000:
openssl x509 -checkend 2592000 -noout -in /opt/homebrew/etc/letsencrypt/live/example.com/cert.pem \
&& echo "Still valid for more than 30 days" \
|| echo "Expires within 30 days — time to renew"
If you prefer not to touch the command line at all, you can always click the padlock icon in your browser’s address bar while viewing your site and look at the certificate details, which include the expiry date in plain language. But the OpenSSL checks above are handy because they let you set a reminder based on the real date rather than guessing.
Why you cannot easily automate renewal on Namecheap or NameSilo
This is the part most guides gloss over, so here is the honest picture. The --manual method cannot renew on its own, because Certbot has no way to recreate that TXT record for you — it does not have access to your DNS account. The usual fix elsewhere is a Certbot DNS plugin, which talks to your DNS provider’s API and creates the challenge record automatically on every renewal. Certbot maintains official plugins for a specific set of providers: Amazon Route 53, Cloudflare, Google Cloud DNS, DigitalOcean, DNSimple, DNS Made Easy, Gehirn, Linode, LuaDNS, NS1, OVH, and any server supporting the RFC2136 standard.
Notice who is not on that list: the registrars most shared-hosting users actually use, including Namecheap, NameSilo, and GoDaddy. There is no official Certbot plugin for any of them. NameSilo has a public API but only unofficial, community-maintained plugins of varying reliability. Namecheap is harder still: it has an API, but access is gated. To even switch it on, Namecheap requires your account to meet one of these thresholds — at least 20 domains, or at least $50 in account balance, or at least $50 spent in the last two years — and then you must whitelist the specific IP address that will make the calls, and only IPv4 addresses are accepted. For a typical person with one or two domains running from a home internet connection, that is a non-starter: you likely do not meet the threshold, and even if you did, home IP addresses change, which would silently break the whitelist and the renewal with it.
So for this audience there are realistically two honest options. The first is to simply accept manual renewal: when the certificate nears its ninety-day expiry, repeat the process — run the command again, create a fresh TXT record, paste the new files into cPanel — and set a calendar reminder for every sixty days so you never get caught out. Plenty of small sites run exactly this way and it is perfectly fine. The second option, for those who want true automation despite their registrar, is CNAME delegation, described next.
The automation that works anyway: CNAME delegation
There is a clever technique, endorsed in Certbot’s own documentation, that lets you automate renewals even when your registrar has no usable plugin. The idea is to hand off just one tiny piece of your DNS — the challenge record — to a service that does have a plugin, while leaving everything else (your website, your email, your nameservers) exactly where it is at Namecheap or NameSilo. You do this with a CNAME record, and the beauty of it is that you set it up only once.
Here is how it works in principle. When Let’s Encrypt checks your challenge, it looks up _acme-challenge.example.com. A CNAME record is essentially a redirect for a DNS name. So you create, one time, a CNAME at your registrar that points _acme-challenge.example.com to a hostname on a DNS provider you control that has a Certbot plugin. From then on, every time Certbot needs to prove control, it writes the TXT record over on that plugin-supported provider automatically, and the CNAME silently redirects Let’s Encrypt’s lookup to find it there. Your registrar is never touched again.
The setup looks like this. First, create a free account on a DNS provider that has a Certbot plugin and add a zone you control there (a spare domain, or even a subdomain delegated for this purpose). Then, at Namecheap or NameSilo, add a single CNAME record: the host is _acme-challenge and the target (value) is the hostname on the plugin-supported provider where the challenge will live, for example _acme-challenge.example.com.your-acme-zone.net. Save it, and that is the only change you ever make at your registrar.
From that point, you run Certbot with the DNS plugin for the provider you delegated to, supplying its API credentials in a small file. On macOS with Homebrew the shape is:
# Install the DNS plugin for the provider you delegated to
brew install certbot-dns-PROVIDER
# Store that provider's API credentials in a file
mkdir -p ~/.secrets
echo "dns_PROVIDER_api_token = YOUR_TOKEN_HERE" > ~/.secrets/dns.ini
chmod 600 ~/.secrets/dns.ini
# Request the certificate; the plugin writes the TXT record on the
# delegated zone, and your registrar's CNAME redirects the lookup there
certbot certonly \
--dns-PROVIDER \
--dns-PROVIDER-credentials ~/.secrets/dns.ini \
-d example.com -d www.example.com
On Linux the only difference is installing the plugin through your package manager. Replace PROVIDER with whichever plugin-supported DNS service you chose. Because the plugin can now manage the challenge record itself, renewal becomes hands-off: Certbot installs a scheduled task that runs certbot renew automatically, and it succeeds without you lifting a finger. Confirm it works with certbot renew --dry-run.
The remaining piece: getting the renewed cert into cPanel
There is one honest limitation even with delegation working perfectly, and it is specific to shared hosting. Certbot now renews the certificate automatically on your computer, but cPanel still has the old certificate installed and no way to reach into your machine and pull the new one. So the renewed certificate still has to be pushed up to cPanel. You have two options. The straightforward one is to paste the renewed files into cPanel by hand each time, exactly as in step five — the renewal itself is automatic even if the upload is not, which is still a big improvement. The advanced one, for the technically confident, is a Certbot deploy hook that calls cPanel’s API to upload the certificate automatically after each renewal, using cPanel’s UAPI SSL::install_ssl function. That is beyond a first SSL install, but it is the final step toward a pipeline that is automatic end to end.
Which path should you choose?
If you want the simplest route and do not mind a recurring reminder, use the manual DNS method and re-issue every couple of months — for one or two sites on Namecheap or NameSilo, this is genuinely the most sensible choice. If you would rather set things up once and stop thinking about expiry, use CNAME delegation to a plugin-supported DNS provider, and decide whether the cPanel upload stays manual or gets automated with a deploy hook. Either way, you end up with a free, fully trusted SSL certificate on shared hosting without ever needing root access to the server.
One last note: many cPanel hosts offer a built-in free SSL feature called AutoSSL, which issues and renews certificates for you with no command line at all. If your host has it enabled, it is the easiest option of all. But when AutoSSL is unavailable or disabled, the Certbot-from-your-own-computer method in this guide is the reliable way to get the same result on your own terms.