Troubleshoot AnyConnect Login and Certificate Problems on ASA

AnyConnect (Cisco Secure Client) login failures fall into a small handful of categories, and each one has its own debug path on the Cisco ASA. The two most common are AAA failures (the user typed a wrong password, or the AAA server is unreachable, or the user does not have permission to use this connection profile) and certificate failures (the gateway cert is expired, the FQDN does not match, or the client cert is not trusted). This article maps each symptom to the exact show / debug command that confirms the cause, and how to fix it. All output is from a live ASAv 9.23(1) in the PingLabz ASA reference lab.

Before diving in, two prerequisites: a working AnyConnect connection profile (see Cisco ASA AnyConnect SSL VPN Configuration), and a basic understanding of the AAA layer (see Cisco ASA AAA for VPN: LDAP, RADIUS, and TACACS+). For lower-layer (Phase 1 / Phase 2) IPsec troubleshooting, see Troubleshoot Cisco ASA IPsec VPN Phase 1 and Phase 2.

Symptom-to-Cause Quick Reference

AAA Login Failures

Step one is always to confirm whether the user reaches the ASA at all. show vpn-sessiondb anyconnect shows zero active sessions; show logging | include AAA-3-1 shows the AAA failure messages.

ASA-PERIM# show logging | include AAA
%ASA-6-113004: AAA user authentication Successful : server =  10.10.0.10 : user = vpnuser
%ASA-6-113008: AAA transaction status ACCEPT : user = vpnuser
%ASA-6-113009: AAA retrieved default group policy (ANYCONNECT-SSL-GP) for user = vpnuser

That is what success looks like. Three messages: authentication succeeded, AAA accepted the user, the default group-policy was retrieved.

What failure looks like:

%ASA-6-113005: AAA user authentication Rejected : reason = Invalid password : server = 10.10.0.10 : user = vpnuser
%ASA-6-113008: AAA transaction status REJECT : user = vpnuser
%ASA-3-113023: Removed login record. AAA group: RADIUS-VPN, user: vpnuser

If the AAA server is unreachable instead of rejecting:

%ASA-3-113022: AAA Marking RADIUS server 10.10.0.10 in aaa-server group RADIUS-VPN as FAILED
%ASA-6-113025: User exit from AAA: too many auth attempts

The "too many auth attempts" message means RADIUS retry/retry-interval timed out. Check the network path from the ASA's inside interface to the RADIUS server, the shared secret, and the RADIUS server's nas-secret entry for the ASA's IP.

The Single Command That Saves an Hour

ASA-PERIM# test aaa-server authentication RADIUS-VPN host 10.10.0.10 username vpnuser password TEST
INFO: Attempting Authentication test to IP address <10.10.0.10> (timeout: 12 seconds)
ERROR: Authentication Rejected: AAA failure

The test aaa-server command exercises the full path from ASA to AAA server, with a known username and password, without involving the VPN client at all. If test aaa-server succeeds but real client login fails, the problem is on the client side or in the tunnel-group's authentication binding. If test aaa-server fails too, it is an AAA-server reachability or shared-secret problem.

Certificate Failures (Gateway Side)

The most common cause of a "Certificate validation failure" message is that the cert the ASA presents has an FQDN mismatch with the URL the client used to connect.

Check what cert the ASA is actually serving:

ASA-PERIM# show ssl
Accept connections using SSLv3 or greater and negotiate to TLSv1.2 or greater
Start connections using TLSv1.2 and negotiate to TLSv1.2 or greater
SSL DH Group: group14 (2048-bit modulus, FIPS)
SSL ECDH Group: group19 (256-bit EC)

SSL trust-points:
  Self-signed (RSA 2048 bits RSA-SHA256) certificate available
  Self-signed (EC 256 bits ecdsa-with-SHA256) certificate available
  Interface outside: PINGLABZ-SELFSIGNED (RSA 2048 bits RSA-SHA256)
Certificate authentication is not enabled

The trustpoint bound to outside is what clients see. Run show crypto ca certificates to see the actual subject CN, validity, and issuer:

ASA-PERIM# show crypto ca certificates
Certificate
  Status: Available
  Certificate Serial Number: 69ffc240
  Public Key Type: RSA (2048 bits)
  Signature Algorithm: RSA-SHA256
  Issuer Name:
    unstructuredName=vpn.pinglabz.lab
    C=US
    O=PingLabz
    CN=vpn.pinglabz.lab
  Subject Name:
    unstructuredName=vpn.pinglabz.lab
    C=US
    O=PingLabz
    CN=vpn.pinglabz.lab
  Validity Date:
    start date: 00:37:39 UTC May 10 2026
    end   date: 00:37:39 UTC May 7 2036
  Storage: config
  Associated Trustpoints: PINGLABZ-SELFSIGNED

Three things to check on this output:

