DigitalOcean App Platform SSL issues

digitalocean ssl certificate expired on App Platform almost always tracks a custom domain that lost validation—not the default ondigitalocean.app hostname.

Developers deploy apps on DigitalOcean App Platform and attach custom domains in the control panel or via doctl.

DO manages TLS renewal at the edge when DNS points at the provided CNAME target and domain status is Active. Removing and re-adding domains, or letting CNAMEs lapse, can leave browsers seeing expired or default certificates.

Prove TLS on the customer-facing FQDN, then align DNS and app spec before escalating to support.

First response

In Apps → your app → Settings → Domains, read each domain's status (Pending, Active, Error). Copy the exact CNAME target DigitalOcean issued.

Compare public DNS (dig CNAME www.example.com) with the required value. Test TLS:

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

If only the default app URL works, the incident is custom-domain validation—not your container image.

Export the app spec JSON after domain changes so rollback is possible. Note whether the domain is production or preview; preview apps use different default URLs. If Terraform manages DNS, verify state matches the control panel before blaming App Platform.

What this error means

App Platform terminates TLS on its load balancer layer. Built-in *.ondigitalocean.app certificates rotate with the platform. Custom domains require you to maintain DNS proof; DO reissues Let us Encrypt-style certs on that trust relationship.

An expired public cert usually means traffic no longer hits DO's active certificate set—often DNS pointed away, a deleted app component, or a stale domain attachment after forked environments.

PKIX errors from API clients calling your custom domain should be fixed at the platform domain settings, not by baking PEM files into the app unless you use a bring-your-own cert feature on eligible tiers.

App Platform hides certificate machinery behind domain objects. An expired public cert usually means validation trust broke, not that containers crashed. Built-in URLs can remain healthy while branded domains fail, confusing status dashboards.

Common causes

CNAME flapping during migrations to another host while the App Platform domain entry still exists.

Apex ALIAS mistakes when DO requires CNAME flattening at specific DNS providers.

Multiple apps claiming the same hostname across teams.

Certificate pending ignored until notAfter on an older attached cert elapsed.

Component routes serving only internal URLs while marketing advertises a domain never added to the app spec.

Team members sometimes add domains to deleted apps, leaving DNS pointing at stale routing. Apex ALIAS records at niche DNS hosts fail silently compared to simple CNAME instructions. Certificate pending states exceed patience and teams redeploy unnecessarily.

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 commonly shows a public CA used by DigitalOcean. Subject/SAN must include your custom domain exactly.

curl

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

doctl

doctl apps list
doctl apps spec get APP_ID
doctl apps create-domain APP_ID --domain CUSTOMDOMAIN

Inspect deployment logs if domain validation fails after DNS fixes.

Use dig from multiple resolvers on CNAME targets. Hit the default app URL and the custom domain with openssl and diff issuers.

Fix checklist

1. Add or re-add the custom domain in App Platform.
2. Publish the required CNAME at your DNS host; wait for propagation.
3. Wait until panel shows Active certificate status.
4. Remove conflicting A records pointing at retired VMs.
5. Redeploy only if routes changed; SSL is orthogonal to container restarts.
6. Test API webhooks and OAuth callbacks on the custom domain.
7. Monitor both default and custom hostnames if you use both.
8. Document DNS owner for audits.

Roll out and verify

App Platform certificate work rarely requires rebuilding containers. Focus on the domain object in the app spec: remove broken entries, re-add the hostname, and let the control plane reconcile certificates while components keep running.

When multiple environments (production, staging) share a DNS zone, confirm only the intended app owns each custom domain. Cloned apps sometimes duplicate hostname attachments after doctl apps create from an old spec JSON.

After DNS correction, poll domain status every few minutes rather than assuming instant issuance. DigitalOcean sends emails on some SSL failures—correlate timestamps with your deployment history to avoid blaming a code release for a CNAME edit made in parallel.

Finish with webhook and OAuth regression tests hitting the custom domain, not the default ondigitalocean.app URL partners may still store from early development.

Update API clients and OAuth redirect URIs if hostname attachment changed. Document DNS TTL when planning future migrations.

Support engineers often ask for dig output and app UUID together; store both in the incident doc. DigitalOcean documents each app domain with a dedicated validation state machine. Operators should screenshot that state before and after DNS edits because support tickets without timestamps often confuse pre-change failures with propagation delays. When teams maintain DNS in Cloudflare, disable orange-cloud temporarily if HTTP-based validation paths flap, or ensure orange mode still reaches App Platform challenge endpoints. If your organization routes apex records through third-party DDoS scrubbers, confirm scrubbers forward sanitized traffic to the exact CNAME DigitalOcean issued—scrubber misconfiguration frequently mimics certificate expiry while TCP probes stay green. Staging components that share a zone with production must not reuse production CNAME targets unless you intend both environments to compete for the same hostname attachment. Database connections and worker queues do not need restarts for TLS recovery, which is why isolating domain objects first saves incident minutes. FinOps teams should tag DNS owners in asset inventories because certificate incidents often begin when a departed vendor still holds registrar login. Load tests against default app URLs while custom domains fail can mislead leadership into scaling dynos instead of fixing DNS. Schedule a calendar reminder one week before historical cert revalidation windows if your org frequently deletes and recreates domain attachments during cost-saving pauses. Incident retros should note whether SSL pending correlated with a Terraform apply, a manual DNS change, or a registrar lock event. Teams shipping multiple microservices on one app should list every route hostname marketing exposes, including preview URLs and websocket endpoints, because each requires an active domain attachment to present managed TLS. When mobile clients pin alternate ports, remember App Platform still presents certificates on standard HTTPS entry points unless you configure additional documented paths. Pair DO monitoring alerts with external openssl cron jobs because platform notifications sometimes email billing contacts instead of on-call engineers.

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.