processone / eturnal

STUN / TURN standalone server
https://eturnal.net
Apache License 2.0
225 stars 22 forks source link

SSL problem #75

Closed docjojo closed 1 week ago

docjojo commented 1 week ago

Hello,

i have switched from let's encrypt to PositiveSSL and now have problems. I used to have the let's encrypt .pem files but now got .ca-bundle and .crt. I tried to use them as .pem files but eturnal fails to establish TURN/TURNS. Not sure if the error is really SSL related or has another reason? Can you tell from the log? Why is error "TURN is disabled" - isn't that the default?

[info] Accepting connection: 176.198.203.x3:14289 -> 10.0.91.2:3478 [TCP, session 93o37c4zdv8l]
2024-06-26 17:41:14.715192+00:00 
[notice] Rejecting TURN request: TURN is disabled [UDP, session nap6mjgpggln, anonymous, client 176.198.203.203:27300]
2024-06-26 17:41:14.889700+00:00 
[info] Accepting connection: 176.198.203.x3:57031 -> 10.0.91.2:5349 [TCP|TLS, session 05wat0l7pi7c]
2024-06-26 17:41:14.891689+00:00 
[notice] Cannot start connection: SSL_CTX_use_certificate_file failed: error:04800066:PEM routines::bad end line [TCP|TLS, session 05wat0l7pi7c]
2024-06-26 17:41:14.891338+00:00 
[error] CRASH REPORT:
  crasher:
    initial call: stun:init/1
    pid: <0.625.0>
    registered_name: []
    exception exit: <<"SSL_CTX_use_certificate_file failed: error:04800066:PEM routines::bad end line">>
      in function  p1_fsm:init_it/6 (p1_fsm.erl, line 386)
    ancestors: [stun_tmp_sup,stun_sup,<0.582.0>]
    message_queue_len: 0
    messages: []
    links: [<0.587.0>]
    dictionary: [{'$logger_metadata$',
                      #{domain => [stun,stun],
                        stun_transport => <<"TLS">>,
                        stun_session_id => <<"05wat0l7pi7c">>,
                        stun_client => ["176.198.203.x3",":57031"],
                        stun_user => anonymous}}]
    trap_exit: true
    status: running
    heap_size: 987
    stack_size: 28
    reductions: 423
  neighbours:
# eturnal STUN/TURN server configuration file.

eturnal:

  listen:
    -
      ip: "::"
      port: 3478
      transport: udp
    -
      ip: "::"
      port: 3478
      transport: tcp
    -
      ip: "::"
      port: 5349
      transport: udp
    -
      ip: "::"
      port: 5349
      transport: auto

  tls_crt_file: /opt/eturnal/certs/fullchain.pem
  tls_key_file: /opt/eturnal/certs/privkey.pem

  credentials:
    test: "test"

  blacklist_peers:
    - recommended

  log_level: info
  log_dir: /opt/eturnal/log
weiss commented 1 week ago

"SSL_CTX_use_certificate_file failed: error: [...] PEM routines::bad end line"

OpenSSL is telling you that the certificate/key file(s) aren't in PEM format. Either you received a different format from PositiveSSL (can easily be converted, but the details depend on the format), or you modified them by accident.

Why is error "TURN is disabled" - isn't that the default?

Yes, but I'd suggest fixing the TLS issue first and opening a new issue if you still see that message afterwards.

docjojo commented 1 week ago

Both .pem are checked valid and key match. Problem remains though. Any idea?

