I used HTTPS provisioning for the initial deployment of a few Sangoma P-Series phones.
Now, it no longer works.
I’m also trying to set up a TLS channel and SRTP for the same phone, but it’s not working either.
Other softphones have no issues with SIP-TLS.
I suspect these issues might be related. More details follow:
I set up TLS for SIP and SRTP on the server for a few extensions and tested with multiple softphones (MicroSIP, SIPnetic, Zoiper) from the local LAN, a VPN, and the internet.
They all worked after adjusting some certificate settings.
The FreePBX server now has a couple of ZeroSSL free certificates for multiple DNS names.
Each certificate includes both names as Subject Alternative Names (SANs).
The certificates contain the full chain and are trusted by these softphones and browsers.
I also tried switching between the two certificates.
Despite this, the Sangoma P330, provisioned via Endpoint Manager, wasn’t even able to register when using the TLS channel.
Apparently, no TLS session is established—I couldn’t see any SIP messages in the Asterisk log (more details below).
So, I switched back to the TCP channel for provisioning the P330, performed a factory reset, and the phone was able to register again.
However, it still does not fully provision—for example, BLF settings are missing.
The BLF XML file is correctly generated, and I can successfully download it via HTTPS in a browser without certificate warnings.
Wireshark capture shows the following TCP sequence between the client and the HTTPS provisioning port (non-standard): [SYN] → [SYN, ACK] → [ACK] immediately followed by [FIN, ACK] → [FIN, ACK] → [ACK].
Apparently, the phone closes the TCP connection right after the server’s ACK—
no attempt to negotiate TLS via Client Hello, nor any plain HTTP request or other communication.
Meanwhile, the client successfully establishes a TLS session with the server on other ports,
for example, the “Sangoma Phone Desktop Client Service” HTTPS port.
The FreePBX server is fully updated now.
HTTPS provisioning was working about three months ago, but had not been used again until yesterday.
This is just a thought from someone who used to work there, and who used to work on telephones, where I have no present ability to troubleshoot since I don’t have any of that gear anymore.
The firmware you’re using in P-Series land is just a much-updated derivative of what was originally D-Series firmware; specifically D80 firmware (holla!)
So, a lot of other vendors products “work fine,” and Sangoma products won’t, because those other products will just speak TLS to anything that responds to the HELLO, without making sure that what they’re talking to is what they think they’re talking to…which isn’t really great practice on the part of those other products.
Verification is done by comparing what we called the phone’s “big bundle,” which is a composite of the phone’s baked in list of CAs (derived from the cURL folks) and any config-loaded certificates.
If things were working 3 months ago, then I’d question whether a certificate on the server side changed and the big-bundle can’t validate things (maybe it’s a really old firmware). Or, the phone’s being directed to a URL where the server’s name (in the URL) doesn’t match the certificate it’s providing. Or, the phone doesn’t have accurate time and the server and the phone aren’t in alignment on whether a server-presented certificate is time-valid.
You can probably make things work by using the phone’s local UI to Enable Dangerous Unsigned SSL server support.
Anyway, good luck.
also, as with my last out-of-nowhere contribution, please don’t count on me for any followups of any kind. I’m just tossing stuff over a fence and continuing to walk.
Thanks for reply. Certificates likely changed recently, they renew every 90 days but…
What is strange, if I am reading well the packet capture, is that there is not even a TLS hanshake attempt by the client/phone after the TCP handshake.
The same happens also for RESTful app https tarffic.
On the other hand, for SangomaConnect https trafic, there is TCP handshake, successful TLSv1.3 handshake, and TLS Application data successfully exchanged: same client, same server, same certificates…
I also tried disabling the “internal” firewall on the FreePBX machine (same VLAN as the phone, so no other firewall) even if the LAN was already trusted.
Still on 4_25, any 4_26 available apparently for P330.
What is strange is that HTTPS provisioning is failing as described (no Client-Hello sent by phone after TCP handshake), while Sangoma Connect over HTTPS is successful.
