This is similar to a previous post but focuses to a single issue. I also tryed to open a support ticket (it’s included for the Sangoma phones, right?) but I have issue logging in at help.sangoma.com.
I used HTTPS provisioning for the initial deployment of a few Sangoma P-Series phones. Now, it no longer works.
More details follow:
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 browsers. I also tried switching between the two certificates.
I switched to the TCP channel for provisioning the P330, performed a factory reset, and the phone was able to register and get its extension configuration. 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 or with cURL without certificate warnings.
The phone are in the same VLAN of the FreePBX, no external firewall involved.
Provisioning protocol is setup as https on non-standard port selected via System Admin commercial module, with credentials.
The FreePBX 17 server is fully updated now (Jul 2025) and also the phone firmware is updated (4_26_1).
HTTPS provisioning was working at the beginning of the year, but had not been used again until recently.
Hi @unlikely
There are no known issues with this. We are able to provision PX phones via HTTPS, and even the BLF keys are successfully loaded to the phone.
Can you clarify the exact issue you’re facing with BLF?
Are the BLF keys not being loaded to the phone?
Are the BLF keys loaded but not displaying?
Are the BLF key files (exten-1-blf.xml and exten-1.xml) not being downloaded?
You can check the logs on a v17 system — they are stored at: /var/log/apache2/other_vhosts_access.log
Today I performed a packet capture to analyze the HTTPS provisioning behavior between a Sangoma P-Series phone and the FreePBX server. The provisioning is configured on a non-standard HTTPS port.
The capture confirms that the phone initiates a TCP handshake with the server: SYN → SYN-ACK → ACK. However, no TLS traffic follows. Specifically, there is no Client Hello, no certificate exchange, and no application data. The connection is immediately closed with FIN-ACK sequences from both sides.
This indicates that the phone opens the TCP connection but does not proceed with the TLS handshake. The same certificate is successfully used by the phone on other services and ports, which suggests that the certificate itself is not the issue.
At this stage, the TLS session is not being initiated by the phone, despite the server being reachable and responsive.
Notably, when switching the provisioning protocol in the template from HTTPS to HTTP—and re-enabling HTTP at both the port and provisioning protocol level—the phone resumes provisioning correctly. This confirms that the issue is specifically tied to HTTPS provisioning behavior.
The server certificate was replaced with a Let’s Encrypt-issued one (Issuer: E8), but the behavior remains unchanged. The phone completes the TCP handshake on port 2096, then immediately closes the connection without initiating TLS.
Firmware has since updated to version 4.27.2, with no change in behavior. Provisioning over HTTP still works when re-enabled.
A packet capture was performed directly on the router interface connected to the phone. The result confirms the same behavior: a complete TCP handshake on port 2096, followed by immediate connection closure without any TLS handshake. In parallel, TLSv1.3 traffic is correctly established on port 8443 for other Sangoma services, using the same Let’s Encrypt certificate.
This reinforces that the issue is specific to HTTPS provisioning on port 2096, not related to certificate validity or general TLS functionality.
A new test was conducted using port 1443, which is the default HTTPS provisioning port defined by FreePBX. The server is correctly configured and serves the provisioning files (5001-1.xml, 5001-1-blf.xml) without issue—confirmed via direct browser access.
The Sangoma P330 phone successfully completes the TCP handshake on port 1443, but does not initiate a TLS session. No Client Hello is observed in the packet capture, indicating that the phone does not attempt to establish a secure connection on this port, despite the certificate being valid and the content accessible.
Further tests were conducted to investigate the phone’s behavior during HTTPS provisioning.
The phone’s Web GUI was re-enabled by modifying the basefile template, allowing temporary access for configuration.
Syslog DEBUG logging was activated on the device and directed to the FreePBX server (UDP/514), though the server is not yet configured to receive or store these logs.
Syslog packets were captured using Wireshark, filtered by source IP and message content.
During HTTPS provisioning attempts, a recurring error was observed immediately after successful TCP handshake:
[1341]E/middleman: cURL Error:77 Problem with the SSL CA cert (path? access rights?)
This suggests the phone fails to initiate TLS due to issues accessing or validating the CA certificate, despite the server being reachable and serving valid content over HTTPS.
This error also appears near connections to port 8443, although in that case the phone proceeds to successfully establish a TLS session.
Additional syslog messages were captured but appear less relevant at this stage.