ASA Certs and Trustpoints

1) Trustpoint is a container to hold an identity and intermediate/CA certificate.

Trustpoint makes it easy to reference what identity certificate should be used for
what purpose. For ssl/https server functionality, the "ssl trust-point <Trustpoint-
name>" tells the ASA what identity cert to present to an SSL client.

2) ASA presents the entire chain during an SSL/TLS transaction if it has all the certs
in the hierarchy available. In many cases, the client may only trust the Root CA but
not the sub/intermediate CA that issued the ASA cert. In such a case, it is imperative
that the ASA send the entire chain so that the client can trust the cert based on the
cert hierarchy ("I trust the root, hence any cert issued by subCA is trusted by me") .
IF your CA certs are in a separate trustpoint from the identity, you can delete that
trustpoint and re-import the CA cert again. If you want to delete the intermediate CA
and the identity cert also exists within the same trustpoint, you cannot delete the CA
cert alone. You have to remove the entire trustpoint, which removes the identity cert
also. Best export the identity cert in pkcs12 format before you make any changes to
its trustpoint.

The client looks for 4 things to validate server cert:

1) Issuing from and to validation

2) FQDN matches Subject Alternative Name (SAN) or Subject CN name

3) Cert issued by trusted CA. IF it is a local CA, the public key or cert of CA should
be in the trusted store

4) Cert should have the right KU and EKU if this value if populated by the CA.

The way I am understanding this is that the ID Cert and the CA cert should usually be in the
same TP, this way the ASA can present the entire chain to the client. Otherwise, only the ID
cert will be used, which may or may not be completely trusted by the client. Is that correct?

Not necessarily. You can have a all of them on separate trustpoints and the ASA will
automatically build a chain and send it to the client. You can have:

TP1

ID+Intermediate
TP2

SubCA1

TP3

Root

or you can have

TP1

ID

TP2

Intermediate

TP3

SubCA1

TP4

Root

In both cases above, the ASA sends the entire chain up to the Root CA. A trustpoint
can hold only a max of 1 ID and 1 CA cert, so for large CA's (GoDaddy for example)
you usually cannot have all certs in a single trustpoint. Hence, this intelligence is
automatically built into the ASA.

Multiple certificates on ASA

I have a need to have different certificates for different connection types on an
ASA. One certificate for SSL AnyConnect connections and another certificate for
clientless SSL connections. I was able to install the two certificates on the
ASA. But, I am unable to assign them based on the connection. When create a
connection type and assign the certificate, the certificate on the outside interface
changes.

Does anyone know if I can do this within the ASA?

 No, unfortunately certificate is tied to the ASA interface and you won't be able to have
different certificates for different SSL VPN connections/types.
Jennifer is right and you cannot tie multiple certificates to a single interface but what are you
trying to do? If what you are doing is certificate authentication for your AC Clients then you
dont need to attach the identity certificate to the interface nor to the tunnel-group as we used
to do with the legacy IPsec. In fact the certificate that is tied to the interface is just the SSL
certificate of the ASA and its not used for user authentication.