• Subject CN: must match the FQDN the client typed. If the client connects to vpn.pinglabz.com but the cert CN is vpn.pinglabz.lab, the AnyConnect client refuses.
• Validity Date: end date must be in the future. Renew the cert if not.
• Issuer Name: for a real CA-signed cert, the issuer must be a CA the client trusts. Self-signed certs trip warnings unless the user has imported the cert into their trust store.

The Missing Intermediate Cert

A subtle and confusing failure: the cert chain on the ASA is missing the intermediate CA. Browsers usually patch this from their cache and connect anyway; AnyConnect does not. Fix by also importing the intermediate CA's cert into a trustpoint and binding it via the same SSL listener.

ASA-PERIM(config)# crypto ca trustpoint INTERMEDIATE-CA
ASA-PERIM(config-ca-trustpoint)#  enrollment terminal
ASA-PERIM(config)# crypto ca authenticate INTERMEDIATE-CA
... (paste intermediate CA PEM)

Verify the chain is now complete with show crypto ca certificates; both your identity cert and the intermediate should appear with linked Associated Trustpoints.

"User Not Authorized" Errors

Two flavors of this error and they have different fixes:

No AnyConnect Image Configured

ASA-PERIM# show webvpn anyconnect
AnyConnect Client is enabled. No images configured

The fix is to copy the .pkg image to flash and reference it under webvpn:

ASA-PERIM(config)# webvpn
ASA-PERIM(config-webvpn)#  anyconnect image flash:/cisco-secure-client-win-5.1.10.233-webdeploy-k9.pkg 1

The integer is a priority; lower numbers tried first. Multiple images for different OS families can coexist.

Wrong vpn-tunnel-protocol

If the user connects via SSL but the group-policy bound to that tunnel-group has vpn-tunnel-protocol ikev2 only, the client gets "unauthorized connection mechanism." Check the group-policy:

ASA-PERIM# show running-config group-policy ANYCONNECT-SSL-GP
group-policy ANYCONNECT-SSL-GP internal
group-policy ANYCONNECT-SSL-GP attributes
 dns-server value 10.10.0.10
 vpn-tunnel-protocol ssl-client
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value SPLIT-TUNNEL
 default-domain value pinglabz.lab
 webvpn
  anyconnect ssl dtls enable
  ...

Make sure vpn-tunnel-protocol includes ssl-client for SSL clients and ikev2 for IKEv2 clients. To allow both: vpn-tunnel-protocol ssl-client ikev2.

Connection Profile Selection Issues

The user lands on the wrong tunnel-group, so the wrong AAA / group-policy / pool is in effect. Two reasons this happens:

• tunnel-group-list enable not set: the dropdown of group-aliases never appears on the portal page; users always land on DefaultRAGroup. Fix in the global webvpn block.
• group-url not configured: clients hitting https://vpn.pinglabz.com/employees do not get auto-routed to the EMPLOYEES tunnel-group. Add group-url https://vpn.pinglabz.com/employees enable to the tunnel-group's webvpn-attributes.

DAP Termination Logs

If DAP is configured (see Cisco ASA Dynamic Access Policies (DAP)) and a record's action terminate fires, the user sees the configured user-message and the connection drops. The log entry:

%ASA-4-113021: Login Denied. The DAP policy <NO-AC-NO-ENTRY> specified action of TERMINATE

If the named DAP record is not what you expected, run debug dap trace during a test login and see which selectors fired. Always disable that debug after the test.

Trace the Traffic Path Once Login Succeeds

Login succeeded but the user reports "no internal resources work". Use packet-tracer with the user's pool-assigned IP as the source:

ASA-PERIM# packet-tracer input outside icmp 10.99.99.10 8 0 10.10.0.5 detailed

Check that the packet-tracer output shows the NAT exemption rule firing (Section 1 manual NAT for the VPN pool), the ACL phase passing, and the route phase finding the inside interface as egress. If any phase drops, that's the next thing to fix. NAT exemption is the most common culprit; Cisco ASA Identity NAT / NAT Exemption for VPNs walks the full pattern.

High-Value Debug Commands

Key Takeaways

AnyConnect troubleshooting on the Cisco ASA reduces to a small set of causes and a single show command for each. AAA failures show in the %ASA-6-113xxx log range and are confirmed via test aaa-server authentication. Cert failures show up as TLS handshake errors on the client and are diagnosed via show ssl certificate and show crypto ca certificates. Group-policy or tunnel-group misconfig shows up as "unauthorized connection mechanism" and is diagnosed via show running-config group-policy. Network-path issues are diagnosed with packet-tracer. Always pair every debug with a no debug in the same change so production never gets stuck under verbose tracing.

For the full Cisco ASA reference, including site-to-site IPsec, NAT, ACLs, failover, and the troubleshooting tools, see the Cisco ASA pillar. For lower-layer IPsec failures, see Troubleshoot Cisco ASA IPsec VPN Phase 1 and Phase 2; for the cert lifecycle that this article tests against, return to Cisco ASA Certificate Management for AnyConnect.