The Campaign Subdomain Shows "Your Connection Is Not Private": What Should You Check First?

Answer First

Definition: “Your Connection Is Not Private” (Chrome) — “Warning: Potential Security Risk Ahead” in Firefox — is the browser refusing to open a page because it could not establish a trusted, encrypted connection with the host it actually reached. For a campaign entry, that host is the URL after the redirect, not the branded subdomain the audience clicked. A subdomain SSL certificate error on a forwarding entry, in other words, is a message about the destination — and only rarely about the forwarding itself.

Why: A forwarding entry is an instruction, not a connection. When a visitor clicks springsale.yourbrand.com, the entry answers with a redirect (typically 301 or 302), and the browser then performs a completely independent TLS handshake with the destination host. If that destination answers on plain HTTP, serves an expired certificate, or presents a certificate whose hostname does not match, the browser shows the warning — no matter how healthy the entry is. Diagnosing the error means separating what the entry controls (where the browser goes) from what the destination server controls (whether TLS succeeds once the browser arrives).

Example: You configure springsale.yourbrand.com to forward to http://landingpage.yourpartner.com/spring. The redirect fires, the browser lands on an unencrypted page, and Chrome blocks with the warning — the entry is healthy and the destination is the problem. The same screen appears when the destination’s certificate expired two days ago, or when it covers www.yourpartner.com while your entry points at the apex yourpartner.com.

Key Facts

• The warning concerns the final URL in the chain, not the link you clicked. Browsers validate certificates only after following every redirect.
• Mixed content after the redirect — an HTTPS subdomain pointed at a plain-HTTP destination — is the most common cause of this error on forwarding entries.
• An expired certificate surfaces as NET::ERR_CERT_DATE_INVALID; a hostname mismatch as NET::ERR_CERT_COMMON_NAME_INVALID; a missing intermediate certificate as NET::ERR_CERT_AUTHORITY_INVALID.
• The entry’s own certificate matters only for the first hop; the destination certificate is validated independently of it.
• The warning is computed client-side: browser cache, an HSTS policy on the destination, and even a device’s wrong clock can change whether it appears.
• A recent entry or destination change is a leading suspect: certificates cover only the names and dates they were issued for, and they do not “catch up” on their own.

Expert Explanation

Two hops, two validations

When a visitor clicks a branded subdomain, two separate security checks happen in sequence.

First hop — the entry. The browser resolves springsale.yourbrand.com, connects, and the entry responds with a redirect. HTTP defines this behavior in the redirect status codes and the Location header (RFC 9110): the server tells the client where to go next, and the client does the rest. For the browser to trust this hop, the entry host needs its own valid certificate. With PushULink, the entry subdomain’s DNS and certificate are part of the managed forwarding infrastructure, which is why this hop rarely fails. If the warning appears before any redirect takes place, the problem is in this layer — the entry’s DNS or the platform’s infrastructure — and it is a DNS/platform-owner question, not a destination question. (Which status code your entry uses and what each signals is covered in our guide to 301 vs 302 redirects for campaign entries.)

Second hop — the destination. The browser follows the Location header to the destination URL and starts a brand-new TLS handshake with that host. This validation happens entirely between the visitor’s browser and the destination server; no forwarding product participates in it. This is the hop where campaign warnings are born.

The takeaway: certificate validation happens at the final host. A valid branded subdomain does not bless an invalid destination, and browsers do not skip their checks just because a redirect was involved — MDN’s documentation of HTTP redirections makes the same point: a redirect is a client-followed instruction, and each hop in the chain is validated on its own.

The three classic causes

1. Mixed content after the redirect (protocol mismatch). An HTTPS entry pointed at an HTTP destination. The redirect “succeeds,” but the browser then loads an unencrypted page and blocks it. The fix lives in the entry: change the target to the HTTPS version of the same URL, or ask the destination owner to enable HTTPS.

2. An expired or mismatched certificate on the destination. Three distinct failures sit here: the certificate is past its notAfter date (expired); it was issued for a different hostname than the one in the final URL (common with apex vs. www or with wrong subdomains); or the server omits the intermediate certificate that would complete the trust chain. All three are fixed on the destination server, not in your entry.

3. A certificate that hasn’t caught up after a change. Certificates are issued for specific names and dates. When an entry’s destination changes — a landing page moved to a new host, a new subdomain created after an acquisition consolidation, or a landing page swapped after the ad went live — the certificate on the new destination frequently does not match yet. Wildcards cover only the names they were issued for, and a freshly issued certificate can still omit the exact hostname the entry points to.

Why the warning can look inconsistent

