04-23-2010 05:16 AM
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
04-23-2010 05:16 AM
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
04-23-2010 05:44 AM
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.
04-23-2010 06:17 AM
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
05-16-2013 03:03 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide