August 12, 2026

HTTPS and SSL certificates for small business: what happens when yours expires (and how to make sure it never does)

Your website was working yesterday. Today, every visitor sees a blood-red full-page warning that says "Your connection is not private" and most of them are hitting the back button before they finish reading it. Your SSL certificate expired at 3am and nobody noticed until the phones stopped ringing.

This is one of the most common preventable outages I see, and it's almost always caused by something boring: a renewal script that quietly stopped working six weeks ago.

What HTTPS actually does for your business

The padlock icon in the browser bar does three things, and all of them matter:

Encrypts traffic. When someone fills out a contact form or types a credit card number, HTTPS scrambles it so nobody sitting between their laptop and your server can read it. Without it, anyone on the same coffee-shop Wi-Fi can grab that data.

Verifies you're really you. The certificate is signed by a trusted authority (like Let's Encrypt, DigiCert, or Sectigo) that has confirmed you actually control the domain. This is what stops someone from spinning up a fake copy of your site to phish your customers.

Unlocks modern web performance. HTTP/2 and HTTP/3 — the protocols that make sites load fast — only run over HTTPS. Google also uses HTTPS as a ranking signal and has since 2014. If you're not on HTTPS, you're slower and less visible than every competitor who is.

For a small business site, HTTPS isn't optional anymore. Chrome, Safari, and Firefox all flag non-HTTPS sites as "Not Secure" in the address bar, which is a great way to lose a lead before they've read your homepage.

What actually happens when your certificate expires

Here's the sequence when a cert lapses:

1. Browsers block the site. Every modern browser shows a full-page interstitial warning. It looks identical to what you'd see if the site were actively serving malware. Most visitors — even technical ones — turn around.
2. Google starts dropping rankings. Googlebot can still crawl, but repeated fetch errors and the security warning signal a broken site. If it stays down long enough, you'll see rankings slide within a week.
3. Email deliverability can degrade. If your domain uses HTTPS-based verification for anything (webhooks, third-party integrations, some DMARC reporting endpoints), those quietly break. If your MX and web share a certificate, mail can bounce.
4. Integrations break silently. Stripe, payment gateways, booking software, Zapier webhooks — anything that talks to your site over HTTPS will refuse to connect. You may not notice until a customer calls to say their card was declined.

The worst part: to a regular visitor, an expired cert looks exactly like a hacked site. You lose trust, not just traffic.

Let's Encrypt is the right choice for most small businesses

Let's Encrypt is a free, automated certificate authority backed by Mozilla, Cisco, the EFF, and a bunch of others. It issues the same kind of domain-validated (DV) certificate you'd pay $50–$200/year for elsewhere. Every browser trusts it.

The catch — which is actually a feature — is that Let's Encrypt certs are only valid for 90 days. That short window forces automation. If your setup can't renew itself, you'll find out fast, not two years later when you've forgotten how any of it works.

If you're on shared hosting (Bluehost, SiteGround, WP Engine, Kinsta, Cloudways, etc.), Let's Encrypt is almost certainly built in and enabled by default. You don't need to think about it.

On a VPS or dedicated server, you install certbot and let it handle renewals via a systemd timer:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
sudo systemctl status certbot.timer

That last line confirms the renewal timer is active. Certbot will attempt renewal twice a day and only actually renew when the cert is within 30 days of expiring.

When you actually need a paid certificate

Free certs work for the vast majority of small businesses. You need paid — specifically Organization Validated (OV) or Extended Validation (EV) — in a few narrow cases:

• Regulated industries. Banks, credit unions, healthcare providers handling PHI, and some legal/financial services often have compliance requirements or vendor policies that mandate OV/EV.
• Warranty coverage. Paid CAs offer warranties (usually $10K–$1.75M) that reimburse end users if the cert is mis-issued and they lose money. It almost never pays out, but some B2B contracts require it.
• Wildcard or multi-domain complexity. Let's Encrypt supports wildcards, but if you're managing dozens of subdomains across multiple environments with strict change control, a paid wildcard from DigiCert or Sectigo can be easier to operate.
• Longer validity for internal systems. Public certs max out at 398 days (dropping to 47 days over the next few years). Paid certs on internal CAs can be longer.

If none of that describes you, use Let's Encrypt and put the $200/year toward something that actually moves the needle.

