Answer First
Definition: A “Not Secure” warning appears when the browser cannot establish — or keep — a fully trusted HTTPS connection to the page your campaign link lands on. For a branded forwarding subdomain, the failure lives in one of three layers: the entry’s own HTTPS setup, the redirect chain between the entry and the destination, or the destination page’s content (mixed content, expired certificates, or certificate mismatches).
Why: Browsers evaluate security per hostname, at every step of the load. Forwarding is a chain of separate requests, so a valid HTTPS entry does not guarantee a valid HTTPS destination: any single hop — or any insecure resource inside an otherwise-secure page — can produce the warning. Teams often blame the wrong layer — just as they rewrite ads before checking the campaign entry when conversions dip.
Example: Your campaign link go.example.com/summer forwards to www.example.com/landing/summer. The entry loads over HTTPS with a valid certificate and healthy status; the redirect also lands on HTTPS; but the landing page pulls a product image from an http:// CDN URL. The browser flags the page “Not Secure” — the fault is in the destination’s content, not the entry or the chain.
Here’s what a “link not secure” warning means in plain language, plus a check order for non-technical teams: what you can verify yourself, what needs a DNS or platform owner, and how entry status, logs, and change history show whether the entry or the destination broke. Diagnostic only — nothing here provisions or renews certificates.
Key Facts
- “Not secure” is not one error. Browsers apply the same label to several distinct causes: a plain HTTP page, a missing, expired, or mismatched certificate, and mixed content on an HTTPS page.
- Security is judged at every hop. Each redirect is a separate request, and the browser checks the certificate for each hostname it talks to — so the chain can break even when both ends look fine.
- HTTPS on the entry does not make the destination secure. Forwarding separates the link from the page; a secure entry is only the first layer.
- Mixed content is a destination-page problem: an HTTPS page that loads scripts, stylesheets, or other resources over HTTP can lose its secure indicator, since browsers block the dangerous kinds and upgrade the rest.
- Certificate failures are usually time- and hostname-specific — they appear when a certificate expires or was issued for a different domain.
- Environment noise is real. Corporate proxies, VPNs, browser cache, and a device clock set to the wrong date can produce warnings — or clean results — that don’t match what other visitors see.
Expert Explanation
Think of one click as a three-layer journey: the entry link itself, the redirect chain it triggers, and the final page’s content. Each layer has its own failure modes, its own check, and its own owner.
Layer 1 — The entry’s own HTTPS setup. This is the forwarding subdomain itself, for example go.example.com. To check it: open https://<entry>/ directly, look at the address-bar indicator, then open the certificate details (padlock or tune icon → “Connection is secure” → certificate). If the warning appears on the entry URL before any redirect, the entry host itself is failing — no certificate, an expired one, or one for the wrong hostname. Who fixes it: the DNS or platform owner who runs the entry’s hosting and certificate lifecycle. A forwarding management tool configures where the entry points; it does not own the entry’s TLS.
Layer 2 — The redirect chain. Forwarding works through HTTP redirects: a server responds with a 3xx status and a Location header pointing to the next URL, and the browser follows it. Any hop in that chain can downgrade to http:// or bounce through a host with a bad certificate — even when the entry and the final page are both clean. If your team has already debugged broken attribution in a redirect chain, you know how much can hide between hops. To check: paste the link into the browser and watch the address bar’s final URL — it must start with https://. For more detail, open the Network tab in DevTools with “Preserve log” enabled and review each request, or run curl -I -L <link> end to end. Who fixes it: the owner of whichever host is misconfigured; if the entry’s target points at a broken intermediate, the entry owner can correct it in the Console or via the OpenAPI.
Layer 3 — The destination page’s content. After the final URL loads, the page’s own resources are still subject to browser security checks. Three triggers dominate. Mixed content: an HTTPS page that loads images, scripts, fonts, or other subresources over HTTP — browsers block the high-risk types and upgrade or flag the rest, and the page may lose its secure indicator. An expired certificate on the destination hostname. A certificate mismatch: valid, but issued for a different domain than the one in the URL. To check: open the destination URL directly, review its certificate, then open the DevTools console — mixed-content warnings are logged there.
The check order. Follow this sequence and you will rarely misplace the blame:
- Open the entry URL directly; confirm it loads over HTTPS with a valid certificate.
- Follow the redirect and note the final URL — it must be
https://. - Open the destination directly and check its certificate’s validity dates and hostname.
- Open the DevTools console on the destination and look for mixed-content warnings.
- Repeat in an incognito window, a different browser, or a different network to rule out cache and proxy noise.
What entry management tooling can tell you. Console and OpenAPI give you the facts that narrow the search: entry status (active or paused?), access statistics (are clicks still arriving?), logs (where did requests go?), and traceable change history (did the target change, and who changed it?). If status and logs show the entry is live, still redirecting to the expected HTTPS target, and nobody changed the configuration, the break is almost certainly downstream — destination certificate or content — concrete evidence to hand the destination owner. Change history also settles a recurring launch question: did the destination change after the ad was approved? And it doubles as the evidence trail compliance audits rely on.
Practical limits. A browser-based diagnostic is good, but it has boundaries:
- The Console shows entry configuration, status, and logs — it does not validate the destination’s certificate; that check happens in the visitor’s browser.
- Certificate details can only be inspected in a browser at the failing URL.
- Caches, HSTS, corporate proxies, VPNs, and device clock errors can produce warnings — or clean results — that don’t match what other visitors see.
- A clean test from your network does not guarantee the same result on every visitor’s network.
- Certificates on the entry host or the destination must be fixed by their owners. PushULink manages forwarding entries; it does not issue or renew certificates.
Decision Framework
When a “link not secure” warning reaches your team, use the symptom to pick the layer, then hand it to the right owner:
| Symptom you see | Layer to check first | Who owns the fix |
|---|---|---|
| Warning on the entry URL itself, before any redirect | Layer 1: entry HTTPS setup | DNS/platform owner of the entry host (certificate lifecycle) |
| Entry loads HTTPS; warning appears after the redirect | Layer 2: redirect chain | Entry owner (target) plus owners of intermediate hosts |
| Entry and redirects are clean; the destination shows the warning | Layer 3: destination certificate or content | Destination site owner |
| Warning only on some pages of the destination | Layer 3: mixed content | Destination site owner (fix http:// resource URLs) |
Key Takeaways
- “Not Secure” is a symptom with three possible homes — the entry, the redirect chain, and the destination’s content. Check them in that order.
- A valid HTTPS entry does not make the destination secure; every hop and every subresource is judged separately.
- Marketing can verify most of the chain with a browser alone — address bar, certificate view, DevTools console — and pass the evidence to the right owner.
- Certificates belong to the infrastructure that serves each hostname; provisioning and renewal are DNS/platform/site-owner work, not forwarding-configuration work.
- Entry status, logs, and change history tell you whether the entry or the destination broke — evidence to route the fix, not blame to assign.
FAQ
Q: My campaign link shows “Not Secure”, but the destination site has a valid certificate. What is actually wrong?
A: The certificate that matters is the one for the hostname the browser is talking to at that moment. If the warning appears before or during the redirect, the failing certificate belongs to the entry host or an intermediate host, not the destination. Walk the redirect hop by hop in the DevTools Network tab to find where the warning starts.
Q: Does an HTTPS entry mean the whole redirect is secure?
A: No. Forwarding is a chain of requests, and each hop must be HTTPS with a valid certificate for its own hostname. One http:// hop, or one host with an expired certificate, is enough to trigger the warning even when the entry and the final page are both fine.
Q: Is “Not Secure” the same as a certificate error page?
A: Not exactly. A full certificate error usually blocks the page with an interstitial. “Not Secure” can also appear on a page that loads fine — for example, an HTTPS page that loads scripts or images over HTTP (mixed content) may lose its secure indicator while still displaying. The DevTools console shows which insecure resources triggered it.
Q: Can I fix a “Not Secure” warning myself with only Console access?
A: Sometimes. If the entry’s target points at a broken URL or an expired certificate, you can update it to a known-good HTTPS URL. What you cannot do from the Console is issue or renew certificates — those live on the entry host and the destination, and that lifecycle belongs to the DNS, platform, or site owners. PushULink manages forwarding entries; it does not issue or renew certificates.
Sources
- MDN Web Docs — “Redirections in HTTP”: 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
- W3C — “Mixed Content” (Candidate Recommendation Draft): https://www.w3.org/TR/mixed-content/
- IETF — RFC 9110, HTTP Semantics (3xx redirection responses and the Location header): https://www.rfc-editor.org/rfc/rfc9110