Bluehost SSL certificate expired

A bluehost ssl certificate expired warning means visitors hit an old Let's Encrypt or vendor leaf on your Bluehost account—not that every Bluehost server worldwide broke.

Site owners on Bluehost shared, WordPress, or VPS plans see certificate date errors on the primary domain, addon domains, or staging subdomains.

Bluehost bundles cPanel AutoSSL and a Free SSL Certificate toggle in account tools. Renewal can fail silently when addon domains lack DNS, .htaccess forces HTTPS before a cert exists, or AutoSSL exclusions block the vhost.

Start by checking TLS on the exact hostname in the browser bar, then use cPanel SSL/TLS Status before opening a chat with support.

First response

Log into Bluehost → My Sites (or Advanced → cPanel) and open SSL/TLS Status for the domain that fails. Note domains marked Excluded, AutoSSL failed, or showing an old expiration date.

From your workstation (or /check), capture openssl output for the failing hostname. Bluehost support resolves faster when you attach notAfter, issuer, and whether the domain is primary, addon, or parked.

If WordPress runs on the account, distinguish hosting TLS from plugin redirects—WordPress site SSL certificate expired covers siteurl drift after the cert is fixed.

Bluehost chat support moves faster when you attach SSL/TLS Status screenshots and external openssl output together. Note account type: shared, WordPress, or VPS changes which renewal tools are available. If multiple sites share an IP, confirm the failing domain is mapped to the correct certificate in Manage SSL Sites.

What this error means

Bluehost terminates TLS on Apache/LiteSpeed in front of your files. When the leaf expires, browsers block wp-admin, checkout plugins, and webmail on the same vhost.

AutoSSL attempts DV issuance per domain on the account. It is not magic: the domain must resolve to Bluehost, pass HTTP-01 or vendor validation, and not be manually set to exclude AutoSSL in WHM/cPanel.

Expired hosting TLS is independent of domain registration billing—but registrar holds can block revalidation later, so note registrar expiry separately.

Shared hosting presents one listener with many SNI certificates. An expired mapping for a single addon domain does not always surface in the primary domain panel. Visitors experience pure PKIX failure without application error pages. Webmail and phpMyAdmin on the same cert fail simultaneously, which helps correlate scope.

Common causes

Addon domain DNS still points elsewhere while files live on Bluehost; AutoSSL never validates the name shoppers use.

Manual commercial certs installed years ago were never replaced when AutoSSL took over, leaving Apache configured with the older PEM.

Wildcard or SAN mismatch: cert covers www only while marketing uses bare apex without redirect rules.

Staging subdomains (staging.example.com) were created in cPanel but never received AutoSSL runs.

Resource limits or ModSecurity temporarily blocked validation URLs during the last renewal window.

Migrated sites sometimes leave manual commercial certs installed while AutoSSL is disabled, hiding upcoming expiry until browsers block shoppers. Staging subdomain certificates expire quietly because traffic is low. HTTP-only validation breaks when Force HTTPS redirects exist before a cert is present.

Confirm from the outside

OpenSSL

echo | openssl s_client -connect HOST:443 -servername HOST 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Replace HOST with the public hostname users type.

How to read the output

Issuer often shows Let's Encrypt or cPanel partner CA after successful AutoSSL. If issuer is an old commercial name, Apache may still reference a manually uploaded bundle.

curl

curl -vI --connect-timeout 10 https://HOST/ 2>&1 | grep -Ei 'expire|SSL certificate|subject:|issuer:'

Bluehost / cPanel AutoSSL

In cPanel: SSL/TLS Status → Run AutoSSL (or Manage SSL sites to see which certificate Apache uses).

SSH (if enabled on your plan):

/usr/local/cpanel/bin/autossl_check --all

Watch /var/cpanel/logs/autossl/ for the domain if validation fails.

Loop openssl across primary, addon, and staging hostnames on the account. Check whether www and apex present different serial numbers indicating split vhosts.

Fix checklist

1. Confirm domain DNS A/AAAA records point to Bluehost.
2. Run AutoSSL on the failing vhost in cPanel.
3. Remove stale manual certs in SSL/TLS → Manage SSL sites if they block AutoSSL replacement.
4. Include both apex and www in redirects once a valid cert exists.
5. Reload is automatic on shared hosting; on VPS, restart httpd or LiteSpeed if instructed.
6. Re-test webmail and phpMyAdmin on the same cert if they share the vhost.
7. Enable Bluehost SSL renewal reminders or external monitoring.
8. Archive openssl proof in the ticket.

Roll out and verify

Schedule Bluehost certificate work in a window when support chat is available if AutoSSL fails twice—reseller branding does not change underlying cPanel behavior. Export current Manage SSL Sites mappings before deleting manual bundles so you can roll back if a commercial cert was intentional.

After AutoSSL succeeds, walk every addon domain on the account, not only the one that alerted first. Bluehost accounts often host staging subdomains that share an IP but use distinct vhosts with separate expiry dates. Hit each with openssl in a short loop and paste outputs into your change record.

Verification includes webmail, cPanel login on the shared URL, and WordPress cron if DISABLE_WP_CRON is false. Mobile browsers on guest Wi‑Fi catch split-horizon DNS mistakes that desktop VPN tests miss. Compare Bluehost panel expiration with live notAfter; they should match within minutes once AutoSSL finishes.

If you plan migration away from Bluehost, still renew until cutover completes. Letting TLS expire mid-migration produces the worst combination: broken DNS validation on the new host and angry customers on the old one.

Update Bluehost portal contacts for AutoSSL emails. After renewal, walk client WordPress dashboards that cache https asset URLs.

When to use automation

Certificate files on disk and green panels lie until a stranger's TLS handshake succeeds. Schedule live checks on the exact hostname shoppers or API clients resolve, including redirects and the certificate presented after your platform edge terminates the connection. Pair TLS notAfter with RDAP domain registration data so revalidation is not blocked by registrar billing.

Run a one-shot proof on /check, then add the production hostname to monitoring with alerts at 30, 14, 7, and 1 day thresholds. ssldays reads the live chain external users see—useful when shared hosting, PaaS edges, or CMS layers each claim TLS is fine.