cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5618
Views
5
Helpful
16
Replies

Secure TLS SIP Trunk to Avaya Session Manager.

Magnus Holsting
Level 1
Level 1

Hi all.

 

I have an Issue getting a Secure SIP trunk up and running from our Call-Manager to an Avaya Session manager.

 

CUCM: System version: 8.6.2.22025-1

 

In the SIP security profile, I've tried both Authenticated and Encrypted as Device Security Mode.

Certificate from the Avaya has been uploaded to both CUCM's and CUCM's Certifiates has been uploaded to the Avaya Session Manager.

 

I've attached 2 images, 1 of security profile, the other of setup of SIP Trunk destination.

*The trunk works perfectly in non-secure mode.

 

Thank you in advance for any/all answers.

 

Best Regards

Magnus

2 Accepted Solutions

Accepted Solutions

Ayodeji Okanlawon
VIP Alumni
VIP Alumni

Hi Magnus,

Your X.509 Subject name is wrong..

 On CUCM cluster, your X.509 subject name  must be set to the Common Name in the certificate from your Avaya server that was uploaded to cucm.

Please rate all useful posts

View solution in original post

Magnus,

When I originally looked at the packet captures I noticed that there two common names in the client certificate presented by Avaya

common name=SM100

common name=SIP Product Certificate Authority.

I ignored this because I assumed one of this should be enough and since I didn't see any failure...However CUCM is not happy with this..

The trace below shows the TLS connection failure and cucm tells us why. NB this is for a call coming from Avaya (8971 to cucm 8571)

+++++++

09:43:37.793 |ConnectionFailure - Unified CM failed to open a TLS connection for the indicated device Device Name:SIP_2_Nortel_New IP Address:172.20.1.122
09:43:37.793 |SIPSocketProtocol(2,100,17,311)::SendTLSConnectionInfo|*^*^*
09:43:37.793 |SIPSocketProtocol(2,100,17,311)::handleReadComplete send SdlReadRsp: size 632|*^*^*
09:43:37.793 |//SIP/SIPHandler/ccbId=0/scbId=0/getDnsSubjectAltName: We did not find SubjectAltName|2,100,71,1.1^*^*
|2,100,63,1.1801384^172.17.204.30^*
09:43:37.793 |//SIP/SIPTcp/wait_SdlReadRsp: SignalCounter = 1801382|2,100,63,1.1801384^172.17.204.30^*
09:43:37.794 |//SIP/SIPD(2,73,48)/ccbId=0/scbId=0/validTLSConnection: mTsp.DeviceName[SIP_2_Nortel_New], TLS InvalidX509NameInCertificate Error (reason 2), Rcvd=SM100, Expected=SIP Product Certificate Authority|2,100,17,311.3^*^*
09:43:37.794 |//SIP/SIPD(2,73,48)/ccbId=0/scbId=0/restart0_SIPCertificateInd: mTsp.DeviceName[SIP_2_Nortel_New] - X.509 Certficate info mismatch for INCOMING connection. peer addr=172.17.204.30|2,100,17,311.3^*^*

+++++

To resolve this you should add SM100 to the X.509 subject name as follows:

X.509 subject name: SM100, SIP Product Certificate Authority

Make sure you reset the sip trunk after this change

Do this and do another test call from Avaya to CUCM.

Please rate all useful posts

View solution in original post

16 Replies 16

Ayodeji Okanlawon
VIP Alumni
VIP Alumni

Hi Magnus,

Your X.509 Subject name is wrong..

 On CUCM cluster, your X.509 subject name  must be set to the Common Name in the certificate from your Avaya server that was uploaded to cucm.

Please rate all useful posts

Hi Ayodeji

 

Thanx for the reply

 

From avaya cert:
 Issuer Name: CN=SIP Product Certificate Authority, OU=SIP Product Certificate Authority, O=Avaya Inc., C=US

 

As i Understand CN= is Common Name ?

 

If this is the Case, i got the Common Name correct.

 

Indeed you are correct. I wouldn't have imagined that to be the common name. The next thing is for us to look at cucm logs and see whats going on.

Can you get cucm logs and send over?

You could also get packet captures from the cucm server(s) using the ff command from the os platform

utils network capture port 5061 file testSIPTLS count 1000 size all

file get activelog platform/cli/testSIPTLS.cap

Please rate all useful posts

Hi again Ayodeji

 

I can and will do this, but currently SIP Trunk is running on non secure profile and is in production, so will have to wait till tomorrow.

 