Setting up auto-renewal so you never think about this again

The renewal path depends on your setup:

• cPanel hosting: Look for "AutoSSL" in cPanel. Enable it for your domain and all subdomains. It runs weekly and installs Let's Encrypt certs automatically.
• Plesk: The "SSL It!" extension does the same thing. Turn on "Keep websites secured" and "Renew automatically."
• Managed WordPress hosts (WP Engine, Kinsta, Flywheel): SSL is included and auto-renewed. You just need to make sure your domain's DNS actually points to them.
• VPS with Nginx or Apache: Use certbot's systemd timer (installed automatically on modern Ubuntu/Debian). Verify with systemctl list-timers | grep certbot.
• Cloudflare in front of your origin: Cloudflare's "Universal SSL" handles the edge cert automatically. You still need a cert on your origin server — set the origin to "Full (strict)" mode and use a Cloudflare-issued origin certificate valid for 15 years.

Whatever the setup, do one thing after you configure it: test the renewal manually. On certbot: sudo certbot renew --dry-run. If it fails, you want to know today, not 89 days from now.

Monitoring is not the same as uptime monitoring

This is where I see small businesses get burned. UptimeRobot or Pingdom is set up to check https://yourdomain.com every 5 minutes. Great. But most uptime tools by default just check that the site returns a 200 status code. If your cert expires, the site still returns 200 to the monitoring tool — because monitoring tools often ignore certificate errors.

You need a monitor specifically configured to alert on certificate problems. In UptimeRobot, this is the "SSL/TLS" monitor type, which alerts you 30, 14, and 7 days before expiry. Set it up alongside your normal uptime check, not instead of it.

Better yet, use both:

• HTTP(S) uptime monitor: site is reachable
• SSL certificate monitor: cert is valid and >14 days from expiring
• Optionally, a keyword monitor that checks a specific string appears on the homepage (catches the case where the site loads but is showing a WordPress error or a hacked defacement page)

Free tier of UptimeRobot covers all three for a single site.

Why renewals fail (and how to catch it)

The four most common silent failure modes:

1. DNS changed and nobody updated the cert config. You migrated to a new host, but the old server is still trying to renew a cert it can't validate.

2. HTTP-01 challenge blocked. Let's Encrypt validates domain ownership by fetching a file over HTTP (port 80). If you or your host has locked down port 80, or a firewall/WAF is blocking the Let's Encrypt IPs, renewal fails. Solution: use DNS-01 challenge instead, which validates via a TXT record.

3. Cert covers yourdomain.com but not www.yourdomain.com (or vice versa). Half your visitors see the padlock, the other half see a warning. Always issue for both.

4. Rate limits. Let's Encrypt allows 5 duplicate certs per week. If a broken script is looping, you can burn through the limit and get locked out for days. Watch your renewal logs.

Recovering from an expired cert

If it's already happened, don't panic. You can be back up in under an hour if you know what you're doing:

1. Confirm the expiry (check https://yourdomain.com in an incognito window, or run openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates)
2. Force a manual renewal: sudo certbot renew --force-renewal
3. If that fails, issue a fresh cert: sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
4. Restart the web server: sudo systemctl reload nginx (or apache2)
5. Test in a fresh browser session — Ctrl+Shift+R to bypass the cache
6. Then figure out why it failed and fix the underlying automation

The site being down for an hour on a Tuesday afternoon is annoying. The site being down for three days because nobody notices the expiry until Monday morning is a real problem.

Getting this off your plate

If you're running a small business, you should not be spending your Tuesday reading certbot logs. This is exactly the kind of thing that should be silently handled in the background — set up once, monitored continuously, and only ever surface as an alert if something actually needs your attention.

The site hardening work I do for small business WordPress sites includes SSL setup with Let's Encrypt, automated renewal, dual monitoring (uptime + certificate), and alerting that goes to me first so I can fix issues before you find out about them. Same principle as when I cleaned up a Southern California contractor's WordPress site after a previous developer left them with a self-healing backdoor and 115+ spam posts — the goal is that boring stuff stays boring.

If your certificate situation is currently "I have no idea when it expires or who set it up," that's worth a conversation. Take a look at the site hardening service at thewizrdz.io or send me a note through the contact form. Better to sort it out on a calm Tuesday than a chaotic Sunday night.