Issue with Thawte SSL123 Certificate intermediate chain

[kpruett]

Hi,

I have a problem getting correct chain verification I think while using a Thawte SSL123 certificate on an ASA 5520 running AnyConnect SSL VPN. I noticed when both using the client as well as when using AnyConnect mobile that a security error results, forcing the user to accept before connecting.

Thawte issues the 123 series certs with both a first intermediate and second intermediate cert for the entire chain. I think I may have missed one of these in my installation of the certs onto the ASA, but I'm unsure if I can just add another CA cert on that same trustpoint, or what I need to do. Specifically, help for fixing the issue, and/or how to handle multiple intermediate certs for a chain issued ssl cert on an ASA.

A copy of my show crypto ca cert is below, names changed to protect the innocent:

CA Certificate

  Status: Available

  Certificate Serial Number: 7610128a17b682bb3a1f9d1a9a35c092

  Certificate Usage: General Purpose

  Public Key Type: RSA (2048 bits)

  Signature Algorithm: SHA1 with RSA Encryption

  Issuer Name:

    cn=thawte Primary Root CA

    ou=(c) 2006 thawte\, Inc. - For authorized use only

    ou=Certification Services Division

    o=thawte\, Inc.

    c=US

  Subject Name:

    cn=Thawte DV SSL CA

    ou=Domain Validated SSL

    o=Thawte\, Inc.

    c=US

  OCSP AIA:

    URL: http://ocsp.thawte.com

  CRL Distribution Points:

    [1]  http://crl.thawte.com/ThawtePCA.crl

  Validity Date:

    start date: 19:00:00 EST Feb 17 2010

    end   date: 18:59:59 EST Feb 17 2020

  Associated Trustpoints: mysite.mycompany.com.trustpoint

Certificate

  Status: Available

  Certificate Serial Number: 17f7b3d30f075a368aefbdbc410d291d

  Certificate Usage: General Purpose

  Public Key Type: RSA (2048 bits)

  Signature Algorithm: SHA1 with RSA Encryption

  Issuer Name:

    cn=Thawte DV SSL CA

    ou=Domain Validated SSL

    o=Thawte\, Inc.

    c=US

  Subject Name:

    cn=vpn-na.doosan.com

    ou=Domain Validated

    ou=Thawte SSL123 certificate

    ou=Go to https://www.thawte.com/repository/index.html

    o=vpn-na.doosan.com

  OCSP AIA:

    URL: http://ocsp.thawte.com

  CRL Distribution Points:

    [1]  http://svr-dv-crl.thawte.com/ThawteDV.crl

  Validity Date:

    start date: 20:00:00 EDT May 14 2012

    end   date: 19:59:59 EDT May 14 2016

  Associated Trustpoints: mysite.mycompany.com.trustpoint

[Andrew Phirsov]

but I'm unsure if I can just add another CA cert on that same  trustpoint, or what I need to do. Specifically, help for fixing the  issue, and/or how to handle multiple intermediate certs for a chain  issued ssl cert on an ASA.

What i usually do, and it works fine with ASA, is i authenticate trustpoint with a certificate of a the last CA in a chain, i.e. certificate of the CA wich directly issued the client certificate. As it turned out, ASA doesn't chek whole certificate chain.

[kpruett]

Yeah I think in this case I used the root or first intermediate. Strangely, SSL check tools show it okay, but clients connecting show that not to be the case. Surely there is a way to have multiple intermediates in a chain. Otherwise my re-shopping list for a cert is going to get expensive.

[Andrew Phirsov]

Client-site is a different question and not related to chain-config on an ASA. Client devices typically should have full chain installed.

[kpruett]

Sorry Andrew, I meant clients connecting to the SSL VPN running on that ASA. The cert on the ASA shows as invalid, if using AnyConnect or AnyConnect Mobile.

[Andrew Phirsov]

Hi,

again, if clients reject certificate on an asa it means only one thing - they don't trust that certificate, i.e. PCs, from wich you're connecting to webvpn portal don't have full chain installed on them. ASA doesn't require to have full chain for sslvpn to work, but clients, connecting to that ASA should have Root CA certificate and certificates of all the Sub CAs installed.

[kpruett]

Andrew that's actually the problem. I don't have access to all the clients connecting. Even if I did, I do not have the capability to add root ca's to every mobile device. Surely there is something on the ASA itself I can do to force the full chain to be attached to the cert on the device?

[Andrew Phirsov]

There is a chain command under tunnel-group ipsec attributes:

tunnel-group GROUPNAME ipsec-attributes

chain

That should do it, but i never tried)