AnyConnect Cannot Confirm It Is Connected To Your Secure Gateway

This AnyConnect warning points to a trust check failure, often a certificate or network trust issue, so the tunnel won’t complete as expected.

If you’re seeing this message, you’re stuck in a frustrating middle ground. AnyConnect starts the connection, then it refuses to finish because something about the gateway identity or the network path doesn’t pass its safety checks.

You can often clear it in minutes with a few targeted checks. The trick is to fix the cause, not click past warnings or random settings.

What This AnyConnect Message Is Telling You

AnyConnect builds a TLS session to the VPN gateway (ASA, Firepower/FTD, Secure Firewall, Meraki MX, or another secure gateway). During that handshake it checks who it is talking to and whether the local network looks safe enough for the profile rules.

When the client can’t validate the gateway identity, or a profile rule says the current network can’t be trusted, it blocks the tunnel and shows the warning about not being able to confirm the secure gateway.

AnyConnect Cannot Confirm It Is Connected To Your Secure Gateway

You’ll often see this after a certificate change, a new Wi-Fi network, a captive portal, a wrong hostname, a clock drift on your device, or network gear that interferes with TLS.

Fast Checks That Fix Most Cases

Quick Pass — Run these checks in order. Stop when the connection works and stays up for a minute.

Switch networks — Try mobile hotspot or a different Wi-Fi to rule out a blocked or intercepted connection path.
Open a normal website — Sign in to any Wi-Fi login page first, then retry the VPN.
Confirm the VPN gateway — Use the exact gateway name your company provided, not an IP or a guess from an old bookmark.
Check date and time — Set time to automatic, then restart AnyConnect so certificate dates line up.
Restart the client — Quit AnyConnect fully, then launch it again so it reloads the profile and trust state.

If you get a prompt about an untrusted server certificate, don’t accept it blindly. A real attacker on public Wi-Fi can spoof a gateway name and steal credentials. Treat that prompt as a sign you need a clean trust chain.

Cause	What You Notice	What To Try
Wrong hostname	Certificate name mismatch, repeats on every try	Use the official FQDN from your IT desk
Device clock drift	Certificate looks expired or not yet valid	Enable automatic time, then retry
Captive portal	VPN fails on hotel or café Wi-Fi	Log in to Wi-Fi first, then reconnect
TLS inspection	Works on hotspot, fails on office guest Wi-Fi	Try a different network or ask IT to exempt VPN

AnyConnect Cannot Confirm Secure Gateway Connection On Untrusted Networks

Some profiles run in “Always-On” mode or use a network trust list. In that setup, AnyConnect checks the current network name, DNS suffix, or other signals before it allows a tunnel. If it decides the network is not trusted, it can block the session even when the gateway certificate is fine.

This shows up a lot when you move between home Wi-Fi, office Wi-Fi, and public networks. The VPN may connect at home, then fail at a hotel with the same gateway.

Try a hotspot — If a hotspot works instantly, the local Wi-Fi path is the likely trigger.
Turn off captive portal helpers — Disconnect from Wi-Fi, reconnect, complete the sign-in page, then retry.
Check for a proxy — On managed devices, proxy settings can break the TLS path to the gateway.

If your company controls the profile, you may not have access to the “block untrusted networks” toggle. In newer Cisco Secure Client builds, many preferences are locked down by policy.

One more quick test. Try the same gateway over a wired connection or your phone hotspot. If it works there, your local router may be rewriting DNS or blocking UDP. Reboot the router, turn off any “security” filtering, and retry. If you can’t change those settings, switch networks. Then connect again and watch prompts.

Fixes On Windows That Target The Root Cause

Windows machines tend to hit this message for three reasons: trust store problems, network interception, or a profile mismatch after an update.

Certificate And Trust Store Fixes

Retry and read the certificate prompt — Note the issuer and the server name shown, then cancel instead of accepting.
Update Windows — Install pending updates, then reboot so root certificate updates apply.
Remove stale certificates — If you have a custom root from an old VPN or filter tool, remove it only if it’s not required by your organization.

Network Path Fixes

Disable auto proxy detection — In Windows settings, turn off auto proxy detection and retry if you’re off-site.
Test IPv4 only — Temporarily disable IPv6 on the active adapter and retry if your network breaks dual-stack routing.
Allow AnyConnect through firewall — Check that local firewall rules are not blocking the VPN adapter or vpnagent.

Client Reset Steps

Clean Reset — These steps help when the install is fine yet settings drifted.

Sign out of the client — Disconnect, then quit AnyConnect from the tray so it stops fully.
Reopen as a normal user — Launch it again, enter the gateway name, then connect once before adding extra options.
Reinstall Cisco Secure Client — Use your company package so the right modules and profile land in the right folder.

