BigCommerce SSL certificate errors

BigCommerce SSL certificate errors usually mean your custom store domain still hits expired infrastructure—or DNS never finished pointing at BigCommerce's managed TLS.

Merchants see bigcommerce ssl certificate expired warnings on the storefront URL, checkout, or embedded scripts while BigCommerce admin still looks healthy. The failure is almost always on the custom domain path, not on *.mybigcommerce.com.

Teams often renew a certificate on a old origin server after migrating to BigCommerce, or leave apex DNS on a parked host while only www uses BigCommerce CNAMEs. Browsers judge the hostname in the address bar, not where the catalog database lives.

This runbook proves TLS on the live store domain, walks through BigCommerce domain connection checks, and ends with the same openssl and curl commands that should pass before you close the ticket.

First response

Open Server Settings → Domain & URLs (or Store Setup → Store Profile → Domains) and note whether the custom domain shows Connected with a valid SSL state. Capture the exact URL customers use (www vs apex), then run openssl against that hostname from an external network—not only from your laptop on VPN.

Screenshot the browser interstitial (NET::ERR_CERT_DATE_INVALID, SEC_ERROR_EXPIRED_CERTIFICATE, or checkout failures) and paste openssl notAfter output into the incident channel. If you still operate a headless front or partner subdomain on your own metal, test those hostnames separately; BigCommerce-managed TLS does not cover infrastructure you did not delegate.

See Shopify SSL certificate errors when comparing SaaS commerce TLS and How to fix an expired SSL certificate for generic renew → reload discipline.

Document whether shoppers hit apex or www in analytics before you change DNS. Capture checkout partner callbacks that terminate TLS on your infrastructure.

What this error means

BigCommerce provisions and renews TLS for custom domains once DNS validates per their current documentation. Until that handshake succeeds, shoppers receive a PKIX failure even if the control panel eventually shows SSL pending or provisioned.

An expired certificate on a non-BigCommerce host in the DNS chain still breaks assets. Storefront themes, analytics pixels, or app embeds that load from cdn.yourbrand.com inherit whatever TLS that hostname presents. Admin may report SSL ready while the public www record still resolves to last year's server IP.

PKIX does not grant grace because you moved platforms: notAfter on the leaf must be in the future, intermediates must chain, and the SAN list must include the name in the URL bar.

Managed commerce platforms decouple application uptime from custom-domain TLS. The database and admin API can respond while the storefront hostname shoppers bookmarked still presents an expired leaf from a prior hosting era. Payment wallets and mobile apps pin HTTPS hosts and will not follow an HTTP downgrade. Treat custom-domain TLS as production-critical even when the default mybigcommerce.com URL loads cleanly.

Common causes

DNS split brain is the most common pattern: apex A/ALIAS still points at expired shared hosting while www CNAME targets BigCommerce. Marketing emails deep-link to the apex and trigger errors.

Incomplete domain setup leaves BigCommerce unable to complete DV validation—SSL stays pending until CNAME/A records match the values shown in domain settings. Teams change DNS at the registrar but forget to remove stale proxy orange-cloud records that hide the correct target.

Headless or hybrid stacks keep TLS on a Node/Vercel storefront while checkout posts to BigCommerce; only the layer customers browse must be renewed on your side.

Legacy redirects on an old nginx box terminate HTTPS with an expired default certificate before forwarding to BigCommerce, so openssl shows expired material even though BigCommerce itself is fine.

Stencil theme assets pulled from a photographer CDN subdomain often escape renewal calendars focused on www only. B2B portals on a separate hostname may still terminate on a partner reverse proxy outside BigCommerce. Email deep links using bare domains bypass www CNAME fixes until apex records migrate. Marketplace connectors sometimes validate TLS on return URLs you control, not on BigCommerce core endpoints.

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

Compare notAfter with BigCommerce's expected issuance window. Issuer is typically a public CA (Let's Encrypt or DigiCert) once provisioning completes—not your old host's cPanel vendor.

curl

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

BigCommerce admin checks

In admin, open the domain row and use Check connection or the SSL status indicator. If the domain is not connected, fix DNS at the registrar first; do not upload manual PEM files to BigCommerce for standard custom domains.

For stencil/CDN asset hosts you control, run:

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

Replace STOREDOMAIN with the hostname shoppers use.

Test store, apex, and callback URLs with the same openssl invocation, saving serial numbers in the ticket. If Cloudflare or another proxy sits in front, run checks in DNS-only or bypass mode temporarily to see origin dates without edge substitution. Compare BigCommerce admin domain status timestamps with external notAfter to catch delayed provisioning.

Fix checklist

1. List every hostname linked in Domain & URLs (apex, www, regional TLDs).
2. Align DNS with BigCommerce's live docs (CNAME for www, ALIAS/flatten for apex where required).
3. Remove conflicting orange-cloud or reverse-proxy records until validation completes.
4. Wait for automatic SSL provisioning after DNS propagates (often minutes, sometimes hours).
5. Renew or remove TLS on any non-BigCommerce host still in the asset path.
6. Place a test order on the custom domain over mobile LTE.
7. Re-run openssl until notAfter is months ahead.
8. Document which hostname each marketing channel uses.

Roll out and verify

Procurement for a BigCommerce custom domain is primarily DNS alignment, not uploading a CSR. Collect every hostname shoppers type, including alternate TLDs and campaign vanity paths, then ensure each either targets BigCommerce or has a deliberate certificate owner documented elsewhere. Screenshot domain rows in admin before changes so support can diff status transitions.

Installation on BigCommerce is automatic once DNS validates; your work is removing competing TLS on hosts still in the path. Decommission expired certificates on retired nginx boxes that answer apex A records, and update partner integrations that pin old intermediates. If apps embed third-party scripts from your domain, renew those listeners or proxy them behind a CDN with valid edge TLS.

Verification must exercise checkout, account login, and B2B portals on cellular networks without corporate trust stores. Re-run the openssl command from the ticket opener and compare serial numbers. Place a low-value test order with the custom domain in the address bar and confirm payment iframes load without mixed-content or date errors. Feed store, apex, and asset hostnames into live monitoring before marketing campaigns resume.

Communication should separate BigCommerce platform status from infrastructure you manage. Executives care that the public store hostname shows a future notAfter, not whether a legacy VPS was renewed. Document who owns DNS at the registrar versus who owns BigCommerce admin access.

Notify app partners after issuer changes. Archive CT log entries for the new leaf if provisioning stalls.

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.