cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2121
Views
5
Helpful
6
Replies

CUBE SIP-TLS w/ Intelepeer

Daniel Lucas
Level 1
Level 1

From what I have read CUBE always performs mutual authentication with SIP-TLS. From what I can see however, there is only a single trustpoint referenced in the 'crypto signaling' command under sip-ua. This implies that both sides must have a certificate signed by the same CA. Is it possible to have both sides have certificates signed by two different 3rd-party CAs?

The case I am dealing with is our CUBE's certificate would be signed by our certificate provider (GoDaddy for example), and the carrier's (Intelepeer) would be signed by whoever they use.

 

Also, we are only doing SIP-TLS/SRTP from the CUBE to carrier, and not between the CUBE and UCM.

 

UCM--LAN(SIP/RTP)-->CUBE--INTERNET(SIP-TLS/SRTP)-->ITSP

-Thanks

 

1 Accepted Solution

Accepted Solutions

Daniel Lucas
Level 1
Level 1
Figured this one out - under 'sip-ua' the trustpoint referenced by the crypto signaling command needs to refer to the trustpoint/CA of the CUBE's certificate; which is what is sent to the ITSP.
Having the ITSPs CA certificate stored as an authenticated trustpoint will allow the CUBE to validate the certificate received.

View solution in original post

6 Replies 6

R0g22
Cisco Employee
Cisco Employee
That's a good question but I will need to see if their is something documented in that regard. I would say that CUBE pair has trust points for the same external CA. The reason could be that crypto check-pointing will not happen since the RFC's restrict against sharing crypto keys.

Ok thanks,
Also worth mentioning, we are deploying a standalone CUBE; not an HA pair.

-Thanks

Ok. Thanks for highlighting. I thought this is in continuation to your CUBE HA post.

For your query, why not have your CUBE certs self-signed and have your ITSP make the changes at their end ? Also, use the certificates on the CUBE from the same CA that your ITSP does ? ITSP usually shares the certificates both Root and intermediary CA's as well.

Thanks for the reply,

I would prefer to not use self-signed certificates if possible for security reasons. I would still have the same situation however; the ITSP would need to import my cert, and I would need to import their cert; and somehow the router know which is used for what.

I found a Cisco document that I am trying to follow, and I may be just misunderstanding the configuration example:

Intelepeer SIP Trunking: Connecting Cisco Unified Communications Manager 9.1 via the Cisco Unified Border Element 10.0 using SIP TLS

 

I understand that the CSR is generated on the router, and the intelepeer certificates are imported. I also see where the router is configured to authenticate signaling received from Intelepeer with the IntelepeerCA trustpoint via the"crypto signaling remote-addr 68.68.123.103 255.255.255.255 trustpoint intelpeerCA" command. However, I am failing to see where the router is instructed to use it's own certificate (the tekvlabsCA trustpoint in the example) in order to authenticate to Intelepeer.

You don't instruct it to use it. During TLS handshake, the CUBE will share it's certificate. It will do that when behaving as a client and also when behaving as a server. Post which there is a Certificate Verify and a "Change Cipher Spec" from both ends. TLS is completed after this.

Daniel Lucas
Level 1
Level 1
Figured this one out - under 'sip-ua' the trustpoint referenced by the crypto signaling command needs to refer to the trustpoint/CA of the CUBE's certificate; which is what is sent to the ITSP.
Having the ITSPs CA certificate stored as an authenticated trustpoint will allow the CUBE to validate the certificate received.