` openssl rsa -noout -modulus -in privkey.pem | openssl md5 MD5(stdin)= 603a8975d580d81036b82efd080d8ee7

openssl x509 -noout -modulus -in fullchain.pem | openssl md5 MD5(stdin)= 603a8975d580d81036b82efd080d8ee7

openssl rsa -inform PEM -in privkey.pem
writing RSA key -----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCtoshMSFuGNr2T ADN13mH4qmssBOO..........0ZZ+AWIdabYrsuYZKD /zDmR8OuBtP8igpew754qiOfZ/PM959dyWhoMmC6iUkXtCSXALEjrtNT6vbozudr BBjJt4zeKCJHl8iGQU53bxm8 -----END PRIVATE KEY-----

openssl x509 -inform PEM -in fullchain.pem

-----BEGIN CERTIFICATE----- MIIGMjCCBRqgAwIBAgIRAOyv7fm7tVz6YrGYs5dGtyEwDQYJKoZIhvcNAQELBQAw gY8xCzAJBg......NeSmBXUWI1A4G8TBJb99+J2Ws wIAYMdzi89W+Cj8gJtomJksDGi5chuCME6B1+xg6uBGZ4E6/B7HjRTDVk+9mrtZJ 3eM2tawOPDI/kvwkvzZ6rvtG1aTt36l8FiJDCOQN2UKlvTGiYLz2G4as8+FLfPw6 lpPg5waC -----END CERTIFICATE-----`

docjojo commented 1 week ago

openssl verify -CAfile fastturn_pro.ca-bundle fullchain.pem fullchain.pem: OK

weiss commented 1 week ago

Well the error message is bad end line, and that error is emitted by OpenSSL, not eturnal. I don't know why the openssl command line tool isn't stumbling over the same issue, and I can't tell you what exactly is wrong without looking at the PEM file.

Searching the web for OpenSSL "bad end line" might give you some ideas to check.

docjojo commented 1 week ago

Thank you. I could not figure out the problem with the cert file and have switched back to let's encrypt which works fine with eturnal on different machines. Also using the same config file. However on this machine I am still getting errors. Even though I am using the original let's encrypt files.

Connection failure: SSL_do_handshake failed Is there something on the machine missing to handle the certs?

` drwxr-xr-x 2 eturnal eturnal 4096 Jun 27 11:14 . drwxr-xr-x 10 eturnal eturnal 4096 Jun 26 16:04 .. -rw-r--r-- 1 eturnal eturnal 3562 Jun 27 11:14 fullchain.pem -rw------- 1 eturnal eturnal 1704 Jun 27 11:14 privkey.pem

root@C20240620043885:/opt/eturnal/certs# openssl rsa -noout -modulus -in privkey.pem | openssl md5 MD5(stdin)= 3ffe7bc8f336464591f3cba1c2e0635c

root@C20240620043885:/opt/eturnal/certs# openssl x509 -noout -modulus -in fullchain.pem | openssl md5 MD5(stdin)= 3ffe7bc8f336464591f3cba1c2e0635c `

2024-06-27 11:16:24.590523+00:00 [info] Accepting connection: 176.198.203.xxx:2174 -> 10.0.91.2:3478 [TCP, session pvlz1lpfkcvv] 2024-06-27 11:16:24.604390+00:00 [info] Connection reset by peer [TCP, session pvlz1lpfkcvv, anonymous, client 176.198.203.xxx:2174] 2024-06-27 11:16:28.160957+00:00 [info] Accepting connection: 176.198.203.xxx:1632 -> 10.0.91.2:3478 [TCP, session 62fge7au23lm] 2024-06-27 11:16:28.172625+00:00 [info] Connection reset by peer [TCP, session 62fge7au23lm, anonymous, client 176.198.203.xxx:1632] 2024-06-27 11:16:38.380993+00:00 [notice] Rejecting TURN request: TURN is disabled [UDP, session 2plr7i72jl2q, anonymous, client 176.198.203.xxx:8140] 2024-06-27 11:16:40.025298+00:00 [info] Accepting connection: 176.198.203.xxx:2113 -> 10.0.91.2:5349 [TCP|TLS, session o7vbajlyqcza] 2024-06-27 11:16:40.035026+00:00 [info] Accepting connection: 176.198.203.xxx:2158 -> 10.0.91.2:5349 [TCP|TLS, session pvj2w1qpf4wi] 2024-06-27 11:16:40.207865+00:00 [info] Connection failure: SSL_do_handshake failed: error:0A000416:SSL routines::sslv3 alert certificate unknown [TLS, session o7vbajlyqcza, anonymous, client 176.198.203.xxx:2113] 2024-06-27 11:16:40.212275+00:00 [info] Connection failure: SSL_do_handshake failed: error:0A000416:SSL routines::sslv3 alert certificate unknown [TLS, session pvj2w1qpf4wi, anonymous, client 176.198.203.xxx:2158] root@C20240620043885:/opt/eturnal/log#

