ASA SSL certificate report on ssllabs.com

[Jason Boston]

Morning friends,

I have an ASA 5512 running only an IPSEC VPN tunnel. My third-party signed cert (Verisign) is the only identity cert and it is set to my "device certificate" and it seems to work great for my users who are connecting via AnyConnect remote desktop. They no longer receive "You are connecting to an un-trusted server".

So yesterday my boss heard about ssllabs.com and decided to put in our URL. This is a specific URL that ONLY hosts the ASA. No site. No clienteles SSL VPN or anything. All it allows is IPSEC remote VPN connections through AnyConnect. 

The result... an F. Apparently it's receiving a certificate that is self signed by the ASA. So the grade is all down-hill from there and I'm being questioned "why".

I'm wondering as well. Shouldn't the test pickup my Verisign signed SSL certificate? Even though I'm not hosting any site on the URL?

Any guidance would be appreciated!

Thank you,

_J

[Karsten Iwen · Accepted solution]

ssllabs.com tests with ssl/tls and not with IPsec. Have you configured your ssl to use your trustpoint?

ssl trust-point YOUR-TRUSTPOINT outside

But don't expect a good grade. Although untested, I assume that an "A" is only possible with ASA version 9.3(2) and higher.

[Jason Boston]

Thanks Karsten! That did it. Now I need to fix the Poodle vuln. Apparently the workaround didn't work for my version. Time to do an update!

[Marvin Rhoads]

Even with a properly issued and associated Verisign certificate, we will still get an "F" until Cisco releases a fix for the POODLE TLS vulnerability that affect ASA software.

[Karsten Iwen]

Hi Marvin,

do you already have an ASA with 9.3(2) running? I would be interested what the score is with and without TLS1.2 only configured.

At least 9.2(3) which is quite new is still affected by POODLE.

Have a great day, Karsten

[Marvin Rhoads]

Hi Karsten - the couple of ASAs I have with 9.3(2) don't have a public-facing FQDN so I cannot run the Qualys tester against them.

It's kind of ironic that this bug has come back up with TLS. All the cool kids who had already deprecated SSL were bragging about how superior TLS is when the bug was first associated only with SSL.

[jeremey.sansom1]

Hello,

Do you know if this has been patched yet?

Thanks,

J

[Jason Boston]

That's interesting. I just assumed that my inability to find a Cisco report for POODLE TLS was just me not looking in the right place. I guess I assumed it would have been fixed by now. 

In all honestly though, since I'm only running IPSEC can I close port 443 on my domain anyway? I was under the impression this was required for the certificate verification upon connection to IPSEC, but now I'm not sure. I'm too afraid to test it at the moment. I would have to try it later today. 

Thanks again for all of your great help with this.