The ASA can be enrolled with a CA (internal like Microsoft or external like VeriSign)
and that will result in the ASA having one or more CA certificates as well as one
Identity certificate. The Identity cert is what the ASA would use to authenticate itself
to clients connecting in (i.e. clientless, AnyConnect, Cisco VPN client, site-to-site,
etc.). Going with a VeriSign or similar CA is the most desirable option because all the
client browser will automatically trust it. If you go with an in house CA you will need
to install the CA cert on all the clients browsers (or they will warn of untrusted issuer
cert when connecting).
For SSL (clientless or AnyConnect SSL), without enrolling the ASA with a CA what it
will send to clients connecting in is a dynamic auto-generated self-signed cert. This
is the least desirable option as it will likely result in the clients getting hostname
mismatch and/or untrusted browser warnings.
When any client makes a connection into the ASA, the ASA will send a list of trusted
cert DN's down to the client. This allows the client to pick a cert that is issued by one
of the CAs that the ASA trusts. For the configuration you mentioned your ASA would
have two or more CA certs which it would communicated to the clients. You don't
need to link any of the ASA certs to the interfaces for clients to authenticate using
certificates from different CAs. The ASA certificate you link to an interface via ssl
trustpoint interface , is just the one that you want to ASA to use to identify itself to the
clients (the server's certificate).

For example, if let's'say your ASA has 2 trustpoints TP#1 and TP#2.

 TP#1 holds the CA and ASA ID certificate from Verisign.

 TP#2 holds the CA and ASA ID certificate from a private CA

By default all browsers will have Verisign available in the Trusted Root Authorities
Certificates store but not the private CA root .

 User John , an employee, has a personal/ID certificate from Verisign in his browser
and is allowed to use AnyConnect.
 User Ann , a consultant, has a personal/ID certificate from private CA in her browser
and is allowed to use Clientless only.

1) What is the end user behavior if ssl trustpoint TP#1 interface outside is
configured on the ASA?
Both the ID certificates from John and Ann will be validated against the 2 CAs,
andconnect just fine without any popups, since Verisign is a trusted Root Certificate
on both PCs.
2) What is the end user behavior if ssl trustpoint TP#2 interface outside is
configured on the ASA?
User Ann will connect just fine without any popups, since Private CA is in the Trusted
Root Certificate store on Ann's PC.
User John will be presented with a popup warning that Private CA certificate is
untrusted ,since this Private CA is not included by default in Trusted Root Certificate
store on John's PC. John can choose to trust the ASA's Private-CA certificate
permanently and will not receive any more warnings on subsequent connection
attempts. The session operates normally thereafter.

To enter certificate chain configuration mode for the indicated trustpoint, use the crypto ca certificate
chain command in global configuration mode. To return to global configuration mode, use the no form of this
command or use the exit command.

crypto ca certificate chain trustpoint

[no] crypto ca certificate chain trustpoint

OK you can delete a CA cert like so;

crypto ca certificate chain {Trustpointt}

no certificate ca {Certificate ID}

However, if you want to delete an identity cert then just do the same but drop the 'ca'
keyword.

Exporting RSA keys from Cisco ASA: Harder than it should

