Answer First
Definition: An “SSL certificate expired” error on a campaign link means the destination the entry points at presented a TLS certificate whose validity window has ended, and the visitor’s browser refused to proceed. A TLS certificate is a signed document binding a hostname to a public key, with explicit not-before/not-after validity dates defined in the X.509 standard (RFC 5280). A browser that reaches a host whose certificate is outside that window blocks the connection and shows a security warning before any redirect, page content, or HTTP status code appears.
Why: A campaign link is a chain of at least two hosts, so two independent things can expire: the domain registration and the TLS certificate. Domain registration decides whether a hostname resolves at all — the failure mode covered in our earlier article “The Campaign Domain Expired.” The TLS certificate decides whether a browser trusts the encrypted connection once it resolves. Certificate expiry looks nothing like a 404: a 404 is an HTTP response delivered after a successful connection; an expired certificate aborts the connection before HTTP begins — while the entry still returns its normal 301 or 200.
Example: Your entry mybrand.com/promo 301-redirects to a landing page on an agency’s domain, whose certificate expired over the weekend. A visitor clicks the ad; the entry answers with a 301; the browser follows the redirect and, instead of a landing page, shows “Your connection is not private” (NET::ERR_CERT_DATE_INVALID in Chrome). Your uptime monitor — checking only the entry URL — reports green, while support gets a ticket reading “this link is unsafe.” The entry never failed; the destination’s certificate did.
Key Facts
- Two things expire on a campaign link, on different hosts: the domain registration (entry side) and the TLS certificate (entry host, destination host, or both).
- Certificate validity is defined in X.509 (RFC 5280) as explicit not-before/not-after dates, checked by the browser on every connection.
- Expired certificates fail below the HTTP layer — no status code exists for an HTTP-level check to catch.
- Renewing the domain does not renew the certificate — the two are managed by different parties on different schedules.
- Public certificates are short-lived by design — Let’s Encrypt, the largest public CA, issues 90-day certificates — so expiry recurs.
- You can only replace a certificate you own.
Expert Explanation
The chain has two certificates, and both can expire
When a visitor clicks a branded campaign link, the request crosses at least two hosts: the entry host (your branded subdomain) and the destination host. The browser performs a TLS handshake with each, evaluated independently. The entry host’s certificate is yours to manage. The destination’s belongs to whoever runs it — an agency, a campaign platform, a partner site — and its expiry is outside your control.
The failure is easy to misread because it is invisible to HTTP tooling. A 404 or a 502 happens after a connection is established: the server responds and your monitor records a status code. A certificate expiry happens during the handshake, before any HTTP response is sent. If your health check only fetches the entry URL and records its 301 or 200, it never sees the destination’s certificate problem — entry status and visitor experience can diverge completely.
Redirect behavior matters too. With a 301 or 302, the browser checks the entry host’s certificate first, follows the Location header, then checks the destination host’s. Each hop is a separate trust decision — see our comparison of 301 vs 302 redirects for campaign entries. A warning can therefore appear at either layer, and the address bar tells you which one failed.
Why certificates expire
Short validity periods are deliberate: they limit the damage of a compromised key and force automation — the dominant public CA issues 90-day certificates to make expiry routine. For an entry owner, the destination’s certificate will expire roughly four times a year — renewed by someone who does not notify you. There is no “renewal” in the extension sense: the validity window is fixed at issuance, so the owner must obtain and install a new certificate before the old not-after time.
The support-ticket signature
The classic signature is a stream of “this link is unsafe” tickets while monitoring stays green. Visitors describe fear, not HTTP errors, because the browser frames the problem as a security decision. Teams often respond by rewriting ads or re-checking the entry — the pattern we describe in Ads Get Clicks But No Conversions? Check The Campaign Entry Before Rewriting The Ads — when the fix actually lives at the destination. The tickets are useful: they name the URL the warning appeared on — the failing layer.
Decision Framework
Separate the layers
Four questions separate the layers: which URL shows the warning, which host’s certificate is expired, who owns it, and whether it can be replaced before launch — the table walks through the combinations.
| What you observe | Layer most likely failing | Check | Who can fix it |
|---|---|---|---|
| Warning on the entry URL before any redirect | Entry host certificate, or entry domain registration | Entry host certificate dates; domain resolution | You (entry owner) |
| Entry redirects, then warning on the final URL | Destination certificate | Destination host certificate dates (see FAQ) | Destination owner — or you change the destination |
| Monitoring green, visitors report warning | Destination certificate (invisible to entry-only checks) | Follow the redirect chain; validate TLS end-to-end | Destination owner — or you change the destination |
| Warning only on some devices or browsers | Trust store differences, hostname mismatch, or an incomplete chain | Hostname, full chain, and dates on several devices | Usually the certificate owner |
The pre-launch check to add to your health checks
Add this checklist to whatever health-check routine you already run — the status you see in the Console, an external monitor, or both. Treat it as operational practice, not a product guarantee.
- Record the destination certificate’s owner, issuer, and not-after date before launch.
- Add a check that follows the full redirect chain and validates TLS on the final host — not just the entry URL.
- Set an alert at least two weeks before the not-after date (earlier for 90-day certificates).
- Confirm a destination contact who can replace it, or agree an escalation path.
- Re-run the check after any destination change, not just at launch.
- Log the check where your team records entry changes — the same principle as the documentation in How Entry Management Supports Compliance Audits.
Practical limits
A pre-launch check is a snapshot — a certificate can expire the day after you check — and you cannot receive renewal notifications for a certificate you do not own: the CA emails the destination owner, so your calendar and checks are the only safety net. Some destinations block bot traffic or serve different certificates by geography, producing false alarms; validate against what real visitors will see. And a valid certificate does not guarantee a clean warning: hostname mismatch, revocation, and untrusted issuers all produce one.
When the destination is the problem
If the destination owner cannot or will not replace the certificate in time, change the redirect target to a host you control or a working page on the same platform — exactly the workflow in The Ad Is Approved, But the Landing Page Changed. What Should We Do?. If the destination is contractual, the expiry, and who held the certificate, belongs in the handoff record. In the interim, decide whether to keep the entry live: an entry that forwards visitors into a browser warning usually costs more trust than a paused one.
Key Takeaways
- Domain registration and TLS certificates expire independently; renewing the domain does nothing for the certificate.
- Certificate expiry fails below HTTP: a 301 or 200 on the entry does not mean the destination is safe.
- The URL in the warning tells you whether the entry host or the destination host is failing.
- The destination’s certificate is owned by someone else, so “this link is unsafe” tickets are a signal about the destination — your options are detect, escalate, or change the destination.
- Add an end-to-end TLS check that follows the redirect chain to your pre-launch routine, alerted well before the not-after date.
FAQ
Q: What does “SSL certificate expired” mean when it appears on my campaign link? A: The browser reached a host in the link’s redirect chain and found a TLS certificate whose validity window had ended, so it showed a security warning instead of loading the page. It is a TLS-layer failure, distinct from a 404, and it can happen on the entry host or the destination host.
Q: My entry’s status still shows healthy — how can the link be broken? A: Certificate expiry happens below HTTP. Monitoring that checks only the entry URL sees the normal 301 or 200 and records success, while the browser — following the redirect and performing a second TLS handshake at the destination — hits the expired certificate. The two measure different things.
Q: I renewed the domain — why do visitors still see the warning? A: Domain registration and the TLS certificate are separate systems: renewing the domain keeps the hostname registered but does not extend any certificate. Check which host in the redirect chain presents the expired certificate, then have it replaced — or change the destination.
Q: How do I check the destination’s certificate expiry myself?
A: From a machine that can reach the destination, run openssl s_client -connect <host>:443 -servername <host> </dev/null 2>/dev/null | openssl x509 -noout -dates for the not-before and not-after dates. To cover the redirect chain, follow the entry URL first with curl -sIL <entry-url> to get the final host, then check it.
Sources
- RFC 5280 (X.509 certificate validity periods): https://www.rfc-editor.org/rfc/rfc5280
- RFC 9110 (HTTP redirect status codes): https://www.rfc-editor.org/rfc/rfc9110
- MDN Web Docs (Redirections in HTTP): https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
- Let’s Encrypt (Why ninety-day lifetimes): https://letsencrypt.org/2015/11/09/why-90-days.html
- Google Chrome Help (NET::ERR_CERT_DATE_INVALID): https://support.google.com/chrome/answer/6098869