docjojo commented 1 week ago

Same .pem files are in use by apache and resolve ok in the browser when opening the webpage. So I really don't know what's wrong.

weiss commented 1 week ago

Maybe the WebRTC client isn't using the same TURN host name as you're using in the browser? (Maybe it's using an IP address instead?)

docjojo commented 1 week ago

thank you! yes you are right, the client is requesting the IP directly, however that is exactly what i am doing on the other machines, and there STUN 3478, 5349 and TURN 3478 work ok. I understand that TURNS can not work without hostname / SSL. But TURN should work without hostname, i think?

weiss commented 1 week ago

But TURN should work without hostname, i think?

Yes, absolutely. But the error you've show was triggered by a client attempting TURNS. (A client will usually try all options you're offering, so the call may well just work via UDP despite this error message.)

docjojo commented 1 week ago

thank you!

docjojo commented 1 week ago

I have set relay_ipv4_addr after this message from eturnal

2024-06-27 15:35:51.789126+00:00 [info] Relay IPv4 address not configured 2024-06-27 15:35:51.789597+00:00 [info] Relay IPv6 address not configured 2024-06-27 15:35:51.789828+00:00 [info] Listening on 127.0.0.1:3470 (tcp) (Erlang protocol version 5) 2024-06-27 15:35:51.790630+00:00 [warning] Specify a 'relay_ipv4_addr' to enable TURN

Now it works!

paulmenzel commented 5 days ago

Great that, it works now. As a lurker, how could this have been debugged quicker in hindsight?

docjojo commented 5 days ago

can't say, i didn't get this message in the logs before. relay_ipv4_addr wasn't required in other installations, so there must be some issue with auto-detecting IP4 address of the machine.

weiss commented 5 days ago

how could this have been debugged quicker in hindsight?

Two unrelated problems were mentioned in this issue:

  1. OpenSSL complaining about a PEM file because of a bad end line. As there's no way to get an (even) more specific message out of OpenSSL, I see no alternative to looking at the -----END CERTIFICATE----- (and KEY) lines in the PEM file(s). It might just have been something trivial such as a missing newline at the end. Note that eturnal actually copies and concatenates the configured PEM files into a single file within the run_dir, so checking that one might make the problem more obvious. (I'm thinking about adding an extra newline between concatenated files to avoid this specific issue.)
  2. TURN requires an IPv4 relay address. If no address is configured, eturnal tries to auto-detect it, but if that fails, it will log the following messages, as @docjojo mentioned:
[info] Relay IPv4 address not configured
[info] Relay IPv6 address not configured
[warning] Specify a 'relay_ipv4_addr' to enable TURN

Not sure whether complaining even louder would be desirable in this case.

docjojo commented 5 days ago

How about that, if auto detect doesn't work?

curl ipconfig.io > /opt/eturnal/my.ip
export ETURNAL_RELAY_IPV4_ADDR=$(cat /opt/eturnal/my.ip)
/opt/eturnal/bin/eturnalctl reload
echo $ETURNAL_RELAY_IPV4_ADDR
crontab -e
@reboot  /opt/eturnal/eturnal.env.sh
weiss commented 5 days ago

Our Docker containers do something along those lines. Except they use STUN instead of HTTP :smile: