While typing this out, I realized the issue, but wanted to put it out there for others…
Using FreePBX 15.0.37.4, this system has been up for a number of years, but this issue only recently appeared.
We have a fqdn, with a commercial cert mapped to the phone system firewall then natted to freePBX
inside a firewall, ports forwarded
90% of our users are from outside the network. they use non-company networks, no VPN. For example soft phone app on pc, mobile etc… so they are NEVER coming from inside the network. this works perfectly.
We recently opened an office inside the same building as the PBX so calls from those phones will be in the same network as the PBX. These phones and ONLY these phones drop after 30 sec.
I realized by looking at logs that it seems to be that its trying to validate the cert to the internal IP…
2024-01-03 07:41:56:050 [linphone/belle-sip] ERROR Channel [0x7ff6d8068000]: SSL handshake failed : X509 - Certificate verification failed, e.g. CRL, CA or signature check failed
2024-01-03 07:41:56:050 [linphone/belle-sip] ERROR Cannot connect to [TLS://192.168.yyy.xxx:25061]
[this is where I realized the issue]
the issue is that the public DNS resolves the FQDN properly for the external address, both forward and reverse lookups. so when phones connect from outside the network, they connect with the FQDN and decrypts with the FQDN / public IP
looking at the failed calls in the log they are attempting to connect to the internal ip not the external one. So its trying to validate the cert that’s mapped to the hostname/ip, which resolves to the external ip, and it fails because that’s not the IP it got the connection from.
SOLUTION
The fqdn on the cert is all that matters, make sure the internal and external DNS servers map to a proper IP for the network they are on, and they don’t have to be the same, generally they won’t in this case. Internal clients get one IP via internal dns from the hostname and externals another from external dns… they both then resolve properly. the certs don’t care, as a matter of fact they have no idea what the IP is, validation handles that.
I recognize also the dns cache could break this if a mobile for example is on and off the network rapidly and the wrong address is cached. This seems to be ok and we haven’t yet had that issue.