be
Unlike Cisco IOS routers, which by default don't allow RSA private keys to be exported from NVRAM,
Cisco ASAs don't protect private keys. But there's no command (of which I'm aware) to directly export
the keys either.

Sometimes you need to squirrel away those keys. You can do it by getting a certificate that uses the
keys, then exporting a certificate bundle (with private key included). Here's how.

First, create a key:

 crypto key generate rsa label mykey modulus 2048

Next, create a trustpoint which references the key, and generate a self-signed certificate:

crypto ca trustpoint throwaway

keypair mykey
enrollment self
crypto ca enroll throwaway noconfirm

Now the throwaway trustpoint has a certificate. Export that certificate to the terminal.

no terminal pager
crypto ca export throwaway pkcs12 <passphrase>

Save the blob of text including the begin/end lines. The blob is a PKCS12 bundle encrypted using the
passphrase above and then base64 encoded. Be sure to save the encryption passphrase.

-----BEGIN PKCS12-----
MIIJZwIBAzCCCSEGCSqGSIb3DQEHAaCCCRIEggkOMIIJCjCCCQYGCSqGSIb3DQEH
BqCCCPcwggjzAgEAMIII7AYJKoZIhvcNAQcBMBsGCiqGSIb3DQEMAQMwDQQI4KTD
...etc...
ru1WrVnO7wFa+83BK8D+aQ7UedzQuU6NOiDrjPR0w8uWSLwKmmSVgnZN4BEwPTAh
MAkGBSsOAwIaBQAEFGA2bfp4y+a/R29RZ9TA8sCUSZ+jBBRvppgVbM8rBbW62096
L/HnJErexgICBAA=
-----END PKCS12-----

We no longer need the certificate or the throwaway trustpoint in which it's stored. Kill it. The private
key will survive.

no crypto ca trustpoint throwaway noconfirm

The easiest way to get the key onto an ASA is to import the PKCS12 blob using the passphrase.
Importing the certificate will create 3 things on the ASA:

 The RSA keypair

 The certificate
 A trustpoint to hold the certificate
The keypair will be named the same as the trustpoint. To make the keypair named 'my-imported-key',
import it like this, pasting in the text blob when prompted, then typing 'quit'.
crypto ca import my-imported-key pkcs12 <passphrase>

Now the key is available for use, but there's a useless certificate and trustpoint as well. Kill those off
just like before. The key will survive.

no crypto ca trustpoint my-imported-key noconfirm

Another option is to extract the key from the PKCS12 bundle using openssl on some other device.
First, save the text blob without the BEGIN/END lines to a file. I'd probably call
it throwaway.p12.base64. Then, it needs to be base64-decoded, and parsed from a pkcs12
certificate bundle into a pem-formated private key. The private key output contains both the private
and public keys.

base64 -D throwaway.p12.base64 | openssl pkcs12 -nocerts -nodes -password

pass:<passphrase>
MAC verified OK
Bag Attributes
localKeyID: 00 00 00 01
friendlyName: cn=lab-asa-1,hostname=lab-asa-1.fragmentationneeded.net
Key Attributes: <No Attributes>
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDUp4/EVH/uaScJ
3LuC71Zps8Q/n6JNFP5cehhDm8MYFq1Ms/VGHcHaO0Mt4F0BFQ6nyFjeuiaubeSp
...etc...
3r4cQPYplDbSdNVBYy9BpzsQVoxIn9dcz10fRl1V2xabTvXZ+kDc4KOucVRH+WGV
YsYGwIXyJgsTvhKSDojxMyHQF201x8QO4+oSLndAY+Zj3wRz9S1N1btc929cyfjG
NMJuImRF/uSH2IfFpEl8bAY=
-----END PRIVATE KEY-----

The example above was run on MacOS, where the base64 binary has BSD heritage. On Linux, use -
d rather than -D with the GNU flavor of base64.

Deletion of expired certificate from ASA

Check all SSL certificates installed on ASA firewall:

# show crypto ca certificates

Find the certificates expired and associated Trustpoints.

Check if the trustpoint is referenced in the configuration:

show crypto ssl

show run | i {TRUSPOINT_NAME}

show crypto ca certificate {TRUSPOINT_NAME}

If Yes, check new updated certificate has been configured.

Once expired certificate is identified, take the backup of the certificate and its associated key using
below commands:

no terminal pager
crypto ca export <trustpoint_name> pkcs12 <passphrase>

Save the blob of text including the begin/end lines. The blob is a PKCS12 bundle encrypted using the
passphrase above and then base64 encoded. Be sure to save the encryption passphrase.

-----BEGIN PKCS12-----
MIIJZwIBAzCCCSEGCSqGSIb3DQEHAaCCCRIEggkOMIIJCjCCCQYGCSqGSIb3DQEH
BqCCCPcwggjzAgEAMIII7AYJKoZIhvcNAQcBMBsGCiqGSIb3DQEMAQMwDQQI4KTD
...etc...
ru1WrVnO7wFa+83BK8D+aQ7UedzQuU6NOiDrjPR0w8uWSLwKmmSVgnZN4BEwPTAh
MAkGBSsOAwIaBQAEFGA2bfp4y+a/R29RZ9TA8sCUSZ+jBBRvppgVbM8rBbW62096
L/HnJErexgICBAA=
-----END PKCS12-----

Now expired certificate can be deleted in two ways:

a) delete the truspoint (deletes everything)

#no crypto ca trustpoint {TRUSPOINT_NAME}

b) delete the certificates one by one by entering into the trustpoint configuration:

(config)#crypto ca certificate chain {TRUSPOINT_NAME}

no certificate {certificate_SERIAL_number}