TLS handshake fails in 4.6

[John Lightfoot]

I thought I'd put some effort into getting 4.6 to work with
Exchange Online UM which requires TLS transport with a
non-self-signed SSL certificate. Right out of the gate, the
TLS handshake fails when Exchange requests Sipx's client
certificate and Sipx returns a handshake message with the
cert empty. There's nothing logged that indicates Sipx
doesn't like the request, signing authority (MS's
intermediate authority certs are loaded in Sipx) or the
like. The sipxbridge.log only indicates that the far end
rudely tears the session down but nothing else. I had it
configured with 4.4 with the same cert and same Exchange
config and the cert exchange happened as expected. I'm a
little unclear how to turn the TLS logging to debug or what
else to try. Any thoughts on how to tackle this?

[Douglas Hubler]

Post by John Lightfoot
I thought I'd put some effort into getting 4.6 to work with
Exchange Online UM which requires TLS transport with a
non-self-signed SSL certificate. Right out of the gate, the
TLS handshake fails when Exchange requests Sipx's client
certificate and Sipx returns a handshake message with the
cert empty. There's nothing logged that indicates Sipx
doesn't like the request, signing authority (MS's
intermediate authority certs are loaded in Sipx) or the
like. The sipxbridge.log only indicates that the far end
rudely tears the session down but nothing else. I had it
configured with 4.4 with the same cert and same Exchange
config and the cert exchange happened as expected. I'm a
little unclear how to turn the TLS logging to debug or what

John, no takers as far as developers responding, but I'm very thrilled
you're testing. sipXbridge's TLS implementation hasn't changed
AFAIK, but cert. management certainly has. Can you verify proper cert
is delivered?

[George Niculae]

Post by Douglas Hubler

Post by John Lightfoot
I thought I'd put some effort into getting 4.6 to work with
Exchange Online UM which requires TLS transport with a
non-self-signed SSL certificate. Right out of the gate, the
TLS handshake fails when Exchange requests Sipx's client
certificate and Sipx returns a handshake message with the
cert empty. There's nothing logged that indicates Sipx
doesn't like the request, signing authority (MS's
intermediate authority certs are loaded in Sipx) or the
like. The sipxbridge.log only indicates that the far end
rudely tears the session down but nothing else. I had it
configured with 4.4 with the same cert and same Exchange
config and the cert exchange happened as expected. I'm a
little unclear how to turn the TLS logging to debug or what

John, no takers as far as developers responding, but I'm very thrilled
you're testing. sipXbridge's TLS implementation hasn't changed
AFAIK, but cert. management certainly has. Can you verify proper cert
is delivered?

Also please provide a sipxbridge logs on debug (snapshot would be
better as we could see the configuration). Habe you set Transport
Protocol on TLS or Auto? (it could be setting not replicating issue)

George

[John Lightfoot]

In response to Doug's question, I've tested with openssl
from the command line using the same certs and the TLS
negotiates fine. I also had it configured pretty much
identically in 4.4 and the Sipx cert was sent. Oh and I
tried with the self-signed cert as well and got the same
results.

As for transport, I have the gateway configured with TLS as
the transport. Since TLS tries to negotiate, it would
appear I at least have that part correct. I'm not sure how
to set logging on Sipxbridge to debug. If I can get some
guidance on that, I'll upload ASAP.
John

[George Niculae]

Post by John Lightfoot
In response to Doug's question, I've tested with openssl
from the command line using the same certs and the TLS
negotiates fine. I also had it configured pretty much
identically in 4.4 and the Sipx cert was sent. Oh and I
tried with the self-signed cert as well and got the same
results.
As for transport, I have the gateway configured with TLS as
the transport. Since TLS tries to negotiate, it would
appear I at least have that part correct. I'm not sure how
to set logging on Sipxbridge to debug. If I can get some
guidance on that, I'll upload ASAP.
John

Sure, go to Devices > SIP Trunk SBCs, click on name (should be
sipXbridge-1) then Logging leve section. I think I know why problem
lies and this is related to setting replication, could you look into
/etc/sipxpbx/sipxbridge.xml file and check if <itsp-transport> for
that account reflects TLS selection?

George

[Tony Graziano]

oops. I sent that for 4.4, for 4.6 refer to what george sent

Post by George Niculae

Post by John Lightfoot
In response to Doug's question, I've tested with openssl
from the command line using the same certs and the TLS
negotiates fine. I also had it configured pretty much
identically in 4.4 and the Sipx cert was sent. Oh and I
tried with the self-signed cert as well and got the same
results.
As for transport, I have the gateway configured with TLS as
the transport. Since TLS tries to negotiate, it would
appear I at least have that part correct. I'm not sure how
to set logging on Sipxbridge to debug. If I can get some
guidance on that, I'll upload ASAP.
John

Sure, go to Devices > SIP Trunk SBCs, click on name (should be
sipXbridge-1) then Logging leve section. I think I know why problem
lies and this is related to setting replication, could you look into
/etc/sipxpbx/sipxbridge.xml file and check if <itsp-transport> for
that account reflects TLS selection?
George
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

[John Lightfoot]

Here's the bridge log at debug...

And, yes, TLS is the transport for the Exchange account in
the sipxbridge.xml.

[John Lightfoot]

a little more info...