Thank you again for taking the time to assist.

Here's the capture file, sorry for the wait.

 

Thank you.

 

/Magnus

Nothing is attached..

Please rate all useful posts

I will try once again, the file extension .cap is not to upload, but didn't see that.

It should be attached now.

Magnus,

After looking at the packet captures, I can confirm that the TLS exchange completed successfully.

These are the key elements of the TLS exchange: highlighted in red:

 

  1. The TCP SYN to establish TCP communication between Avaya (172.17.204.30) and CUCM (172.20.1.121)
  2. The Client Hello that Avaya sends to start the TLS session.
  3. The Server Hello, Server Certificate, and Certificate Request that the CUCM sends to start the certificate exchange process.
  4. The Certificate that the Client Avaya sends to complete the certificate exchange.
  5. The Application Data that is encrypted SIP signalling. Showing us the TLS session has been established

The Application data shows that sip signalling ie SIP INVITE from the Avaya and we see the response back from cucm.

So the certificate part of this is working..

To dig further we need to see the cucm traces and check where the call is failing. Can you send me the cucm traces. Hopefully you still have it in your cucm logs. include calling and called number

Please rate all useful posts

How about this part, a Client Hello from CUCM, but no server response?

Is this of no importance?

I'll fetch the CUCM traces.

Magnus,

Thank you for bringing this to my attention. You are indeed correct that the tls handshake from cucm to Avaya doesn't complete. The Avaya session manager doesn't seem to like something in the client hello from CUCM and hence doesn't bother sending a server hello. You will need to engage the Avaya team to find out why its rejecting the client request from CUCM. So it looks like the handshake is successful in only one direction. So what happens when you attempt to call in from Avaya? That looks like it should work? and it should fail only when you call from CUCM since that's the part that cant get the transport layer up..

 

Please rate all useful posts

Unfortunatly calls in both directions fails..

 

I've contacted the Avaya team and they are looking into my question.

 

Mean while - here are the CUCM Traces..

 

/Magnus

What are the call details? Calling number, called number, time of call?

Please rate all useful posts

Magnus,

When I originally looked at the packet captures I noticed that there two common names in the client certificate presented by Avaya

common name=SM100

common name=SIP Product Certificate Authority.

I ignored this because I assumed one of this should be enough and since I didn't see any failure...However CUCM is not happy with this..

The trace below shows the TLS connection failure and cucm tells us why. NB this is for a call coming from Avaya (8971 to cucm 8571)

+++++++

09:43:37.793 |ConnectionFailure - Unified CM failed to open a TLS connection for the indicated device Device Name:SIP_2_Nortel_New IP Address:172.20.1.122
09:43:37.793 |SIPSocketProtocol(2,100,17,311)::SendTLSConnectionInfo|*^*^*
09:43:37.793 |SIPSocketProtocol(2,100,17,311)::handleReadComplete send SdlReadRsp: size 632|*^*^*
09:43:37.793 |//SIP/SIPHandler/ccbId=0/scbId=0/getDnsSubjectAltName: We did not find SubjectAltName|2,100,71,1.1^*^*
|2,100,63,1.1801384^172.17.204.30^*
09:43:37.793 |//SIP/SIPTcp/wait_SdlReadRsp: SignalCounter = 1801382|2,100,63,1.1801384^172.17.204.30^*
09:43:37.794 |//SIP/SIPD(2,73,48)/ccbId=0/scbId=0/validTLSConnection: mTsp.DeviceName[SIP_2_Nortel_New], TLS InvalidX509NameInCertificate Error (reason 2), Rcvd=SM100, Expected=SIP Product Certificate Authority|2,100,17,311.3^*^*
09:43:37.794 |//SIP/SIPD(2,73,48)/ccbId=0/scbId=0/restart0_SIPCertificateInd: mTsp.DeviceName[SIP_2_Nortel_New] - X.509 Certficate info mismatch for INCOMING connection. peer addr=172.17.204.30|2,100,17,311.3^*^*

+++++

To resolve this you should add SM100 to the X.509 subject name as follows:

X.509 subject name: SM100, SIP Product Certificate Authority

Make sure you reset the sip trunk after this change

Do this and do another test call from Avaya to CUCM.

Please rate all useful posts

I have now added the ekstra Common name, and the Issue is resolved.

 

Thank you very much for your time!!

 

Have a nice weekend :)

 

/Magnus