Fastly TLS certificate expired

fastly tls certificate expired on a Fastly-managed domain breaks HTTPS for every viewer resolving your service CNAME—even when origin nginx still serves a freshly renewed Let’s Encrypt chain.

Fastly terminates TLS on TLS subscriptions and platform-managed or customer-uploaded certificates bound to domains on your service. Public traffic flows to hostnames like www.example.com CNAME’d to your Fastly service address; browsers validate the edge leaf Fastly presents.

Renewal work often stops at the origin while the Fastly TLS configuration still references expired uploaded material or a managed enrollment that failed validation. API clients and SPA bundles fail together because they share the edge listener identity.

You will list domains and certificates, renew via Fastly-managed workflow or upload new PEM material, activate TLS, and openssl each customer hostname. Split origin checks per CDN edge OK but origin certificate expired when fetches fail after edge recovery.

Commerce teams should pause marketing pixels that hard-pin TLS versions during renewal weekends. Fastly edge recovery plus stale third-party tags can look like a partial site outage even when openssl already shows fresh notAfter on the primary hostname.

What to check

Inventory Domains on the Fastly service and note which use Certainly (managed) versus custom uploaded TLS. Managed certs renew inside Fastly when DNS delegation stays correct; uploaded certs follow your CA calendar.

Confirm the customer CNAME points at the Fastly-assigned DNS target shown in the domain detail panel. Stale CNAMEs to retired services make openssl read unexpected certificates during cutovers.

Read TLS activation status: pending certificate jobs do not change live notAfter until Fastly completes issuance and binds the domain. Capture external serial before opening Fastly support or uploading replacement material.

Fastly services often pair shield POPs with origin fetches. Edge openssl can be healthy while origin pulls fail for different reasons—still document both when closing fastly tls certificate expired tickets that began as generic 503 errors.

Step-by-step

Live TLS on the customer hostname

HOST=www.example.com
echo | openssl s_client -connect "${HOST}:443" -servername "${HOST}" 2>/dev/null \
  | openssl x509 -noout -dates -serial -subject -issuer

Fastly API: list TLS domains and certs

Set FASTLY_API_TOKEN from your secrets manager.

curl -s -H "Fastly-Key: $FASTLY_API_TOKEN" \
  "https://api.fastly.com/tls/domains" | jq '.data[] | {id, relationships}'
curl -s -H "Fastly-Key: $FASTLY_API_TOKEN" \
  "https://api.fastly.com/tls/certificates" | jq '.data[] | {id, attributes}'

Match certificate IDs to the domain relationship for the failing hostname.

Upload renewed custom certificate

After your CA issues PEM and key:

curl -s -X POST -H "Fastly-Key: $FASTLY_API_TOKEN" -H "Content-Type: application/json" \
  "https://api.fastly.com/tls/certificates" \
  -d @- <<EOF
{
  "data": {
    "type": "tls_certificate",
    "attributes": {
      "name": "example-2026",
      "cert_blob": "$(awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' cert.pem)",
      "key_blob": "$(awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' privkey.pem)"
    }
  }
}
EOF

In practice, use the Fastly CLI or Terraform provider your platform team maintains to avoid quoting errors in JSON. Link the new certificate to the domain via TLS activation API or control panel Secure another domain workflow.

Redact cert_blob and key_blob from chat logs when pasting API responses—they contain private material even during war rooms.

Fastly CLI (when installed)

fastly tls-configuration list
fastly domain list --service-id SERVICE_ID
fastly tls-subscription list

Command names vary slightly by CLI version; prefer fastly help tls when scripts fail.

Control panel path

Configure → select service → Domains → select hostname → Secure → upload certificate or enable Certainly managed TLS → complete DNS verification records Fastly displays.

Wait until domain status shows issued or active with future notAfter.

Activate the service version that carries production traffic after TLS updates when your workflow clones configs between staging and production service IDs. TLS objects are global to the account but domains attach per service—verify the service ID matches the CNAME target Fastly issued.

Verify all marketing hostnames

for h in www.example.com api.example.com; do
  echo "== $h =="
  echo | openssl s_client -connect "$h:443" -servername "$h" 2>/dev/null | openssl x509 -noout -dates
done

Origin check if errors persist

dig +short CNAME www.example.com
# curl -vI https://origin-behind-fastly/ with Host header per your shielding docs

Document the Fastly service ID beside each customer CNAME in your monitoring tool. On-call should not grep every service during a pager when openssl already names the failing hostname.

How to read the output

Certainly-managed certs show public CA issuers in openssl. Uploaded certs show your enterprise CA or Let’s Encrypt depending on source. Serial changes after successful bind.

If openssl on the customer hostname still shows expired dates five minutes after activation, confirm you updated the correct TLS configuration attached to the active service version, not a draft clone.

Managed TLS failures often correlate with removed ACME or validation TXT at DNS—fix authoritative records, not Fastly caching.

Partner SLAs sometimes require evidence that Fastly edge served valid TLS during an outage window—store timestamped openssl captures in the ticket repository when closing fastly tls certificate expired work, not only console screenshots.

Image optimization and compute-at-edge features do not substitute for TLS binding updates; they share the same customer hostname and the same certificate object.

Common mistakes

Renewing origin certs only while Fastly uploaded PEM expired—classic fastly tls certificate expired during platform migrations.

Creating a new service version without activating TLS on the production service ID customers hit.

Uploading cert without matching private key or missing intermediate chain in cert_blob.

Pointing apex A records at origin during firefighting, then forgetting to restore Fastly CNAME—monitoring sees green origin while users bypass edge.

Assuming Certainly auto-renew covers custom uploaded domains you never migrated to managed TLS.

Ignoring shield or origin patterns—edge green with 503 may be load balancer presenting an expired certificate on the origin.

Embedding PEM newlines incorrectly in JSON uploads—use CLI, Terraform, or control panel upload when scripting quoting is fragile.

Rotating Fastly API tokens during the incident without updating automation that lists certificates—secondary failures look like incomplete renewal.

When to use automation

Fastly services multiply per brand; DNS and TLS configs diverge after acquisitions. Monitor live TLS on customer CNAMEs, not ticket attachments from last year’s upload.

ssldays reads issuer, SANs, chain trust, and expiry from outside your network and alerts at 30, 14, 7, and 1 days. RDAP helps when domain validation needs healthy registrar data. Email on all plans; Slack and Discord webhooks on Starter and Pro; three domains daily free, twenty-five hourly Starter, one hundred Pro.

Probe with /check, schedule /register for every production domain on the service, and pair edge watches with origin checks described in CDN edge OK but origin certificate expired.

Add each Fastly domain to monitoring the week after creation, not the week before expiry—Certainly and upload workflows need runway when validation email, SMS, or DNS tokens stall legal and security approvals.