I had been testing by calling the pilot number on the
voicemail dialplan (x101). I hadn't gotten as far as
turning voicemail from internal to external for a user.
When I did enable a user for Exchange, all calls rolled to
internal voicemail no matter the settings. Perhaps there's
something more fundamentally broken than just the TLS.

[George Niculae]

Post by John Lightfoot
a little more info...
I had been testing by calling the pilot number on the
voicemail dialplan (x101). I hadn't gotten as far as
turning voicemail from internal to external for a user.
When I did enable a user for Exchange, all calls rolled to
internal voicemail no matter the settings. Perhaps there's
something more fundamentally broken than just the TLS.

Well I think it's only related to certs in 4.6 (as you mentioned it
works in 4.4) - I see the exception while trying to send invite to
ITSP

Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed
connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:869)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1190)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1217)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1201)
at gov.nist.javax.sip.stack.IOHandler.sendBytes(IOHandler.java:307)
at gov.nist.javax.sip.stack.TLSMessageChannel.sendMessage(TLSMessageChannel.java:311)
at gov.nist.javax.sip.stack.MessageChannel.sendMessage(MessageChannel.java:255)
at gov.nist.javax.sip.stack.SIPTransaction.sendMessage(SIPTransaction.java:745)
at gov.nist.javax.sip.stack.SIPClientTransaction.sendMessage(SIPClientTransaction.java:476)
at gov.nist.javax.sip.stack.SIPClientTransaction.sendRequest(SIPClientTransaction.java:968)
... 11 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(InputRecord.java:352)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:850)
... 20 more

Can you describe exactly the config steps you took?

Thanks
George

[John Lightfoot]

Sure. For the certs, I installed a StartSSL-issued
certificate for my Sipx and two intermediate CAs from
Microsoft. I edited the "Voicemail" dial plan with
"Exchange Voicemail Server" in the type field and the FQDN
of the Exchange Online gateway in the address. I added a SIP
Trunk gateway with the same Exchange Online address as the
dialplan entry and set the transport to TLS and port to
5061. Last, I changed the voicemail server for the user to
"Microsoft Exchange UM Voicemail Server." I referred
earlier to the fact that this last step didn't change the
way calls roll to voicemail. Oddly, though, if I dial 8+ext
the call does try to go to Exchange rather than to the
internal vm.

[Tony Graziano]

Because there is no active dial plan entry for 8+ pointing to the exchange
system?
--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!

Post by John Lightfoot
Sure. For the certs, I installed a StartSSL-issued
certificate for my Sipx and two intermediate CAs from
Microsoft. I edited the "Voicemail" dial plan with
"Exchange Voicemail Server" in the type field and the FQDN
of the Exchange Online gateway in the address. I added a SIP
Trunk gateway with the same Exchange Online address as the
dialplan entry and set the transport to TLS and port to
5061. Last, I changed the voicemail server for the user to
"Microsoft Exchange UM Voicemail Server." I referred
earlier to the fact that this last step didn't change the
way calls roll to voicemail. Oddly, though, if I dial 8+ext
the call does try to go to Exchange rather than to the
internal vm.
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[John Lightfoot]

No, the 8 is the default direct-to-voicemail prefix defined
no the vm dp. So it's odd when I get the internal voicemail
greeting when I timeout on a call to extension 200 but get
the TLS attempt when I dial 8200.

[Douglas Hubler]

Can you turn on "SIP Capture" feature and compare the ladder diagrams
of each call in homer?

Diagnostics/SIP Capture/SIP Capture Web Interface

Post by John Lightfoot
No, the 8 is the default direct-to-voicemail prefix defined
no the vm dp. So it's odd when I get the internal voicemail
greeting when I timeout on a call to extension 200 but get
the TLS attempt when I dial 8200.
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[John Lightfoot]

I enabled SIP capturing and left all the config at defaults
but I'm not seeing anything captured in the Homer interface.
Is there something else I need to do to turn it on?

To your question, though, when I do a tcpdump filtered on
port 5061 and call either 8-200 (dir to ext 200 vm) or 101
(vm access #) I get traffic like you see in
Sipx-O365_TlsHandshake_failed.pcap. Packet 13 is client
certificate request and 15 is the empty response. I don't
get anything when I call 200 and let it roll. For
comparison, I get ssl_handshake_test.pcap when I run this
from Sipx shell: "openssl s_client -connect [unique
ID].um.outlook.com:5061 -cert /etc/sipxpbx/ssl/ssl.crt -key
/etc/sipxpbx/ssl/ssl.key -CApath
/etc/sipxpbx/ssl/authorities/". You can test yourself by
using wildcard-latam.um.outlook.com:5061 as the destination
host.

(I apparently can't upload those two caps but it's easy
enough to replicate using wildcard-latam.um.outlook.com as
the gateway address)

[John Lightfoot]

Oh, it was just restricting me to one file. Here's the
other openssl pcap...

[Tony Graziano]

system>logging levels>advanced>trunking (which is sipxbridge)

set to debug and restart services as prompted

Post by John Lightfoot
In response to Doug's question, I've tested with openssl
from the command line using the same certs and the TLS
negotiates fine. I also had it configured pretty much
identically in 4.4 and the Sipx cert was sent. Oh and I
tried with the self-signed cert as well and got the same
results.
As for transport, I have the gateway configured with TLS as
the transport. Since TLS tries to negotiate, it would
appear I at least have that part correct. I'm not sure how
to set logging on Sipxbridge to debug. If I can get some
guidance on that, I'll upload ASAP.
John
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>