cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8963
Views
5
Helpful
4
Replies

ASA // certificate-handling (trustpoints)

Hi!

I have a  question regarding certificate-handling in the ASA (for example for  using it for AnyConnect).

I'm not talking of the internal CA  here, just about handling certificates coming from an external CA.

If  you configure a trustpoint on the ASA - can the trustpoint itself  contain i whole hierarchy of certificates? For example, one  root-CA-certificate, one intermediate-CA-certificate, and one  certificate for the ASA itself, where the ASA holds the private key,  too?

For me it would be logical, but I can't do it. I always have  to configure a separate trustpoint for each level - in this case two:  One for the certificate of the root-CA, the second for the  intermediate-CA. The second than also holds the certificate of the ASA  itself.

Is this really the "right" way to do it? I get everything  to work (validation and stuff) when using the second way, but I'm  confused because of the command "crypto ca certificate chain  <trustpoint>", which for me indicates that it should indeed be  possible to have a complete chain of certificates, a complete hierarchy  so to speak, associated to this trustpoint.

The documentation  didn't help me out here.

Thanks for clarification.
Florian

4 Replies 4

I will just add  another snippet of information, to make even more clear what I mean.

This  is the configuration of my lab-ASA. It holds 3 (three!) trustpoints,  which basically are all from the same CA (it's the free startssl.com  CA).

startssl.com-root is the trustpoint holding the  root-certificate. startssl.com-client is one intermediate CA of  startssl.com. It issues certificates for clients (for instance, I have a  WebVPN-User having such a certificate, who authenticates with this  certificate successfully against the ASA). startssl.com-server is  another intermediate CA, this CA issues certificates for webservers. My  ASA has it's own certificate (for WebVPN) issued from this CA, holding  the private key for it.

crypto ca trustpoint startssl.com-root
enrollment terminal
crl configure
crypto ca trustpoint  startssl.com-client
revocation-check crl
enrollment terminal
crl configure
crypto ca trustpoint startssl.com-server
enrollment terminal
crl configure

crypto ca certificate chain  startssl.com-root
certificate ca 01
[hex-output omitted]
quit
crypto ca certificate chain startssl.com-client
certificate ca 0d
[hex-output omitted]
quit
crypto ca  certificate chain startssl.com-server
certificate ca 0a
[hex-output omitted]
quit
certificate 017a56
[hex-output  omitted] (this is the certificate of the ASA itself)
quit

For  me it would make more sense to have ONE trustpoint (startssl.com),  which holds the complete chain of root, the two intermediate CAs, and my  own certificate.

Regards,
Florian

You are absolutely right. You do not need to configure 3 different trustpoint. You should use 1 trustpoint for your identity certificate, and same trustpoint for the intermediate certificate. You don't even need to have the CA root if you have the intermediate certificate.

Here should be the steps:

1) Create trustpoint:

crypto ca trustpoint startssl.com
enrollment terminal
crl configure

2) Generate the CSR: crypto ca enroll startssl.com

3) Download the intermediate CA certificate (should be the one that the identity certificate referenced - 1 hieracy up from the identity cert):

crypto ca authenticate startssl.com

4) Download the identity certificate:

crypto ca import startssl.com certificate

5) Then assign the trustpoint to the outside interface if it's for SSL:

ssl trust-point startssl.com outside

Here is the sample configuration for Verisign certificate (from this example, both the Root certificate and the identity certificate references "my.verisign.trustpoint" trust point:

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00808b3cff.shtml

Hope that helps.

It's true, you can have the identity certificate (or many of them) and the certificate of the issuing subordinate in the same trustpoint. If you look above (in my config-snippet), you see that this is the case for the trustpoint "startssl.com-server" - it contains two certificates. One is the certificate of the subordinate CA which issues certificates for servers, the other the identity certificate of the ASA. BUT, to authenticate clients, I seem to need a SECOND trustpoint from the SAME CA-hierarchy - it's called startssl.com-clients in my case. This is the subordinate CA which issues certificates for clients. And yes, this second trustpoint ALONE theoretically would be sufficient to authenticate client-certificates from VPN-users, for example.

What I meant was: As both subordinate CAs belong to the same PKI-hierarchy (both certificates where issued by the same root-CA, which I defined it as trustpoint startssl.com-root), it would make sense for me to have those saved together in one trustpoint. I'm still not sure if that's a valid way of doing it.

Thanks,

Florian

I have exactly the same situation here and I am wondering if you have ever managed to get all CA certificates in hierarchy chained to the same trustpoint (rootCA, intermediateCAs and identity certificates)?

Thanks,

Branislav