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.
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.
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:
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.
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)?
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...