If you still see the same warning after a reinstall and a clean network, it’s time to gather logs so your IT desk can see what the client is rejecting.

Fixes On macOS And Mobile Devices

On macOS, the client depends on the macOS certificate store and the active network path. On iOS and Android, the OS VPN stack can add another layer of prompts and permission checks.

macOS Steps

Confirm the gateway name — Use the FQDN, then retry on a second network to rule out Wi-Fi filtering.
Check for a captive portal — Open Safari, visit a plain HTTP site, finish any sign-in, then reconnect.
Review certificate trust prompts — If a certificate trust dialog appears, cancel it and report the issuer and name to IT.

iPhone And iPad Steps

Close and reopen the app — Swipe it away, launch again, then connect once without switching networks mid-try.
Forget and rejoin Wi-Fi — Rejoin the network so the portal step completes, then retry.
Remove old VPN profiles — Delete stale VPN configurations that point to older gateways.

Android Steps

Allow VPN permission — Accept the system VPN permission prompt and retry if it was dismissed earlier.
Disable private DNS temporarily — If you use a custom private DNS provider, turn it off and retry so gateway name resolution matches the profile.
Restart the phone — A reboot clears stuck VPN services that can block a fresh tunnel.

When the same account works on one device and fails on another, the device trust store or local network stack is usually the difference, not the username or password.

Gateway And Policy Checks For Network Admins

If you manage the secure gateway, this warning often points to certificate chain, name match, or policy behavior that is working as designed. Users see it as a sudden break after a renewal or a profile push.

Start by reproducing the issue on a clean network like a phone hotspot. That separates local Wi-Fi interference from a gateway-side change.

Certificate Chain And Name Match

Match the FQDN to the certificate — The gateway certificate must include the exact public name users type, as a SAN entry or the common name.
Serve the full chain — Install the intermediate certificates on the gateway so clients can build trust to a root they already have.
Check validity dates — A renewed cert can be valid, yet client clocks drift and make it appear “not yet valid” to the handshake.
Watch for TLS inspection — Guest Wi-Fi with HTTPS interception can swap certificates and trigger the warning even with a clean gateway setup.

Revocation Reachability

Certificate-based setups can fail when the client can’t reach the revocation endpoints referenced by the certificate chain. That can happen on locked-down networks that block OCSP or CRL traffic.

Test OCSP and CRL access — Confirm the client network can reach the CA endpoints used by your PKI.
Review profile rules — Network trust lists and Always-On settings can block “untrusted” networks even when the certificate is valid.

Transport And Module Settings

Try disabling DTLS — Some gateways and networks break DTLS while TLS works, so a TLS-only test helps isolate the path.
Validate SNI and load balancers — A load balancer that presents the wrong certificate for a given host name will trigger a name mismatch.
Confirm the client package — Mixed Cisco Secure Client modules and old profiles can create odd prompts after an upgrade.

On Meraki MX deployments, a self-signed or interim certificate can trigger trust warnings until a publicly trusted certificate is in place. On ASA/FTD, a missing intermediate chain is another common culprit.

Gather The Right Logs And Details Before You Escalate

Your IT desk will move faster if you send details that point at the exact failure. A vague “VPN broke” message forces guesswork.

Capture the full error text — Include the exact wording and any error code shown under the message.
Write down the gateway FQDN — Include the typed URL, not a nickname.
Note your network type — Home Wi-Fi, office Wi-Fi, hotel Wi-Fi, or mobile hotspot.
List client and OS versions — Cisco Secure Client/AnyConnect version plus Windows, macOS, iOS, or Android version.

For Cisco Secure Client, DART (Diagnostics and Reporting Tool) bundles the logs into a single file that can be shared with your IT desk or Cisco TAC. Cisco documents DART collection steps for Windows and macOS, and it’s often the fastest way to show what happened during the TLS handshake.

Run DART diagnostics — Open DART from the Start menu or Cisco Secure Client, then collect a diagnostics bundle.
Reconnect once before collecting — Trigger the error again so the log captures the failure at the right time.
Send the bundle securely — Use your company’s file share or ticket portal rather than email attachments when rules require it.

If the ticket asks what changed, mention any of these: a new Wi-Fi router, a new ISP, a new client version, a new gateway URL, or a certificate renewal window.

When you write the report, include this sentence once so it matches common ticket searches: “anyconnect cannot confirm it is connected to your secure gateway.”

If you hit the same message again on a second network, include it again in the ticket: “anyconnect cannot confirm it is connected to your secure gateway.”