Answer First
Definition: A subdomain SSL certificate warning is the browser refusing, or flagging, the TLS connection when someone opens your branded campaign subdomain — for example spring-sale.yourbrand.com. In the vast majority of cases the warning has nothing to do with the forwarding entry: the entry is live, the redirect rule is correct, and the destination page is reachable.
Why: Because the entry does not hold a certificate. When a browser opens your subdomain it performs a TLS handshake with whichever host is answering at that moment — the forwarding subdomain first, and then the destination host after the redirect. The certificate belongs to one of those hosts, not to the entry pointing at it. Teams chase the wrong layer for exactly this reason: they recreate entries, blame DNS, or reprint QR codes, while the fault sits in TLS configuration they never touched.
Example: A team sees “Your connection is not private” on launch.yourbrand.com. The Console shows the entry Active with recent redirect traffic, and the logs show the 301 firing. The warning is on the destination host: the landing page’s certificate expired overnight. The entry did its job — it forwarded. The destination server’s TLS did not.
Key Facts
- A subdomain SSL certificate warning is a TLS-layer event, not an entry-status event. The browser validates the certificate of the host it is currently talking to, on every hop: before the redirect and again after it.
- The error text classifies the fault: expired (NET::ERR_CERT_DATE_INVALID), untrusted (NET::ERR_CERT_AUTHORITY_INVALID), wrong-domain (NET::ERR_CERT_COMMON_NAME_INVALID or NET::ERR_CERT_NAME_NOT_MATCHED), or mixed content (console “Mixed Content” errors with a “Not secure” padlock).
- Exactly three layers can produce the warning: TLS on the forwarding subdomain, TLS on the destination host, and mixed content inside the destination page.
- Console status and logs prove whether the entry is live and forwarding; they cannot prove a certificate’s validity. Check the entry first, then verify certificates at the host layer.
- Modern browsers do not let real visitors bypass certificate warnings; “proceed anyway” is per-visitor, temporary, and a dead end for a customer-facing campaign.
Expert Explanation
Layer 1: TLS on the forwarding subdomain
When a visitor opens campaign.yourbrand.com, the browser connects to the host that the subdomain resolves to and expects a certificate valid for that hostname. If the certificate is expired, untrusted, or issued for a different name, the warning appears before the redirect runs — the browser never reaches your destination. Chrome shows “Your connection is not private” with NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_AUTHORITY_INVALID, or NET::ERR_CERT_COMMON_NAME_INVALID; Safari and Firefox use different wording but the same underlying checks.
The cause is the certificate covering the subdomain itself: its validity window lapsed, it was issued by an issuer the browser doesn’t trust, or it was issued for a different hostname. Whether that certificate is provisioned automatically or supplied by your team is a configuration detail — the browser’s check happens regardless. Verify at the network layer with the browser’s certificate viewer or a certificate transparency log, and treat the Console’s entry status as proof of forwarding, not proof of TLS.
Layer 2: TLS on the destination host
The forwarding host answers with a 301 or 302 redirect. The browser follows it to the destination URL and performs a fresh TLS handshake with the destination host. If that certificate is expired or untrusted, the warning appears after the redirect — sometimes the URL bar flashes the destination before the error page.
This is the most common layer and the one most often misdiagnosed as “my entry broke.” The redirect worked perfectly; the destination team’s certificate expired, or their server stopped sending the intermediate chain. Certificates do not travel with the redirect — when a landing page moves to a new host or domain, the new host needs its own valid certificate, the same situation our guide on what to do when the landing page changes after the ad was approved covers, and the same lesson that applies when consolidating subdomains after an acquisition: each host stands on its own TLS.
Layer 3: Mixed content inside the destination page
The destination loads over HTTPS, but the page requests HTTP resources — scripts, iframes, images, fonts. Browsers block active mixed content (scripts, iframes) entirely and mark passive content (images, audio) as insecure. Symptoms: the page loads, the padlock becomes “Not secure,” and DevTools shows “Mixed Content: the page at ‘https://…’ was loaded over HTTPS, but requested an insecure resource.” There is no full-screen warning, which is why teams miss this layer: the redirect “worked,” so nobody opens the console.
Reading the browser signal
| Browser signal | Meaning | Layer at fault | Typical cause | First check |
|---|---|---|---|---|
| ”Your connection is not private” + NET::ERR_CERT_DATE_INVALID | Certificate expired | Forwarding subdomain or destination host | Missed renewal | Which host was the browser on? Console status + logs |
| NET::ERR_CERT_AUTHORITY_INVALID | Certificate not trusted | Forwarding subdomain or destination host | Self-signed cert or missing intermediate chain | Browser cert viewer / public server test |
| NET::ERR_CERT_COMMON_NAME_INVALID / NAME_NOT_MATCHED | Certificate is for a different hostname | Forwarding subdomain or destination host | Host or DNS change without a matching cert | Console entry URL vs. certificate subject |
| ”Not secure” padlock + “Mixed Content” console errors | HTTPS page loading HTTP resources | Destination page | Hard-coded http:// asset URLs | Browser DevTools console |
Decision Framework
- Copy the exact error text — the NET::ERR code and the hostname in the address bar. Do this before touching anything; the code is your layer map.
- Locate the layer. Did the warning appear before the redirect (forwarding subdomain) or after it (destination host)? Is there a full-screen warning at all, or just a “Not secure” padlock (mixed content)?
- Verify the entry layer. Open the Console and check the entry’s status, recent access statistics, and logs: does the log show the redirect firing at the reported time? Does the change history show the entry or its destination URL was recently modified? This traceability is the same evidence trail auditors look for in entry management. If the entry is healthy, the fault is not the entry.
- Check the host certificates. For the destination: open the browser’s certificate viewer or a public server test such as SSL Labs. For the forwarding subdomain: check the certificate in the browser or a certificate transparency log. Console status and logs do not replace this check.
- Fix at the correct layer, then re-test. Renew or reinstall the certificate (destination team), fix hard-coded http:// URLs (page team), and only if status and logs show the entry itself failing, look at the entry — revisit 301 vs 302 redirect behavior and whether the destination URL itself changed.
Practical limits — what you can and cannot do:
- You cannot make browsers stop warning for real visitors; “Advanced → proceed” is per-visitor and resets.
- Browser and OS caching can serve a stale redirect or a stale error page for a short window — re-test in a fresh or private window after a fix.
- Mixed content is enforced by the browser; the fix is in the page’s HTML/CMS, never in the entry.
- Browsers cache 301 responses; a cached redirect to an old destination can resurface a destination warning even after you fixed the entry — exactly why the 301 vs 302 choice matters for campaign entries.
- The Console reports entry status, traffic, logs, and change history — it does not issue or validate certificates for your hosts.
Key Takeaways
- A subdomain SSL certificate warning is a TLS-layer event on one of three layers, and almost never means the entry is wrong.
- Read the exact error text: expired, untrusted, wrong-domain, and mixed content each point to a different layer and cause.
- Check Console status and logs before changing anything — they prove whether the entry is forwarding; certificate validity is verified separately at the host layer.
- The warning often comes from the destination host after a perfectly working redirect — the most common and most misdiagnosed case.
- Don’t recreate entries, blame DNS, or reprint QR codes until you have located the layer.
- When the page loads but shows “Not secure,” it’s mixed content, not the entry — open DevTools and read the console.
- Check the campaign entry before rewriting the ads is the same discipline: diagnose the layer before you change anything.
FAQ
Q: My campaign subdomain shows “Your connection is not private.” Is my forwarding entry broken?
A: Almost certainly not. The entry is a forwarding rule; the warning comes from the TLS handshake with the host the browser is talking to — the forwarding subdomain, or the destination after the redirect. If the Console shows a normal status and logs with redirects firing, the entry is fine and a certificate on one of the hosts is the problem. Copy the NET::ERR code and match it to the table above.
Q: What’s the difference between “expired” and “untrusted” certificate errors, and does it change the fix?
A: Expired (NET::ERR_CERT_DATE_INVALID) means the certificate’s validity window passed — the certificate needs renewal. Untrusted (NET::ERR_CERT_AUTHORITY_INVALID) means the browser does not recognize the issuer — commonly a self-signed certificate or a server that stopped sending the intermediate chain. Both are host-layer problems, but the fix differs (renew vs. install the chain), so the error text tells you who to contact and what to ask for.
Q: The redirect works but the browser shows “Not secure” on the landing page. Is that the entry?
A: No. If the page loaded, the redirect and the destination TLS are fine; the warning is mixed content — the HTTPS page is requesting HTTP resources such as scripts, images, or iframes. Open DevTools → Console and look for “Mixed Content” messages, then fix the hard-coded http:// URLs in the page or CMS. There is nothing to fix in the entry.
Q: I recreated the entry and the warning is still there. What now?
A: Recreating an entry never changes a certificate, so the warning persists — you changed a layer that was not at fault. If you changed a working configuration, restore it, then work the decision framework: identify the error code, confirm which host the browser was connecting to, and check that host’s certificate with the browser viewer or a public server test. Use the Console’s change history to confirm whether the destination URL changed recently and needs its own certificate check.
Sources
- RFC 9110 — HTTP Semantics (redirect status codes): https://www.rfc-editor.org/rfc/rfc9110
- MDN Web Docs — HTTP Redirections: https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
- MDN Web Docs — Mixed content: https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content
- MDN Web Docs — Transport Layer Security: https://developer.mozilla.org/en-US/docs/Web/Security/Transport_Layer_Security
- Qualys SSL Labs — SSL Server Test: https://www.ssllabs.com/ssltest/