< Previous by Date	Date Index	Next by Date >
< Previous in Thread	Thread Index	Next in Thread >

Re: [reSIProcate-users] TLS Handshake failure on debian 8

From: Florent SCHILDKNECHT <florent.schildknecht@xxxxxxxxx>
Date: Mon, 30 Jan 2017 18:14:39 +0100

Hey Scott,

Thanks for your reply,

I’ll try to answer as best as I can.

Not sure if it matters, but I am wish to use this TURN server as a relay for a WebRTC application.

I already have working JS clients and a signaling server.

To test my turn server, I use this tool :

https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

I first set the 3478, unencrypted address, then I try using the port 5349, which is my TlsTurnPort.

First test (port 3478, seems to work) :

URL : turn:turn.my-domain.com:3478

username : test

credential : « my-hashed-password »

Time Component Type Foundation Protocol Address Port Priority

0.002 1 host 1026183099 udp My_Local_IP 51014 126 | 32542 | 255

0.002 2 host 1026183099 udp My_Local_IP 59034 126 | 32542 | 254

0.044 1 srflx 3160557839 udp My_Public_IP 34652 100 | 32542 | 255

0.049 2 srflx 3160557839 udp My_Public_IP 34653 100 | 32542 | 254

0.102 1 host 1940501323 tcp My_Local_IP 9 90 | 32542 | 255

0.102 2 host 1940501323 tcp My_Local_IP 9 90 | 32542 | 254

0.165 1 relay 4193894297 udp My_Server_IP 49156 2 | 32542 | 255

0.168 2 relay 4193894297 udp My_Server_IP 49157 2 | 32542 | 254

0.169 Done

Second test (port 5349) :

URL : turn:turn.my-domain.com:5349

username : test

credential : « my-hashed-password »

Time Component Type Foundation Protocol Address Port Priority

0.002 1 host 1026183099 udp My_Local_IP 58981 126 | 32542 | 255

0.002 2 host 1026183099 udp My_Local_IP 58354 126 | 32542 | 254

0.103 1 host 1940501323 tcp My_Local_IP 9 90 | 32542 | 255

0.103 2 host 1940501323 tcp My_Local_IP 9 90 | 32542 | 254

9.560 Not reachable?

1. I’ve set the logger level to DEBUG in the reTurnServer.config file.

Now, I have those logs :

## Server start

## When I try to connect my webrtc

The openssl version I am using is :

OpenSSL 1.0.1t 3 May 2016

2. Not exactly sure of what you mean by « installed » ;

I am using letsencrypt, so unless I really get something wrong,

The root CA is the one of LetsEncrypt, which usually does not need any installation ?

Here is a screen of the certificate when I access the domain on port 443 (Using nginx, no web-application of any kind on this domain though)

(Which means the certificate is valid... Right?)

3. I really think so, even though I am using the webrtc.github.io tool,

The URL that is set is indeed turn.my-domain.com, which is the Common Name of my certificate.

4. I have never used wireshark, so it’s not easy to understand how it works, but I gave it a try.

Not actually sure what kind of information I am looking for?

Here is a screen of some frames that I could consider related, given the fact that it is the good server IP address…

Thanks again in advance,

Best regards,

Florent Schildknecht

UX-designer et développeur web auto-entrepreneur

http://floschild.me/

+33 6 78 41 74 79 (France)

+46 7 64 15 32 64 (Sweden)

On 30 Jan 2017, at 14:49, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:

Hi Florent,

Things to look for:
1. Was there any errors in the logs when reTurn started surrounding the loading of certificates? Conversely, do you see success messages reading your certificate file?
2. Does the client have the root certificate installed?
3. Is the client connecting using the domain that matches the Common Name in the certificate?
4. Take a wireshark capture of the TLS handshake to try to get more information on why the connection is closing. Is is the client or server disconnecting? Do the certificates presented from the server to the client look valid?

Some other general notes from the wiki (http://www.resiprocate.org/Certificates):
"Certificates in the this file should be specified from top down. Ie. Highest level certificate first and root certificate last."

I'll let someone more linux savey answer your other questions about file permissions, etc. :)

Scott

On Mon, Jan 30, 2017 at 5:22 AM, Florent SCHILDKNECHT <florent.schildknecht@xxxxxxxxx> wrote:
Hey,

I am trying to set-up reTurn server for a project requiring SSL/TLS encryption,
On a debian 8 server (installed with the official packets, apt-get install resiprocate-turn-server)
The server seems to work fine on unencrypted port, but I have troubles with TLS.

I am using letsencrypt to generate certificates, not with the certbot utility but another client.

I have the following valid certificates for my subdomain (turn.my-domain.com) ;
(Regenerated automatically every 3 months)

cert.pem (certificate part only)
chain.pem (chain part only)
combined.pem (combines the full-chain and the certificate private key)
fullchain.pem (it includes all the issuers chain)

Plus I of course have the keys

public.pem
private.pem

All those files are set in a specific location on my server, and are 0600, owned by a specific user (let say « acme »)

Few informations about my /etc/reTurn/reTurnServer.config :

TurnPort = 3478
TlsTurnPort = 5349

I am running the server with the user who owns the certificates (so they can be read) :
RunAsUser = acme
RunAsGroup = acme

And settings the absolute paths of the certificates

TlsServerCertificateFilename = /[...]/fullchain.pem
TlsServerPrivateKeyFilename = /[...]/private.pem

Authentication is working fine on port 3478, with the test user I’ve set ;
However, it doesn’t work on port 5349 (got some kind of timeout).

In the log file, I can see a "TlsConnection handshake failure error » :

WARNING | 20170130-105917.582 | reTurnServer | RETURN | 140414884460288 | TlsConnection.cxx:80 | TlsConnection handshake failure, error=335544539-short read

But I don’t understand what’s going on exactly ;
Do you know if there is something specific to check about TLS configuration, certificates or whatever ?
Am I supposed to provide the « fullchain.pem » certificate, or another one ?
(I’ve already tested with the four differente certificates, without success)

I’m also interested to know if there would be a better practice that running the server with my « acme » user,
But how to access the certificates ?

Best regards,

Florent Schildknecht
UX-designer et développeur web auto-entrepreneur
http://floschild.me/
+33 6 78 41 74 79 (France)
+46 7 64 15 32 64 (Sweden)

_______________________________________________
resiprocate-users mailing list
resiprocate-users@resiprocate.org
List Archive: http://list.resiprocate.org/archive/resiprocate-users/

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Follow-Ups:
- Re: [reSIProcate-users] TLS Handshake failure on debian 8
  - From: Scott Godin

References:
- [reSIProcate-users] TLS Handshake failure on debian 8
  - From: Florent SCHILDKNECHT
- Re: [reSIProcate-users] TLS Handshake failure on debian 8
  - From: Scott Godin

Prev by Date: Re: [reSIProcate-users] TLS Handshake failure on debian 8
Next by Date: Re: [reSIProcate-users] TLS Handshake failure on debian 8
Previous by thread: Re: [reSIProcate-users] TLS Handshake failure on debian 8
Next by thread: Re: [reSIProcate-users] TLS Handshake failure on debian 8
Index(es):
- Date
- Thread