| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
Hey Scott,I’m sincerely sorry for the troubles,The server has always been working fine, it was actually a mistake in the configuration (client-side)…I was trying this within my _javascript_ web-app (and in the online tool aswell) :new RTCPeerConnection({'iceServers': [{'urls': ['turn:turn.my-domain.com:5349'],'username': 'test','credential': '*******'}]});And the URL was actually wrong, TURN over TLS needs the « turns » protocol, and not « turn »...new RTCPeerConnection({'iceServers': [{'urls': ['turns:turn.my-domain.com:5349' ],'username': 'test','credential': '*******'}]});Few hours lost for an « s », but at least it works fine :)Thank you again for your support,And for providing this great project !!Best regards,Florent Schildknecht+46 7 64 15 32 64 (Sweden)On 30 Jan 2017, at 21:11, Florent SCHILDKNECHT <florent.schildknecht@gmail.com > wrote:The first output was just the informations provided by the tool (https://webrtc.github.io/samples/src/content/peerconnection ) ;/trickle-ice/ Not 100% sure neither what it confirms, but just to say the first test indicates a « done » status,(which I can reproduce with any other working STUN / TURN server)And the second one a « not reachable? » one.The test client you have never seen is just a screenshot of my browser (Google Chrome),When I browse to https://turn.my-domain.com.I do not have a web application running behind, but just an « empty » nginx instance, to check the validity of the certificate.So I assume the same thing…I am quite sure the certificate is valid.I missed the point of it actually, I ran it on my personnal computer (client)…I’ll check how to run it on CLI on my VPS.Is there any alternative way to get more precise informations about the TLS handshake ?No chance you could know what this « wrong version number » error could mean?Thanks again,Florent Schildknecht+46 7 64 15 32 64 (Sweden)On 30 Jan 2017, at 20:52, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:...inline...On Mon, Jan 30, 2017 at 12:14 PM, Florent SCHILDKNECHT <florent.schildknecht@gmail.com > wrote: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 :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:3478username : testcredential : « my-hashed-password »Time Component Type Foundation Protocol Address Port Priority0.002 1 host 1026183099 udp My_Local_IP 51014 126 | 32542 | 2550.002 2 host 1026183099 udp My_Local_IP 59034 126 | 32542 | 2540.044 1 srflx 3160557839 udp My_Public_IP 34652 100 | 32542 | 2550.049 2 srflx 3160557839 udp My_Public_IP 34653 100 | 32542 | 2540.102 1 host 1940501323 tcp My_Local_IP 9 90 | 32542 | 2550.102 2 host 1940501323 tcp My_Local_IP 9 90 | 32542 | 2540.169 Done[Scott] I don't understand what this output is. Is this tracerte output from your client?Second test (port 5349) :Time Component Type Foundation Protocol Address Port Priority0.002 1 host 1026183099 udp My_Local_IP 58981 126 | 32542 | 2550.002 2 host 1026183099 udp My_Local_IP 58354 126 | 32542 | 2540.103 1 host 1940501323 tcp My_Local_IP 9 90 | 32542 | 2550.103 2 host 1940501323 tcp My_Local_IP 9 90 | 32542 | 2549.560 Not reachable?1. I’ve set the logger level to DEBUG in the reTurnServer.config file.Now, I have those logs :## Server startINFO | 20170130-171540.513 | reTurnServer | RETURN | 140023855642432 | UdpServer.cxx:30 | UdpServer started. Listening on X.X.X.X:3478INFO | 20170130-171540.513 | reTurnServer | RETURN | 140023855642432 | TcpServer.cxx:35 | TcpServer started. Listening on X.X.X.X:3478INFO | 20170130-171540.515 | reTurnServer | RETURN | 140023855642432 | TlsServer.cxx:73 | TlsServer started. Listening on X.X.X.X:5349INFO | 20170130-171540.515 | reTurnServer | RETURN | 140023855642432 | UdpServer.cxx:30 | UdpServer started. Listening on Y:Y:Y:Y:Y:Y:3478INFO | 20170130-171540.515 | reTurnServer | RETURN | 140023855642432 | TcpServer.cxx:35 | TcpServer started. Listening on Y:Y:Y:Y:Y:Y:3478INFO | 20170130-171540.516 | reTurnServer | RETURN | 140023855642432 | TlsServer.cxx:73 | TlsServer started. Listening on Y:Y:Y:Y:Y:Y:5349## When I try to connect my webrtcDEBUG | 20170130-173043.614 | reTurnServer | RETURN | 140023809464064 | TlsConnection.cxx:44 | TlsConnection started.WARNING | 20170130-173047.462 | reTurnServer | RETURN | 140023809464064 | TlsConnection.cxx:80 | TlsConnection handshake failure, error=336130315-wrong version numberDEBUG | 20170130-173047.462 | reTurnServer | RETURN | 140023809464064 | TlsConnection.cxx:32 | TlsConnection destroyed.The openssl version I am using is :OpenSSL 1.0.1t 3 May 2016[Scott] Interestingly enough the error in this log is different than what you previously posted. This shows "wrong version", previous error was "short read". Not sure what that means at this point. So I'm assuming there was no errors about reading or parsing your certificate files?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)<certificate-screen.jpeg>(Which means the certificate is valid... Right?)[Scott] I have never used that test client, so I'm not familiar with it. However is appears to be a browser base app, so I would assume if the browser is happy with the root CA, then you will be good, but I can't say for sure. The bottom line is that the client needs to trust the certificate that the server presents. I think the wireshark trace will help confirm here.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.[Scott] OK good. :)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…<wireshark-screen.jpeg>[Scott] I'm not sure what I'm looking at in this screenshot. You should be running wireshark on the reTurn machine and start tracing port 5349 or filter you output to only view TCP port 5349. You should be able to decode the traffic on this port as SSL/TLS traffic and see the handshake messaging.Thanks again in advance,Best regards,Florent Schildknecht+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. :)ScottOn Mon, Jan 30, 2017 at 5:22 AM, Florent SCHILDKNECHT <florent.schildknecht@xxxxxxxxm > 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 keyspublic.pemprivate.pemAll 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 = 3478TlsTurnPort = 5349I am running the server with the user who owns the certificates (so they can be read) :RunAsUser = acmeRunAsGroup = acmeAnd settings the absolute paths of the certificatesTlsServerCertificateFilename = /[...]/fullchain.pemTlsServerPrivateKeyFilename = /[...]/private.pemAuthentication 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 readBut 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+46 7 64 15 32 64 (Sweden)
_______________________________________________
resiprocate-users mailing list
resiprocate-users@resiprocate.org
List Archive: http://list.resiprocate.org/archive/resiprocate-users/