Netlify SSL certificate expired

Netlify ssl certificate expired (or failed to renew) means visitors see certificate date errors on your custom domain while something.netlify.app may still be fine.

Netlify terminates TLS on its CDN. Your git push does not renew certificates—DNS ownership and domain verification records do.

External openssl on the custom domain is the first step; Netlify UI status can lag behind live presentation during propagation.

First response

In Netlify: Site configuration → Domain management, note each custom domain’s certificate status, HTTPS provision date, and any “DNS verification failed” banners. Copy the Netlify subdomain (yoursite.netlify.app) for comparison testing.

Run openssl on the broken custom domain and on the default netlify.app host. If you use external DNS, export current A/AAAA/CNAME/ALIAS records and compare to Netlify’s required targets.

List recent DNS provider changes, apex flattening moves, or email forwarding DNS edits that might have removed validation records. Capture whether HTTPS → Force SSL or HSTS is enabled.

If the site uses Netlify DNS, export the full zone before edits. External DNS with partial delegation (subdomain NS to Netlify, apex elsewhere) produces certificates that renew for one label and expire on another—common in netlify ssl certificate expired tickets after marketing buys www on a subdomain product.

What this error means

Netlify issues and renews Let’s Encrypt certificates for domains verified on your site. When renewal cannot complete, the edge may continue serving an expired leaf or fall back to errors on SNI for that hostname. Browsers perform PKIX checks independently of your build status.

Apex domains often need ALIAS/ANAME or Netlify DNS; mispointed A records to old IPs bypass Netlify entirely and present whatever certificate runs on that orphan server—commonly mistaken for “Netlify expired.” Netlify ssl certificate expired properly means the Netlify edge is serving stale material for a domain listed in your site’s domain panel.

Common causes

DNS moved from Netlify DNS to a registrar without copying Netlify verification records breaks auto-renewal silently until expiry.

Multiple Netlify sites claim the same apex domain; only one can hold the certificate. IPv6 AAAA records pointing away from Netlify while A records are correct cause split-brain validation failures.

Wildcard needs follow vendor docs; partial hostname coverage leaves www valid while apex expires. Enterprise setups with external DNSSEC errors block Let’s Encrypt lookups.

Very long CNAME chains or CDN in front of Netlify custom domain can cause Netlify to stop managing TLS for that label. Subdomain takeover after site deletion leaves DNS pointing at Netlify’s infrastructure with no active cert.

Large Media Library assets on cdn.netlify.app or transformed image URLs may still load while HTML host fails—do not treat partial loads as proof TLS is fine. Branch subdomain certificates rotate independently; a marketing vanity domain on another host does not cover your Netlify custom label.

Confirm from the outside

echo | openssl s_client -connect www.yourbrand.com:443 -servername www.yourbrand.com 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer -serial

Compare to Netlify default host:

echo | openssl s_client -connect yoursite.netlify.app:443 -servername yoursite.netlify.app 2>/dev/null \
  | openssl x509 -noout -dates -subject

curl -vI --connect-timeout 15 https://www.yourbrand.com/ 2>&1 \
  | grep -Ei 'expire|SSL certificate|server:'

CLI (with Netlify auth):

netlify status
netlify api getSite --data '{"site_id": "YOUR_SITE_ID"}' | jq '.ssl_url, .custom_domain'

How to read the output

If only the custom domain shows past notAfter, focus on Domain management → HTTPS for that label. If both fail, open a Netlify support ticket with openssl output. If openssl hits a non-Netlify issuer, DNS no longer routes through Netlify—fix records before renewing anywhere else.

Browser spot-check

Test logged-out incognito on the failing host. Netlify Identity and OAuth redirects amplify certificate errors because providers refuse callback URLs with bad TLS.

Fix checklist

Work this list in order for Netlify SSL certificate expired. Paste openssl serials into the ticket after steps 6 and 7 so marketing knows when it is safe to resume ad campaigns.

1. Domain management → select domain → Verify DNS configuration; fix A/ALIAS/CNAME per Netlify’s live checklist.
2. Remove duplicate domain attachments on other Netlify sites or delete orphaned site.
3. Click Renew certificate / Provision certificate after DNS validates (wait for propagation).
4. Disable conflicting third-party SSL on the same hostname (e.g., paused Cloudflare cert).
5. Test apex and www; add redirects in _redirects only after both present valid TLS.
6. Re-run external openssl until serial changes.
7. Spot-check asset URLs and forms posting to https://.
8. Document DNS owner for the next registrar migration.

