01-15-2015 12:18 AM - edited 03-17-2019 01:35 AM
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
Solved! Go to Solution.
01-15-2015 04:33 AM
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.
01-16-2015 05:18 AM
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.
01-15-2015 04:33 AM
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.
01-15-2015 04:47 AM
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.
01-15-2015 04:56 AM
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
01-15-2015 05:22 AM
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.
01-16-2015 12:54 AM
Here's the capture file, sorry for the wait.
Thank you.
/Magnus
01-16-2015 01:20 AM
Nothing is attached..
01-16-2015 01:30 AM
01-16-2015 02:48 AM
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:
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
01-16-2015 03:30 AM
How about this part, a Client Hello from CUCM, but no server response?
Is this of no importance?
I'll fetch the CUCM traces.
01-16-2015 04:03 AM
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..
01-16-2015 04:30 AM
01-16-2015 04:32 AM
What are the call details? Calling number, called number, time of call?
01-16-2015 05:18 AM
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.
01-16-2015 05:29 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide