VPN access to https

[Alex]

So i just set up the clientless vpn on ASA and opened a test http website. It worked as expected. Then i tried to access httpS://www.google.com and that opened with no problems!! But i don't have any CAs installed! Then i tried a local httpS server with a self signed cert and it opened as well. Why did the httpS site worked? Doesn't ASA check the certs or at least prompt when it cant verify a self signed cert???

[Marcin Latosiewicz]

Aleksey, 

Clientless certificate validation was introduced in 9.0.1 release if memory serves well.

http://www.cisco.com/c/en/us/td/docs/security/asa/asa90/release/notes/asarn90.html

Under "Clientless SSL VPN: Server Certificate Validation"

M.

[Alex]

Can you expand a bit on that?

I'm running 9.2(3) ASA

This feature enhances clientless SSL VPN support to enable SSL server certificate verification for remote HTTPS sites against a list of trusted CA certificates.We modified the following commands: ssl-server-check, crypto, crypto ca trustpool, crl, certificate, revocation-check.

So the way i read it it should be verifying https connection against a list of trusted certs? Is there a way to turn it on/off??

[Marcin Latosiewicz · Accepted solution]

SSL Certificate Verification
During the SSL handshake between ASA and remote ssl server, the remote server sends ASA a certificate to authenticate itself. The ASA verifies the server certificate against a list of trusted server CAs in trustpool and trustpoint of PKI subsystem. The verification includes the following items:
Check the server certificate's validity period
Check the server certificate against CAs in the trustpool and trustpoints
Check the server certificate if it matches the domain name, hostname, or ipaddress of the server according to RFC2818, matching rules specified by RFC2459
Check the server certificate's key usage
Check the server certificate's revocation status(CRL or OCSP) 
If all the verifications are passed, the server is authenticated. ASA proceeds with SSL handshake. Otherwise end users are warned of the server certificate problem and informed the reason.
If ASA was configured with “warn-on-failure”, end users can choose continue or not. If continue, the channel between ASA and remote server is still secure, but the identity of the server is untrustworthy.
If configured with “deny-on-failure”, the connections to remote https site were disconnected and end users cannot continue. 
Trustpool Management
The trustpool management feature designates a single configuration object called a trustpool. The trustpool can be thought of as a special case of a trustpoint that will represent multiple known CA certificates. The feature includes a configurable policy that governs how the trustpool certificates are used. 

Config 

 ciscoasa(config-webvpn)# ssl-server-check ?
 webvpn mode commands/options:
 deny-on-failure  Disconnect the connection and show the denying page to end
                  users on failure of verification
 warn-on-failure  Show the warning page to end users on failure of
                  verification

[Alex]

Yep that's exactly what i was missing thanks.

Now if i could piggy back on this, after i turned on the

ssl-server-check deny-on-failure

as expected it failed to load httpS site with self signed cert and gave the following error in the browser

The certificate does not pass the criteria to be trusted.
The security certificate is self signed

So i created a new trustpoint and enrolled that self signed cert from terminal. But now on the clientless browser i get

The website is not trusted because the whole certificate chain didn't pass verifications.

and the logs just say

Certificate chain failed validation. Generic validation failure occured.

Since it's a self signed cert there's no chain per se it's just one CA. Any ideas? Or specific debug commands? Not finding much documentation on this

Check the server certificate's validity period

<pre>sh crypto ca certificates</pre>

Shows Validity Date is good for next 5 years. ASA's clock is correctly set
Check the server certificate against CAs in the trustpool and trustpoints
Guessing it's doing it as without the trustpoint it gives a different error

Check the server certificate if it matches the domain name, hostname, or ipaddress of the server according to RFC2818, matching rules specified by RFC2459

I do have correct ip in "cn=" also browsers don't seem to have an issue with this once accepted. Looking into RFC2818 & 2459

[Marcin Latosiewicz]

Alex, 

Perhaps trustpool operations? Is that CA cert part of trustpool? 

In practice for internet operations, you can pull the bundle from Cisco using 

cry ca trustpool import url http://www.cisco.com/security/pki/trs/ios.p7b

Not sure how up to date it is. 

As for debugging, there are some targeted debugs using debug menu - you better run those with TAC. 

in general 

debug webvpn session 10

debug crypto ca trustpool

M.