ASA Self-signed certificates, primary and secondary

[Leroy Plock]

Hello.

Doing some ASA upgrades, and dealing with the Java certificate requirements.

We upgraded on primary/secondary pair no problem and got the self-signed certificate installed into Java. We can access the primary with no issues or warnings.

However when we access the secondary, java complains that the IP address we're going to doesn't match the CN in the certificate.

Looking at the ASA, there are separate self-signed certificates for the IP of the secondary as well as the primary, but obviously the secondary is presenting a certificate with the primary's IP in the CN. And I see no way to influence which cert the ASA presents to the client.

I would think the easy way to deal with this would be to remove the existing self-signed certificates, generate a new one which includes two CNs, one for each IP. Now the certificate should be valid no matter which IP we're going to.

This seems straightforward, but I couldn't find any documentation saying this was a standard practice, so wondered if I was missing something.

Does anyone see a problem with this approach, and if so can you suggest a better way?

Thank you.

[Karsten Iwen · Accepted solution]

You can use it the way with both IPs in the certificate. Even better, include the internal FQDNs so that you can access them by name and not only by IP.

For maximum campatibility, include the IPs as IP-based SANs *and* as DNS-based SANs.

[Leroy Plock]

Karsten,

Great, thanks for the swift and clear reply.

Followup question: We have a number of ASA primary/secondary pairs. Being lazy, I don't want to generate a separate certificate for each pair and import them all into Java. I'm thinking I can generate ONE certificate that includes the IPs for ALL the ASAs, import that certificate onto all the other ASAs and into Java, and I'm done. I don't see that this in any way presents a security issue, do you?

Thank you.

[Karsten Iwen]

Working that way is not that uncommon, but still has security-implications that should be known.

If one of the ASAs (or the private key) get compromized, then you can't revoke the certificate of a single system. It has to be done for all ASAs at the same and in a short time-frame.

If you decide that it's an acceptable risk, then go for it.

[Leroy Plock]

True, and to export/import the cert between ASAs you have to export the private key which isn't the best practice. But this is just about protecting the ASDM client to be sure it is connecting to a trusted ASA for administration. It has no effect on anyone accessing the network and doesn't protect the ASA from rogue administrators.

As you say, it's a matter of acceptable risk.

Thank you.