Roll out and verify

After Netlify re-issues, walk through critical user journeys: password reset links, Netlify Identity or Auth0 callbacks, and serverless functions invoked from forms. Functions inherit the custom domain TLS the browser sees—no redeploy needed if only DNS changed, but cache tags may still reference http:// asset URLs in older builds.

Use Netlify split testing or branch subdomains only after each hostname shows valid dates in openssl. Document which team owns external DNS; agencies moving clients off Netlify sometimes leave apex records forever—schedule a 90-day RDAP and TLS review post-migration.

If you attach Netlify Analytics or Edge Functions, hit those routes explicitly post-fix—edge middleware can run on hostnames customers rarely browse manually.

When to use automation

Build hooks do not watch certificate notAfter. Schedule live TLS checks on every custom domain on the Netlify site, including preview aliases if customers bookmark them.

Run /check after DNS changes. ssldays monitoring adds registrar RDAP context so domain lapses do not block the next Let’s Encrypt cycle.

Build success webhooks do not inspect notAfter. Monitor every production custom domain, including legacy domains redirected in _redirects, because redirects still require valid TLS on the source hostname. Netlify Identity and webhook endpoints should be on the same monitoring schedule as the homepage.

See Vercel SSL certificate provisioning delays for parallel PaaS DNS patterns and NET::ERR_CERT_DATE_INVALID fix for customer-facing error wording.

Netlify teams using split DNS for email and marketing should keep a change log of TXT records—marketing agencies delete Google Site Verification or DKIM rows while “fixing SSL,” breaking the next Let’s Encrypt cycle weeks later. Functions that call third-party HTTPS APIs inherit Netlify’s runtime egress IP reputation but not its certificate; visitor-facing errors remain tied to custom domain TLS on the HTML response path.

Large media workflows may load images from Netlify Image CDN on a subdomain configured months ago in a forgotten site clone. Audit all sites in the team dashboard for attached custom domains quarterly. Educate stakeholders that redeploying a branch does not renew certificates; only DNS-validated domain settings do.

Closing netlify ssl certificate expired tickets requires openssl proof on every domain in the Netlify site list, including parked domains that 301 elsewhere—browsers still handshake on the source name. Do not mark resolved because netlify.app works while a paid custom domain fails. Document which DNS host owns validation records so the next agency does not repeat the outage during a registrar migration.

Documentation for marketing teams should state clearly that Netlify certificate renewal depends on DNS remaining pointed correctly, not on how often they publish blog posts. Agencies moving a client off Netlify must remove custom domain attachments before repointing DNS, or visitors continue hitting Netlify infrastructure with stale certificates. Executive summaries should quote the exact custom domain that failed ads or email campaigns, because stakeholders confuse the default netlify.app subdomain with branded URLs.

Capacity planning for major launches should include a TLS verification step forty eight hours before traffic spikes. Netlify support can assist with stuck provisioning, but tickets move faster when you attach external certificate inspection output and a recent dig transcript from multiple public resolvers showing correct targets.

Split stacks that serve marketing on Netlify and APIs elsewhere still need monitoring on both sides; marketers may blame Netlify when only the API subdomain expired. Educate content editors that password protected staging links shared with clients use the same TLS as production custom domains. Volunteer open source maintainers mirroring documentation sites on Netlify should not assume the default subdomain alone satisfies readers; custom domains on the same site still need working HTTPS before conference announcement traffic arrives. Press releases that mention a branded domain should be held until public resolvers return consistent answers that route through Netlify with fresh certificate dates. Conference sponsors linking to Netlify hosted landing pages from event apps should verify TLS on venue WiFi before sessions begin. Developer advocates recording conference talks should mention the custom domain hostname on slides only after live external checks pass that day. Open source projects fundraising on Kickstarter should delay backer updates with demo links until branded Netlify domains show clean handshakes globally. Documentation mirrors should run the same external TLS checks as production custom domains before maintainers announce releases.