SSL certificate management for six domains and no budget comes down to one thing: knowing which vhost is serving which cert and when. Issuance is the easy part. Let’s Encrypt gives you free certs, cPanel has a plugin, and you can set it to auto-renew. The hard part is tracking what’s actually deployed across six domains on one shared account, because cPanel won’t do that for you in any sane way.
The actual problem with six domains on one cPanel account
cPanel’s SSL/TLS Status page lists all your domains and shows a green lock or a warning. That’s fine for a quick glance. But it doesn’t tell you which certificate each domain is using, when that cert expires, or whether the auto-renewal actually replaced the old one. You can click into each domain and check the certificate details, but that’s six clicks and a lot of scrolling. And if one domain is serving the wrong cert—maybe it’s still on an old self-signed cert from when you first set up the account—the status page might just show a warning that’s easy to miss.
I’ve seen this happen on my own setup. The cPanel Let’s Encrypt plugin works, but it doesn’t always deploy the cert to every vhost the way you’d expect. I wrote about that in ssl certificate lifecycle management in cPanel when the deploy hook never runs. The deploy hook is supposed to run after renewal, but sometimes it doesn’t, and then you’re left with a cert that’s valid but not actually being served. That’s the kind of thing that will drive you crazy if you’re not tracking it.
What you actually have to track
For six domains, you need a simple spreadsheet or a text file. I use a plain text file because it’s easy to grep. For each domain, track:
- The domain name
- The certificate’s common name and SANs (Subject Alternative Names)
- The issuer (Let’s Encrypt, cPanel AutoSSL, or something else)
- The expiration date
- The date the cert was last renewed
- Whether the cert is actually being served (you can check with
openssl s_clientor a browser) - Any notes, like “deploy hook failed, manually copied cert”
I check this file once a week. It takes five minutes. I run a quick openssl s_client -connect domain.com:443 -servername domain.com for each domain and compare the output to what’s in my file. If the serial number or expiration date changed, I update the file. If a domain is serving a cert that’s about to expire, I know to investigate.
You could automate this with a script. There are plenty of monitoring tools that will check SSL certs and alert you before they expire. But for six domains, a manual check is fine. The key is to do it regularly. I’ve had certs expire because I forgot to check for a month, and then a client’s site went down. That’s a bad look.
Why the deploy hook fails and what to do about it
The cPanel Let’s Encrypt plugin uses a deploy hook to copy the new cert to the right places after renewal. When it fails, you get a valid cert that isn’t being served. The plugin might show the cert as installed, but the web server is still using the old one. That’s the worst case because everything looks fine until the old cert expires.
I’ve had this happen twice. The first time, I didn’t notice for a week because I wasn’t checking. The second time, I caught it the same day because I was running my weekly check. The fix is usually to manually run the deploy hook or to reinstall the cert through cPanel’s interface. But the real lesson is that you can’t trust the plugin’s status page. You have to verify what’s actually being served.
If you’re using a shared cPanel account, you might not have shell access to run openssl commands. In that case, you can use an online SSL checker or a browser’s developer tools to view the certificate. The important thing is to check from outside your own network, because some hosting providers serve different certs internally.
What I’d do differently at a larger scale
If I had twenty domains instead of six, I’d automate the tracking. There are scripts that will check all your domains and output a report. You could run that as a cron job and email yourself the results. But for six domains, that’s overkill. The manual check is fine, and it forces me to actually look at the certs instead of ignoring an automated report.
I’d also consider using a different hosting setup. A shared cPanel account is convenient, but it’s not great for managing multiple domains with different certs. If I had the budget, I’d move to a VPS where I could use something like Certbot directly. But that’s a different conversation.
The monitoring angle
You might think a website monitoring service would catch SSL cert problems. It won’t, not reliably. I wrote about that in website monitoring service: an uptime monitor that pages you for the wrong thing is worse than none. Most uptime monitors only check if the site is up. They don’t check the SSL cert unless you specifically configure them to. And even then, they might only check if the cert is valid, not if it’s the right cert. So you still need to do your own tracking.
What the paid alternatives actually cost
There are paid SSL certificate management tools out there. They range from simple trackers to full-blown certificate lifecycle management platforms. Most of them are overkill for six domains. The pricing models vary: some charge per certificate, some per domain, some per year. At the time of writing, a typical paid SSL cert from a commercial CA costs around $50 to $100 per year per domain, but you don’t need that if you’re using Let’s Encrypt. The management tools are usually priced per domain per month, often starting at a few dollars per domain. For six domains, that’s maybe $20 to $50 per month. Not worth it when a text file and five minutes a week does the job.
The only time I’d pay for a management tool is if I had dozens of domains and couldn’t keep track manually. Or if I needed compliance reports for an audit. For a homelab or a small business with six domains, the free approach is fine.
If you’d rather pay for this
If you want to remove the manual tracking entirely, you could look at a service like SSL.com’s certificate manager or a similar tool from a commercial CA. These are typically priced per certificate or per domain, often on an annual basis. At the time of writing, some charge around $10 per domain per year for management on top of the cert cost. That’s not terrible, but it’s still money you don’t need to spend if you’re willing to spend five minutes a week checking your certs yourself.
For a homelab or a small site, I’d skip the paid tools. The free approach works fine. The only exception is if you’re managing certs for clients and you need to prove compliance or hand off the tracking to someone else. In that case, the per-domain fee might be worth it just to have a dashboard you can screenshot. But for six domains on a shared cPanel account, a text file is all you need.
