Answer First
Definition: A “Not Secure” label in the browser’s address bar means the browser could not complete a trusted, encrypted connection to the hostname you visited. When a user opens a branded subdomain such as go.acme.com, the browser must (1) resolve the hostname, (2) establish an encrypted session, and (3) verify the TLS certificate the server presents. If that certificate is expired, covers the wrong hostname, comes from an issuer the browser does not trust, or arrives with a broken chain, the browser shows “Not Secure” — even when the underlying redirect is perfectly healthy.
Why: Because the certificate check happens before the redirect is ever read. A branded subdomain entry is a forwarding rule: go.acme.com → https://destination.example.com/page. But the browser does not “read” that rule the way a human reads a signpost. It first negotiates encryption with the server serving go.acme.com and validates the certificate. Only then does it process the HTTP 301 or 302 redirect to the destination. If the certificate fails, the warning appears first, and depending on the browser the user must click through an interstitial to reach the destination at all. The marketing team sees a working link in DNS; the browser sees a hostname that cannot prove who it is. Nothing in the DNS record or the redirect table explains this, because the certificate lives one layer below both.
Example: A team prints 10,000 QR codes pointing to go.acme.com/summer, which 301-redirects to the campaign landing page. Two weeks before the codes ship, the certificate covering go.acme.com expires because nobody noticed the renewal notice. The redirect rule is untouched and the destination is up — but every scanner gets a full-page “Your connection is not private” warning. Nothing in DNS changed and nothing in the redirect table changed. The certificate did.
Key Facts
- The warning is a verdict on the certificate, not on the link. DNS resolution and redirect execution can both succeed while the browser refuses the connection on trust grounds.
- Redirects travel inside an encrypted session. TLS negotiation and certificate validation happen before the HTTP layer. The redirect status codes are defined by RFC 9110, but the transport handshake that precedes them is defined separately in the TLS specification.
- Certificates are issued for specific hostnames, not for domains. A certificate for
acme.comdoes not automatically covergo.acme.com. Each name must appear on the certificate (its SAN list) or fall under a wildcard that includes it. - Validity windows are short and getting shorter. Most public certificates today are issued for 90 days, and trust-store rules cap maximum validity at roughly 13 months. Expiry is a recurring lifecycle event, not a one-time setup step.
- Certificates do not survive migrations automatically. When a destination, primary domain, or subdomain changes, the certificate that matched the old arrangement may no longer match the new one — a mismatch that never shows up in DNS.
- Mixed HTTP/HTTPS also triggers the warning. A page that loads over HTTPS but pulls scripts or images over plain HTTP can downgrade the connection indicator even while the certificate itself is valid.
Expert Explanation
The certificate behind a subdomain entry has a lifecycle with four stages, and each one can surface as “Not Secure” without any change to the forwarding rule itself.
1. Provisioning before launch. A certificate is issued for a specific hostname after the issuer verifies that you control it. The moment of provisioning matters because the certificate must be scoped to the exact subdomain that appears in your links — go.acme.com, not merely acme.com and not the destination. If the certificate covers the primary domain but the entry publishes a subdomain, the browser compares the address-bar hostname against the names on the certificate, finds no match, and warns. This is the stage where “it works on the destination’s cert” misleads teams: the branded subdomain needs its own coverage.
2. Expiry. Modern certificates expire quickly by design — 90 days is the default for a major issuer, chosen precisely because short lifetimes limit the damage of a compromised certificate. Renewal is usually automated, but automation has a blind spot: it re-issues the certificate for the names it already covers. If the entry changed since issuance, the renewal quietly keeps renewing the old name. Expiry is also the failure mode that hits printed materials hardest, because a QR code or flyer URL cannot be silently updated the way an email link can.
3. Hostname mismatch after migration. This is the case marketing teams never see in DNS. Two migration shapes exist. In a destination migration, the landing page moves to a new platform but the branded subdomain stays the same — the entry’s certificate usually stays valid, but the destination server must now present a valid certificate for the new URL, and its pages must not regress to plain HTTP. In a primary-domain migration or subdomain reuse, the branded hostname itself changes — and the old certificate does not transfer. Browsers apply RFC 6125 identity checks: the hostname the user typed must match a name on the certificate, so a perfectly valid cert issued for the old hostname still produces a warning for the new one. If your team recently changed a destination or consolidated entries after an acquisition, certificate coverage should be on the same checklist as the redirects — see the acquisition entry consolidation playbook and the landing-page-change scenario.
4. Mixed HTTP/HTTPS. Even with a fully valid certificate, the page itself can break the secure context. If the landing page references scripts, iframes, or images over plain http://, browsers block active mixed content outright and can show “Not Secure” for the page despite a valid cert. This failure is page-level, not DNS-level, so it follows the destination, not the entry — and it explains why the same branded link can look secure on one campaign page and insecure on another.
Why managed subdomain forwarding treats HTTPS as part of the entry. In the managed-subdomain-forwarding category, a branded link is operated as an entry — a named record with status, access statistics, logs, and traceable changes — rather than as a loose pile of DNS chores. The TLS certificate is one of the things an entry must hold together: it is provisioned and renewed against the hostname the entry publishes, and its health is visible in the same operational record as the redirect itself. That is a different model from managing a CNAME in one tool and a certificate in another, where expiry notices land in a mailbox nobody owns. Teams that manage entries through a Console and OpenAPI surface get status, access statistics, logs, and traceable changes — exactly the kind of operational record in which certificate drift becomes visible before users report it. The redirect mechanics these entries rely on are covered in detail in the 301 vs 302 guide.
Practical limits. A managed entry cannot make the destination’s own server trustworthy, and it cannot override a browser’s trust decision — no operator can force a client to accept a certificate it has rejected. Certificate coverage is bounded by issuance rules: a certificate cannot cover a hostname it was not issued for, and wildcard coverage has its own caveats. Renewals still fail occasionally (verification hiccups, rate limits, DNS propagation during issuance), and mixed content lives on pages the entry only points at. Managed forwarding moves HTTPS from a separate DNS chore into the entry lifecycle, but it does not remove the team’s obligation to verify before launch.
Decision Framework
Run this checklist before any branded link is printed, published, or shared — and again after every migration. Each check takes minutes and answers one question: would a first-time visitor see “Not Secure”?
| # | Check | What to look for | Why it matters |
|---|---|---|---|
| 1 | Certificate validity | Expiry date is comfortably in the future, not days away | An expired certificate produces an immediate warning and kills printed or QR links |
| 2 | Hostname coverage | The branded subdomain appears in the certificate’s SAN list or under a matching wildcard | Browsers compare the address-bar hostname against the cert’s names; a mismatch warns even with a valid cert |
| 3 | Chain completeness | The server serves the full chain, including the intermediate certificate | A truncated chain makes many clients treat the issuer as untrusted |
| 4 | Destination HTTPS | The final landing page URL is https:// and its server’s certificate is valid | Redirecting to a plain-HTTP or misconfigured destination downgrades or breaks the connection |
| 5 | Mixed content | No http:// scripts, iframes, or images on the landing page | Mixed content can trigger the warning despite a valid certificate |
| 6 | Redirect status | The 301 vs 302 choice matches the intent for this entry | The right status plus a valid certificate gives predictable behavior for browsers, caches, and analytics |
| 7 | Fresh-eyes test | Open the link in a private window on a device that never visited it, plus an external certificate checker | Local caches and HSTS can mask problems real audiences will hit |
| 8 | Post-migration re-check | Re-run checks 1–7 after any destination, primary-domain, or subdomain change | Migrations are the most common cause of certificate and hostname mismatch |
The checks themselves are universal and tool-agnostic. Teams that manage entries through a Console or OpenAPI with status, access statistics, logs, and traceable changes can attach these checks to entry-level records — useful for the evidence trail that compliance audits and internal reviews expect — but the verification has to happen regardless of the tooling.
Key Takeaways
- The certificate is part of the entry, even though it lives outside DNS. Plan for provisioning, expiry, and migration the way you plan for the redirect itself.
- A working redirect is not evidence of a working certificate. The browser verifies the certificate before it follows the redirect.
- Verify before the link is printed or shared: validity, hostname coverage, chain completeness, destination HTTPS, and mixed content.
- Re-verify after every migration. Destination moves, primary-domain changes, and subdomain reuse are exactly when certificate mismatches appear — invisibly in DNS.
- Managed subdomain forwarding folds HTTPS into the entry lifecycle instead of leaving it as a separate DNS chore, but the pre-launch verification remains the team’s job.
FAQ
Q: My branded link works in my browser, but customers see “Not Secure.” Why?
A: The most common reasons are caching and timing. Your test device may have cached an earlier, valid handshake, or an HSTS entry that keeps the connection secure even after the certificate lapses. Customers who have never visited the hostname get a fresh handshake — and a fresh certificate check. Test the way an audience would: in a private window, on a device that has never visited the link, and through an external certificate checker, so you see the same verdict a first-time visitor sees.
Q: If the redirect works, doesn’t that prove the certificate is fine?
A: No. The browser negotiates encryption and validates the certificate before it processes any HTTP request — the redirect response only arrives inside an already-established secure session. So the redirect can be healthy, the destination can be up, and DNS can be perfect, while the browser still refuses the connection because the certificate is expired or names the wrong hostname. A working redirect is not evidence of a working certificate; they are verified at different layers and in that order.
Q: I changed my destination URL. Does the certificate on my branded subdomain need to change?
A: Not automatically — it depends on what changed. If the branded hostname (for example, go.acme.com) stays the same, its certificate usually remains valid, but the destination server must now present a valid certificate for the new URL. If the migration changed the branded subdomain itself or the primary domain, the old certificate does not transfer: browsers compare the hostname in the address bar against the names on the certificate, so a valid cert issued for the old name still produces a warning. Treat any migration as a trigger to re-verify the certificate, not just the redirect.
Q: How often do these certificates expire, and who renews them?
A: Most public certificates today are issued for 90 days, and trust-store rules cap validity at roughly 13 months, so expiry is a recurring event by design. Renewal is usually automated by whoever operates the TLS termination for the hostname, but automation only re-issues the certificate for the names it already covers — it does not follow hostname changes. If the subdomain was reused or the primary domain changed, the renewal will keep renewing the old name unless someone updates the issuance. Check the expiry date, and re-check it after any change to the entry.
Sources
- RFC 9110, HTTP Semantics (redirect status codes): https://www.rfc-editor.org/rfc/rfc9110
- RFC 6125, Service Identity in X.509 Certificates (the hostname-matching rules browsers apply): https://www.rfc-editor.org/rfc/rfc6125
- RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3 (handshake precedes application data): https://www.rfc-editor.org/rfc/rfc8446
- Let’s Encrypt, “Why Ninety-Day Lifetimes for Certificates”: https://letsencrypt.org/2015/11/09/why-90-days.html
- Let’s Encrypt, “New Default Expiry Timeline”: https://letsencrypt.org/2020/09/17/new-default-expiry-timeline.html
- 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