AnyConnect Untrusted Server Warning: Accept or Import?

You paste the gateway hostname into AnyConnect, the window goes red or white, and a dialog asks whether to trust a server whose certificate the client cannot verify. The natural move is to click through and get to work, and that is exactly the wrong reflex. The answer is written into the client's preferences on that machine and applies to later connections, so the dialog is a configuration decision wearing the costume of a one-time warning. Here is the pass I make, in the order the client shows it.

Start from the warning you actually see

Red and white are not cosmetic variants. The red warning means the profile or preference is set to block untrusted servers, so the client refuses to continue until that setting changes; the white warning means it will let you proceed once you answer explicitly. A third case looks similar and behaves differently: an expired certificate, which the client will not offer to import at all, because importing it would not make it valid. Sorting the three takes a second and decides everything that follows.

Behind all of them sits one short list of causes: a self-signed gateway certificate, a private CA the endpoint does not trust, or a hostname that is missing from the certificate's subject alternative names. Any of the three produces the same dialog and needs a different fix.

Read the certificate before you answer the dialog

Open the certificate details from the warning and look at three fields before you touch a button. The subject and SAN should name the gateway you actually intended to reach, the issuer should be the CA your organization runs, and the validity dates should cover today. Then compare the SHA-256 fingerprint against a copy you obtained somewhere other than this connection, an internal documentation page or a ticket, because a fingerprint read off the same dialog proves nothing at all. If you cannot find an independent copy, you have no basis for accepting the exception.

This is the step that separates a lab from a production gateway. On a test box with a self-signed certificate you generated yesterday, clicking through is reasonable. On a corporate gateway where users type credentials next, a certificate you cannot verify is a plausible interception setup, and the client is the only component still asking the question.

Know what each answer writes to the trust store

Answering yes to the import question adds the gateway's certificate to the client's trusted store on that machine. It is not a per-session exception: later connections can complete without the same prompt, which is the point and also the risk, because nothing on screen reminds anyone that the exception exists. Answering no continues the login for this session only. Both paths get you connected, and only one of them changes the machine.

If you are on the red path, the first attempt is not a login at all. The documented input sequence is a connect line followed by two confirmations, which changes the preference and exits; a script that treats that as success has saved a setting and never authenticated. The certificate-import question only appears on the next attempt, which is why people conclude the prompt is intermittent.

That order matters for automation, not just for fingers. A scripted answer that always says yes keeps working after the gateway changes, and keeps trusting whatever certificate appears next.

Script the answers in the order the client asks

When the client warns but allows the connection, the answers arrive in a fixed order: connect, yes to continue, then the import question, then the group, the username, and the password. Write those as separate lines in the input file instead of guessing at prompt timing. Declining the import is a single character change in the same file, and it is the safer default for anything that runs unattended.

connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORD

Prefer distributing the organization's CA to the endpoints over teaching every script to accept a leaf certificate. A properly issued certificate with the right SAN removes the prompt for everyone, keeps validation meaningful, and does not depend on one endpoint's memory of a decision. Installing a root CA is a heavier change than importing a leaf, so treat it as a managed rollout rather than a help-desk shortcut.

Remove the exceptions that outlive their gateway

AnyConnect saves these preferences per machine, so old answers accumulate on laptops that have moved between offices. Review the saved preferences and the imported certificates on managed endpoints, and check whether an exception still names a hostname that has changed owners. A preference that accepts any untrusted server is broader than the certificate it was created for.

The pattern worth keeping is narrow: a trusted certificate for normal use, a documented out-of-band fingerprint check for a temporary exception, and a named owner who removes it when the migration ends. If you find a blanket accept-any-server setting on a machine you manage, treat it as a finding rather than a convenience.