Migration of CUBE to New CA

[AdamB32212]

Hello,

Background: We have a CUBE interfacing with a third-party CUBE. We use TLS on the interface (1 interface, 1 IP, 1 trustpoint). Initially we'll use the same CA on either end (in which case the configuration is trivial). But what if one of the ends decides to move to another CA? One way is to update the configuration at both ends at the same time. But that may be difficult to coordinate. 

Question: Is there a way to load the 2nd (i.e. new) CA on the CUBE such that the connection will work with EITHER CA on the other end? This way, we could preload the new CA on both ends, then each end could upgrade/transition independently to the new CA, and then the old CA could be removed from the configuration.

Based on what I've read, this does NOT appear to be supported. I understand that an interface with one IP address can be associated only with one trustpoint, and each trustpoint can be associated only with one certificate (e.g. .pk12 file). Am I correct?

[Roger Kallberg]

You can have as many CA certificates loaded into the gateway as you’d like from what I know. To form the trust between the entities in the TLS pair you’ll upload the CA certificate(s) into the trust store that the remote end uses and as well for the one you use at your end.

[Jonathan Schulenberg · Accepted solution]

Definitely possible, but this is really two discrete questions/processes.

If the far end is getting a new CA chain you can create new trustpoint(s) at any time in advance of the switch. IOS XE will search all trustpoints for a match. The root CA gets it’s own trustpoint while any subordinate CA(s) get placed into a second and linked to the root.

If the cert of your CUBE is changing to a new CA chain you can build all of that config in advance and just update the trustpoint being used under sip-ua or voice class tenant. I usually shut / no shut the dial-peers to force a new TLS handshake.

[AdamB32212]

The first option (i.e. relying on the automatic search) is something I was not aware of and it is what I was looking for. It is better for us because it doesn't necessitate coordination between two administrative entities on the two ends of the interface.

BTW, this topic does not seem to be well described (if at all!) in the main Cisco documentation that talks about trustpoints and TLS. As a feedback to Cisco, I would recommend it as a worthwhile update because it is a common problem.

At any rate, I think I know enough to go and try it in the lab.

Thank you for assistance with this!