The same entry can warn on one device and load on another. Three reasons: the browser cached an older redirect response; the destination sent an HSTS (Strict-Transport-Security) header and the browser now refuses any HTTP downgrade for that domain for the policy’s duration; or the device’s clock is wrong, which makes any certificate look expired. As the MDN reference on Strict-Transport-Security explains, once a browser has seen that header it blocks plain-HTTP connections to the host — so a destination moved from HTTPS back to HTTP keeps triggering warnings even though the entry itself “works.”

Practical limits of what you can check

• You cannot inspect the destination’s certificate from the entry Console. The Console shows the entry’s configuration — target URL, status, access statistics, logs, and traceable changes — not the destination’s TLS state.
• Public SSL checkers test from their own servers; useful as a complement, but they cannot replace a real browser session on a visitor’s device.
• You cannot renew or replace a destination certificate from your side. Only the destination’s owner can.
• Do not conclude “the site is fine” from a single browser. Confirm in an incognito window, a second browser, and a device with accurate time.

Decision Framework

Check	What it tells you	Who owns the fix
Open the subdomain in an incognito window and watch the URL bar	Whether the warning appears before or after the redirect	You (diagnosis)
Confirm the final URL’s protocol is https://	Mixed content after the redirect	You (update the entry target)
Click the padlock and inspect the certificate’s validity dates	An expired certificate on the destination	Destination owner
Compare the certificate’s hostname/SAN with the final URL	A hostname mismatch on the destination	Destination owner
Review the entry’s change log for recent target edits	A change the certificate hasn’t caught up to	You + platform owner
Verify the subdomain’s DNS resolves to the forwarding platform	A broken or half-propagated entry	DNS/platform owner

Then apply the decision rules:

• Warning appears before the redirect → entry-side problem (DNS, platform infrastructure) → involve the DNS/platform owner instead of guessing.
• Redirect fires, final URL is http:// → protocol mismatch → update the entry target to the HTTPS URL.
• Redirect fires, final URL is https://, certificate expired or mismatched → destination-side → the destination owner renews or replaces the certificate.
• Entry works in one browser but not another → cache, HSTS, or clock skew → re-test incognito on an accurate-time device; if HSTS is blocking, the destination owner must fix the protocol.

When the destination is outside your control and you cannot reach its administrator, escalate with evidence: the final URL after the redirect plus the certificate details. That turns a guess into a ticket.

Key Takeaways

• A subdomain SSL certificate error on a campaign entry is a destination problem in most cases — check the final URL, not the entry.
• Split every diagnosis into two layers: the entry controls where the browser goes; the destination controls whether TLS works there.
• The top three causes, in order: a plain-HTTP destination, an expired certificate, and a certificate that doesn’t match the hostname after a recent change.
• Re-test in an incognito window on an accurate-time device before escalating anything.
• If warnings are reported or clicks are flat, check the entry before rewriting the ads — the fix is usually one configuration change away, and the entry’s traceable change history tells you exactly what changed and when.
• Fix before launch: visitors who hit a browser warning rarely proceed, and mid-campaign is the worst possible time to discover it.

FAQ

Q: The entry worked yesterday — what changed? A: Start with the destination. Certificates expire on fixed dates, so expiry is the most common “it worked yesterday” cause. Then check whether anyone edited the entry’s target (the change log will show it) and whether the destination moved to a host without a matching certificate. Also remember that browsers cache redirects: the entry may have been misconfigured for a while while visitors still saw the old, cached response.

Q: Can I fix the certificate from the PushULink Console? A: No. The Console manages the entry — target URL, status, access statistics, logs, and traceable changes. Certificates live on the destination server and can only be renewed or replaced by that server’s owner. What you can do from the Console is correct the entry: point it at the HTTPS version of the URL, or at the exact hostname the destination’s certificate actually covers.

Q: Why does the warning show in one browser but not another? A: Because the warning is computed client-side. Common causes: a cached redirect response, an HSTS policy the destination previously sent (which makes the browser refuse HTTP for that domain for the policy’s duration), or a device clock that is off, which makes any certificate look expired. Re-test in an incognito window on a device with accurate time. If the warning only appears where an HSTS policy exists, the destination’s protocol is the problem.

Q: The destination loads fine when I open it directly. Why does the subdomain warn? A: Because the subdomain entry points somewhere other than where you typed. Open the subdomain, watch the URL bar change, and compare the final URL with the destination you believe you configured. The usual culprits are a wrong protocol (http:// instead of https://), a wrong hostname (apex vs. www), or a trailing path the entry adds. That comparison is your first diagnostic step.

Sources

• RFC 9110 — HTTP Semantics: redirect status codes and the Location header — https://www.rfc-editor.org/rfc/rfc9110
• MDN Web Docs — Redirections in HTTP: how browsers follow redirect chains — https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
• Google Chrome Help — Fix “Your connection is not private” errors — https://support.google.com/chrome/answer/6098869
• MDN Web Docs — Strict-Transport-Security header reference — https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security