SOLVED TLS connection handshake terminated by FS

[etsiot]

Trying to get some remote Yealink phones as well as mobile phones (Groundwire) to use TLS instead of openVPN
I am using a non-default port for the internal profile (i.e. non 5061).
Connections are incoming in the FusionPBX box, can see them with netstat however they get stuck in TIME_WAIT state.
Yealink logs report an error code 1040, Groundwire times out the connection multiple times after waiting.
The listening port is indeed owned by freeswitch as evidenced by ss -lptn 'sport =xxx'

Can't see anything related though neither looking at the fs logs, nor with sngrep, nothing shows up.

Any hints on how to debug this?

 

[etsiot]

At this point I have pretty much exhausted the places I can look into.
I have wildcard Let's Encrypt cert issued, /etc/freeswitch/tls contains the certs, owned by www-data
yet, when I try to connect from remote on the tls port I get the following:

# openssl s_client -tls1_2 -connect sip.xxx.xxx:xxxx 14:28:37
CONNECTED(00000005)
4367468076:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure:/System/Volumes/Data/SWE/macOS/BuildRoots/b8ff8433dc/Library/Caches/com.apple.xbs/Sources/libressl/libressl-75/libressl-2.8/ssl/ssl_pkt.c:1200:SSL alert number 40
4367468076:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake failure:/System/Volumes/Data/SWE/macOS/BuildRoots/b8ff8433dc/Library/Caches/com.apple.xbs/Sources/libressl/libressl-75/libressl-2.8/ssl/ssl_pkt.c:585:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Start Time: 1640176169
Timeout : 7200 (sec)
Verify return code: 0 (ok)


Looks like no certificates can be accessed/used by the server?'
Any help where to look is more than welcome

 

[cemotyz09]

You don't specify if you've configured FPBX to accept tls in advanced > vars but if you have try

eval $${certs_dir} in fs_cli

. I had an issue where no matter what I did it wouldn't use the correct directory until it magically did it on its own

 

[cemotyz09]

Sorry on a phone "eval $${certs_dir}" is the correct command

 

[etsiot]

eval $${certs_dir} evals correctly to /etc/freeswitch/tls.
When I created them with letsencrypt scrip per the docs, no error was thrown.
permissions look OK as well.

# ls -la /etc/freeswitch/tls
total 44
drwxr-x--- 2 www-data www-data 4096 Dec 22 17:19 .
drwxr-xr-x 13 www-data www-data 4096 Dec 22 13:33 ..
lrwxrwxrwx 1 www-data www-data 27 Dec 22 13:14 agent.pem -> /etc/freeswitch/tls/all.pem
-rw-r--r-- 1 www-data www-data 5637 Dec 22 13:14 all.pem
-rw------- 1 www-data www-data 1598 Dec 22 13:14 cert.pem
-rw------- 1 www-data www-data 3751 Dec 22 13:14 chain.pem
-rw-rw---- 1 www-data www-data 4980 Dec 22 17:19 dtls-srtp.pem
lrwxrwxrwx 1 www-data www-data 27 Dec 22 13:14 dtls-srtp.pem.old -> /etc/freeswitch/tls/all.pem
-rw------- 1 www-data www-data 5349 Dec 22 13:14 fullchain.pem
-rw------- 1 www-data www-data 288 Dec 22 13:14 privkey.pem
lrwxrwxrwx 1 www-data www-data 27 Dec 22 13:14 tls.pem -> /etc/freeswitch/tls/all.pem
lrwxrwxrwx 1 www-data www-data 27 Dec 22 13:14 wss.pem -> /etc/freeswitch/tls/all.pem

Could it be that the certificate is a wildcard one?

 

[DigitalDaz]

No, wildcards work fine

What happens if you try curling https://valid-isrgrootx1.letsencrypt.org/ from the server, do you get any error?

 

[etsiot]

curling https://valid-isrgrootx1.letsencrypt.org/ worked; however, last evening I started looking at the pems created by the dehydrated script.
The all.pem stored in /etc/freeswitch/tls was missing both the ISG Root X1 certificate as well the chain in the header.
So I was getting the following:

# openssl verify -CAfile all.pem  tls.pem
C=US, O=Let's Encrypt, CN=R3
error 2 at 1 depth lookup: unable to get issuer certificate
error tls.pem: verification failed

It was late so I didn't have time to look into that further...

 

[etsiot]

Ended up working with self-signed certificates...