Unable to associate multiple trustpoints in a tls-profil

[AdamB32212]

Starting with IOS 17.3 it is possible to create tls-profile, associate multiple trustpoints with it, and then in sip-ua add "crypto signaling remote-addr <IP of far end> 255.255.255.255 trustpoint tp_name"

Now, a few days ago I remember that I created a tls-profile and added 2 trustpoints to it. Since then, however, I've been trying to redo it and each time I create a tls-profile and add 2+ trustpoints, and then end and wr, the resulting tls-profile has only 1 trustpoint.

Is this some known bug? or is there anything else that has to be done to associate multiple trustpoint with a single tls-profile?

Ref. Cisco Unified Border Element Configuration Guide Through Cisco IOS XE 17.5 - SIP TLS Support on CUBE [Cisco Unified Border Element] - Cisco 

[Roger Kallberg]

Maybe a stupid and obvious question, if you already have configured this can you not simply look at where you did it before?

[AdamB32212]

I am not able to add multiple trustpoints to a single tls-profile. If I enter a 2nd one, the first one gets removed. I don't believe it's possible/

[pieterh]

>>> Starting with IOS 17.3 it is possible to create tls-profile, associate multiple trustpoints with it, and then in sip-ua add "crypto signaling remote-addr <IP of far end> 255.255.255.255 trustpoint tp_name"<<<

in this sentence above there is only a single trustpoint assigned to the sip-ua. And multiple trustpoints to tls-profile.

maybe what you need is adding multiple certificates/keys to the same trustpoint ?

[AdamB32212]

I am not able to import multiple .p12 files to a single trustpoint. If I try to import the second one, I get the following error message:

% Trustpoint 'tp_name' is in use

% Please delete it or use a different label.

[Nithin Eluvathingal]

Map remote TLS connections to specific trustpoints

When using crypto signaling default sip-ua command ALL inbound TLS connections are mapped to these configuration either via tls-profile or individual post-fix commands. Furthermore, all available trustpoints are checked when performing certificate validation.

It may be desirable to create specific TLS profile configurations for specific peer device based on IP address to ensure exactly the security parameters you define are applied to that TLS session. To do this use the crypto signaling remote-addr command to define an IPv4 or IPv6 subnet to map to a tls-profile or set of postfix commands. You may also directly map verification trustpoint via client-vtp) commands to lock down exactly which trustpoints are used to validate peer certificates.

The command below summarizes most items discussed up to this point:

!
voice class tls-cipher 1
 cipher 1 ECDHE_RSA_AES128_GCM_SHA256
 cipher 2 ECDHE_RSA_AES256_GCM_SHA384
!
voice class tls-profile 1
 trustpoint CUBE-ENT
 cn-san validate bidirectional
 cn-san 1 *.example.com
 cipher 2
 client-vtp PEER-TRUSTPOINT
 sni send
!
sip-ua
 crypto signaling remote-addr 192.168.1.0 /24 tls-profile 1
!

For older versions this can be done like so:

!
sip-ua
 crypto signaling remote-addr 192.168.1.0 /24 trustpoint CUBE-ENT cn-san-validate server client-vtp PEER-TRUSTPOINT strict-cipher
!

Starting in 17.8 you may also configure tls-profile and per-tenant listen ports per voice class tenant to provide furhter segmentation options on a given listen port.

!
voice class tenant 1
 tls-profile 1
 listen-port secure 5062
!

 

Enforce Strict SRTP

When enabling SRTP on CUBE Enterprise the default operation is to disallow fallback to RTP.

Where possible use SRTP on all call-legs however by default CUBE will perform RTP-SRTP as needed.

Note that CUBE does not log the SRTP keys in debugs starting in 16.11+

!
voice service voip
 srtp
!
! or
!
dial-peer voice 1 voip
 srtp
!

https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-border-element/220380-cisco-guide-to-harden-cisco-unified-bord.html

[AdamB32212]

But all I need is to map multiple trustpoints to a single Dial-peer. I can't believe this is not supported. What if there is a migration of certificates to a new CA, how are the two endpoints supposed to support it? There has to be a period of time when at least one endpoint supports BOTH CAs. How can this be configured?  (I am not able to find any information on this topic.)

[AdamB32212]

One clarification: my question is in the context of a SIP Trunk/TLS only, not for IPsec.

[Roger Kallberg]

In your question which side is it that is changing the CA certificate(s). Is it the remote end or your end? If it’s the first you’d would need to add the root and any intermediate certificate to the router. These are not defined by any configuration in sip-us or on the dial peers, it’s enough to have the certificate(s) present in the router to form the chain of trust. If it’s your end I would think that you’d be able to manage this by creating multiple dial peers that uses different TLS profiles and/or tenants. However I’ve never done that sort of configuration, so it’s purely guesswork. Likely your better off to run this by TAC to know for sure.

[AdamB32212]

It could be either end. It is not known ahead of time which side will transition first. 

I tried and created 2 trustpoints, 2 tls-profiles, 2 tenant definitions, 2 dial-peers (each associated with different tenant, of which each was associated with different tls-profiles, etc.). That did not work. Both DPs were always busyout.

I will submit an SR ticket.  (I find it surprising that it's not well documented because this is a common scenario.)

Thank you!

[Roger Kallberg]

If it was your end that changes certificate you’ll know ahead of time. Anything else would be unlikely. If you were to share your running configuration we might be able to help you out easier.

[AdamB32212]

So how is it handled out in the industry? Say, two companies have their respective SBCs/CUBEs and running TLS in between. Then one of them gets a new certificate and it happens to be a different CA (i.e. not common to both ends) -- how do they ensure that the TLS connection stays up?

[Roger Kallberg]

We’re actually in that situation right now where our service provider is changing the CA certificates on their end. For that all we’d need to do is upload the root and intermediate certificates in our routers. Apart from that we do not need to do any additional configuration changes.

[AdamB32212]

Then the only way to handle the migration of CAs is a manual update? 

I knew that we could do it manually but that requires coordination between the endpoints a (tiny) outage (ideally, both ends will do it at the same time resulting in a very short disruption). 

That seems to confirm my growing suspicion that there is no supported way to allow more than 1 trustpoint (CA) per TLS connection at any given time (e.g. 2 concurrently). If that's the case, then I'll accept it as the answer.

[Roger Kallberg · Accepted solution]

In our case there would be no outage as the new certificates would be uploaded in parallel with the currently used. Then when the service provider makes the change on their end we’ll start using the new CA certificates without any additional effort on our end and without any synchronisation of when exactly this is done by the service provider.