Authentication of Intermediate and Root CAs

[AdamB32212]

We are using Cisco CUBEs and we have a question about how certificates are authenticated.

Given two CUBEs loaded with certificate files where the Root CA is the same but intermediate CAs are different, will those CUBEs be able to establish TLS? Or will we need a new Trustpoint with each other's intermediate CA?

Also, is there a command to see which specific certificates are offered during a TLS handshake?

[Roger Kallberg]

AFAIK you would need to have the intermediate certificate present in the trust store to be able to form the TLS trust. On your other question, I don’t know if there are any command present for seeing what certificate(s) are used in the handshake. Likely there are debug(s) where this can be seen, but I don’t know which specifically they are as I’ve never needed to look into this.

[M02@rt37]

Hello @AdamB32212,

...is there a command to see which specific certificates are offered during a TLS handshake?

Try #debug ssl ? 

Check the option given in the output.

[AdamB32212]

I'll give it a try. Thank you!

[Jonathan Schulenberg · Accepted solution]

Welcome to Certificate Chain Validation. My understanding after re-reading the documentation is that the default behavior looks for the first/lowest CA in the chain provided by the peer that is trusted by the router and then stops. That could be the root if that's the only thing you created a trustpoint for, skipping over the intermediate CA(s). If you want IOS to validate the full chain of intermediate(s) and the root you need to include chain-validation continue <root CA trustpoint> in the intermediate CA trustpoint(s). FWIW- This command is part of my personal best practices, but I like to nerd out on PKI stuff.

While on the topic of certificate validation, my understanding is that IOS only processes CRLs by default for the revocation status check. Most public CAs use OCSP these days with CRLs serving as a legacy backup mechanism. You need to use revocation-check ocsp crl on the trustpoint if you want the router to use OCSP and fallback to CRLs. Check the certificate first to ensure it has the AIA (OCSP) and CDP (CRL) attributes though.

As for viewing the specific certs offered: I tend to use the embedded packet capture filtered to the IP of the far end - and SIP TLS port if there are active calls to avoid RTP traffic. It's really easy to see the cert chain sent/received in the TLS Server Hello packet in Wireshark.

[AdamB32212 · Accepted solution]

Thank you for the "Certificate Chain Validation" link! While I searched for the answer, I did not find it somehow. So essentially Root CA is enough, unless configured otherwise, which is perfect. 

The packet capture - yes, I was aware of it, just thought there might be some additional way to make the router spit out the information specific to the certificates. But this is good enough, we'll just use wireshark to analyze the .pcap.

I will leave the post open until Noon just in case anyone has a working experience with this and then I will close the topic as resolved.

Thank you!