HTTPS Provisioning failure on P Series

Sangoma Hardware Phones
21

From what I understand, it’s the phone itself that fails to access or validate the CA certificate trust store, so it doesn’t even attempt an HTTPS connection.

  • The firmware might be referencing a CA path that doesn’t exist or isn’t accessible.
  • The certificate file could be present but have incorrect permissions.
  • The CA bundle might be missing or corrupted within the firmware.
  • …

So the error seems to originate from how the phone handles certificate validation internally.

I also tried downgrading to the November/December firmware version, but that doesn’t seem to be supported.

Am I right?

22

This thread is a continuation of HTTPS Provisioning and SIP-TLS failure on P Series where Malcolm’s reply seems very relevant.

23

That previous thread was also mine—I had been troubleshooting SIP-TLS at the time, which was a new configuration I was experimenting with. I never really understood whether Malcom’s reply was meant to help resolve the issue, and unfortunately, that discussion ended without a solution.

Later on, I opened a separate thread focused specifically on HTTPS provisioning. Unlike SIP-TLS, HTTPS provisioning had worked in the past—at least as far as I can recall—so I felt it deserved dedicated attention.

I really hope Sangoma can finally step in with meaningful input and a resolution. We’re talking about their flagship phones, and this issue has been dragging on for over five months. Every small step forward has come from my own testing and analysis.

24

It sounds to me as though the phone doesn’t trust ZeroSSL. Normally you would fix that by installing the root CA used by ZeroSSL, and any intermediate certificates that your server is not volunteering. Not having used the phone, I don’t know the procedures for doing that.

25

Nothing changes with LE as recently wrote.
And phone doens’t even send ClientHello so doens’t even receive the server certificate.

26

You should be able to open a ticket now. Please try again.

27

Hello, I think I was finally able to login snd open the ticket.
Waiting for a solution for this.

28

Good to know - if you’d like please PM the ticket ID so I can follow along.

29

Can youvdo something to solve this issue? The hotel is about to open for the new season with all sangoma phones unprovisioned: no blf, no contacts, no logo, no apps. Very bad after the investment in many P330 P370 phones.

30

Yes - for sure. please send me the ticket. Sending you a DM now

32

I just found something that might help clarify the TLS negotiation issue. While reviewing the syslog from one P330 phone (configured for SIP-TLS), I noticed a more specific error involving certificate decoding.

Here’s the relevant portion of the log:

2025-11-15T15:31:36+01:00 dphonecored: [608]E/pjproject: ssl0x778118 !Error loading CA list file ‘/nvdata/certs/certs.crt’: bad base64 decode

This seems to confirm that the phone is attempting TLS connection for SIP signaling, but fails due to a corrupted or malformed certificate file (certs.crt). It looks like the issue is internal to the device — possibly related to firmware or a previous upgrade — rather than anything on the server side.

This issue is for sure the reason why also with HTTPS provisiong TLS negotiation doesn’t event start.

33

I just discovered another impact of the TLS trust store corruption.
Also Phone Apps like Call Logs, Time Conditions and so on are affected.
Any attempt to use them reports an error in cURL or on generic server access.
So the impact of this issue is very wide and almost all the phones features beside basic are affected.

We can’t wait anymore. Please escalate this case and provide a definitive solution immediately.
We reported the issue on May 15 on the community, and the support case has now been open for over a month and a half.

Here is a full log excerpt showing the issue:

2025-11-16T18:31:52+01:00 10.185.30.19 lisa: [ 606]I/dpcore: send Sending requestFileCurl requestUser(admin) requestPassword(…) requestUri(https://pbx.mydomain.tld:2087/dphoneApi.php/json) {“request”:{“method”:“switchvox.users.callLogs.getList”,“parameters”:{“account_id”:“30”,“sort_field”:“start_time”,“sort_order”:“DESC”,“max_entries”:“50”}}}
2025-11-16T18:31:52+01:00 10.185.30.19 lisa: [ 606]D/GeneralRequests: insert request-id ‘call_log347’ duration-timeout 20000 ms, progress-timeout -1 s 2025-11-16T18:31:52+01:00 10.185.30.19 lisa: [ 885]I/middleman: Sending cURL request to https://pbx.mydomain.tld:2087/dphoneApi.php/json with body {“request”:{“method”:“switchvox.users.callLogs.getList”,“parameters”:{“account_id”:“30”,“sort_field”:“start_time”,“sort_order”:“DESC”,“max_entries”:“50”}}} and id call_log347
2025-11-16T18:31:52+01:00 10.185.30.19 lisa: [ 885]D/middleman: getFilecURL - sslInfo=Secure
2025-11-16T18:31:52+01:00 10.185.30.19 lisa: [ 604]D/dphonecored: KeyHandlerSangoma Key code:0x0043 value:0x0000
2025-11-16T18:31:52+01:00 10.185.30.19 lisa: [ 885]E/middleman: cURL Error:77 Problem with the SSL CA cert (path? access rights?)
34

I’ve done extensive research on this issue while waiting for Sangoma support.

The following thread seems related, but unfortunately it doesn’t provide a final solution (if any was found):
https://community.freepbx.org/t/freepbx-17-sangoma-p330-320-310-epm-with-dpma-enabled/103679

On my side, I discovered that I can enable SIP‑TLS and have the Sangoma P330 successfully and completely provision and register to FreePBX, as long as HTTPS Provisioning and PhoneApps protocols are disabled.

As soon as I enable one or both of these features in Endpoint Manager for my phone template, after the first conversation between the phone and FreePBX and the first reboot, the phone hangs on “fetching”. At some point I can manually select the DPMA server advertised via mDNS (DPMA protocol runs over TCP), and the phone continues provisioning—but incompletely (no logo, no BLF, no contacts) and SIP‑TLS registration fails.

Capturing syslog from the phone shows again the familiar “bad base64 decode” error, but in a slightly different form. This time I can see more detail of the problematic certificate: it appears split across multiple SIP/MESSAGE packets. The certificates are issued to a “Digium” subject, not related to my domain.

I verified with openssl s_client that the HTTPS provisioning port correctly presents my Apache/Let’s Encrypt certificate, which validates successfully. This confirms that the problem is not related to the HTTPS server certificate.

The problematic certificates are instead Digium‑issued, auto‑generated by DPMA, with CN=AppServer or CN=Digium Appserver, long validity (30 years), and weak RSA 1024 keys. They are fragmented across multiple SIP MESSAGE chunks, sometimes even with different Call‑IDs, which likely prevents proper reassembly. This mismatch seems to be the root cause of the bad base64 decode errors and the phone hanging on fetching.

My questions are:

  1. Is HTTPS Provisioning + HTTPS PhoneApps + SIP‑TLS officially supported?

  2. Am I the only one experiencing this issue?

  3. Can Sangoma reproduce this issue?

  4. Does Sangoma already know what to check or how to solve it?

See the following syslog capture for reference.

2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:  tsx0xac0281f4  Failed to send Request msg MESSAGE/cseq=62615 (tdta0xac0050cc)! err=480900 (bad base64 decode)
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:     pjsua_im.h  Failed to deliver message '-----BEGIN CERTIFICATE-----
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: MIICtDCCAh0CAVUwDQYJKoZIhvcNAQEFBQAwYDELMAkGA1UEBhMCVVMxCzAJBgNV
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: BAgMAkNBMRIwEAYDVQQHDAlTYW4gRGllZ28xFTATBgNVBAoMDERpZ2l1bSwgSW5j
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: LjEZMBcGA1UEAwwQRGlnaXVtIEFwcHNlcnZlcjAgFw0yNTA4MjcxMzM1MjZaGA8y
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: MDU1MDgyMDEzMzUyNlowSzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRQwEgYD
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: VQQKDAtEaWdpdW0sIEluYzEZMBcGA1UEAwwQRGlnaXVtIEFwcHNlcnZlcjBcMA0G
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: CSqGSIb3DQEBAQUAA0sAMEgCQQDcScSzC4a9qhuFISfwWSPspZUzZ/UqqO9RYiS+
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: LZT1mvCzj30bzZ3BoqEJl9zzn4dvdcm7Wc7UmD3GHf/B5pkRAgMBAAGjgdkwgdYw
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: CQYDVR0TBAIwADAuB': 503/bad base64 decode
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]I/pjproject:    pjsua_acc.c  Disconnected notification for transport tlsc0xb4327ab4
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]I/pjproject: sip_transport.  Transport tlsc0xb4327ab4 shutting down, force=0
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:  tsx0xac01884c  Failed to send Request msg MESSAGE/cseq=51471 (tdta0xac0213d4)! err=480900 (bad base64 decode)
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:     pjsua_im.h  Failed to deliver message 'TeXHqr7UfYA5mc4ZlBkzP/VZuxssH6lUHvXBPkZbVBRt
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: sHEfMy7DbiM5xvrHIPDnoj197ccSG9jPcqwSBzkCM9xnbtokieefmMQgtP+Re11g
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: sapyKIF2UGc7V3JORQnREfc5tqgJSqMxw2SyPetJj0n7K/94tcZY/nRxlBolgyNZ
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: jnW9XTB+3yyCd1oGWkSz5eWqtyolSNNTxq6vli8MEUilosEa9bTm4cv132Vua8AS
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: Ixie4rWMNO1xQQD3Rdqs6zXrB1VyjwNegmeoGUr5dQIoIcT2LAaUzhLB26/Tko1P
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: ZwGBzFQ+5v8ssA/246JclBEsZeEGX8gHGc1XXaIavZMRtKQRblOhyF0s2n1+e5Zq
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: zukkxVqf0GhdGbkBo02bhXHH5BbaJPJZwDAVWtXm04er2cMTouVCsVdUS+gi7O/T
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: Z4tWQqgfr173zHqZ
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: -----END CERTIFICATE-----
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: ': 503/bad base64 decode
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:  tsx0xb43e8da4  Failed to send Request msg MESSAGE/cseq=37399 (tdta0xac01a6fc)! err=480900 (bad base64 decode)
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:     pjsua_im.h  Failed to deliver message '--BEGIN CERTIFICATE-----
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: MIIF2zCCA8OgAwIBAgIFLyA4uEYwDQYJKoZIhvcNAQELBQAwdjELMAkGA1UEBhMC
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: VVMxEDAOBgNVBAgMB0FsYWJhbWExEzARBgNVBAcMCkh1bnRzdmlsbGUxHTAbBgNV
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: BAoMFFNhbmdvbWEgVGVjaG5vbG9naWVzMQ8wDQYDVQQLDAZQaG9uZXMxEDAOBgNV
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: BAMMB1Jvb3QgQ0EwIBcNMjQwNDA1MTQxNDE2WhgPMjEyNDAzMTIxNDE0MTZaMH4x
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: CzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdBbGFiYW1hMRMwEQYDVQQHDApIdW50c3Zp
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: bGxlMR0wGwYDVQQKDBRTYW5nb21hIFRlY2hub2xvZ2llczEPMA0GA1UECwwGUGhv
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: bmVzMRgwFgYDVQQDDA9JbnRlcm1lZGlhdGUgQ0EwggIiMA0GCSqGSIb3DQEBAQUA
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: A4ICDwAwggIKAoICAQCn': 503/bad base64 decode
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:  tsx0xac0030a4  Failed to send Request msg MESSAGE/cseq=44727 (tdta0xb432d7c4)! err=480900 (bad base64 decode)
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:     pjsua_im.h  Failed to deliver message 's/Serjbih542Q75RDctV6UPJhW7t+zsoi1aB6p6
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: 7fGisnQ7iMG8Ahv8ipRZ
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: -----END CERTIFICATE-----
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: -----BEGIN CERTIFICATE-----
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: MIIFSDCCAzACAVUwDQYJKoZIhvcNAQEFBQAwfjELMAkGA1UEBhMCVVMxEDAOBgNV
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: BAgMB0FsYWJhbWExEzARBgNVBAcMCkh1bnRzdmlsbGUxHTAbBgNVBAoMFFNhbmdv
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: bWEgVGVjaG5vbG9naWVzMQ8wDQYDVQQLDAZQaG9uZXMxGDAWBgNVBAMMD0ludGVy
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: bWVkaWF0ZSBDQTAgFw0yNTA4MjcxMzM1MjZaGA8yMDU1MDgyMDEzMzUyNlowSzEL
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: MAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRQwEgYDVQQKDAtEaWdpdW0sIEluYzEZ
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: MBcGA1UEAwwQRGlnaXVtIEFwcHNlcnZlcjCCASIwDQYJKoZIhvcNAQEBBQAD': 503/bad base64 decode
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:  tsx0xac02b3b4  Failed to send Request msg MESSAGE/cseq=58566 (tdta0xac0348c4)! err=480900 (bad base64 decode)
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:     pjsua_im.h  Failed to deliver message 'ggEP
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: ADCCAQoCggEBALFFLzrxQxoNQt3rTsEUmr0RLGvmC79fmckXzYI7hBQ2j5gQtEEx
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: V8DysHX0+LSV8MtvH57TnzxugDM4LX+dOcgThqwq/yKEapIvsXz8m+1XEPkDA70/
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: 5dwWEWAVFt/SkIY/QcGnhixkjZJEskB0u4LAPPjgJ3A9tmmOtVSVO05SWWfySD/P
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: LtGKTEqWwq9DJw2plt6rStOlfxMInJctkDGyHlmFvurXciTdfYgJvnWIBJP1WIoG
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: LN8MnTSlO7eKOSLJe2sFU+7U9knidQk+mZtqxNB5qD3OtnB/Psq5uchdA+qmArhd
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: BIDokf7E1iavvwiRjdTVUpOmC/IhB9m5UW8CAwEAAaOCAQUwggEBMAkGA1UdEwQC
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: MAAwLgYJYIZIAYb4QgENBCEWHyJPcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: ZSIwHQYDVR0OBBYEFDI2/K/01lCPQnRjA0Swnlgb': 503/bad base64 decode
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:  tsx0xac05b374  Failed to send Request msg MESSAGE/cseq=63729 (tdta0xb4339b94)! err=480900 (bad base64 decode)
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:     pjsua_im.h  Failed to deliver message 'N70Y+3qBykFcBfqPOJg0j2b9+/gnZoYXoA7I2nwmRqpz
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: NJDQh9QgjOVyA3Lq4RKm9CjU4rSavdL5uuiKBhX+q7QWXowpA+eTkmFc210ZlBUw
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: c5ZncXoxAz9JZZLH0gMeXLBUZfo8/6lwXtl8s4JLt4nlgeKfSpsoX0EUbXMZ2IUS
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: X9CHmrnFf+c5gxkV/Y1w4wBWwOWjE8mzsW2g2fnGjBjggfh1TlgGG3sJm/Jpra67
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: Z2Yh4aQCuAw34AqmLbSQl4uKLLjYUpe8cVdSRLhIPe4qPHwoaBn+oy0YUe3JxJQI
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: Zz+BhwhcXw1fhkio6dgatwqx76qGmIrYgGnAe5wNOe6OFsciQKAtYSyVoG7go7v0
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: 9SiV/20FGM0MLAfuatxtIvIG2bFHwX892Jh05HdU5NDcfQotEmP81HhAmeDyJRKy
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: YHXTu5YDbMlcp5y8aqUJ2TATxPUYK/c+CbU/qtldMYHIexNjbMGcGOBAlAtMPmm7
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: ': 503/bad base64 decode
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:  tsx0xb4307e2c  Failed to send Request msg MESSAGE/cseq=22386 (tdta0xac054f0c)! err=480900 (bad base64 decode)
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:     pjsua_im.h  Failed to deliver message 'vuWYMIGkBgNVHSMEgZwwgZmA
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: FNDgqgzyHMNzrDa9BPNtgEpbpzzSoXqkeDB2MQswCQYDVQQGEwJVUzEQMA4GA1UE
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: CAwHQWxhYmFtYTETMBEGA1UEBwwKSHVudHN2aWxsZTEdMBsGA1UECgwUU2FuZ29t
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: YSBUZWNobm9sb2dpZXMxDzANBgNVBAsMBlBob25lczEQMA4GA1UEAwwHUm9vdCBD
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: QYIFLyA4uEYwDQYJKoZIhvcNAQEFBQADggIBAC6jAmRQ1wKC1wdZw3SE+cBF6dA+
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: XwJvrq45H6Hxjsb1AAqlUmQXceYZkoBAPtPR5laPU+qpjVeSbXN2aNF+ua6FSZ0s
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: RvIy8J5eMA3zDYruMXRsasaVUWjdYQBdY/X1AMRPgLri2igCWuo1wOhX881rE269
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: 9s7YfVeCSIL+SiNweVZL12kd0A48noflBGI2hCnv7hAq667aDeygIFWKo/KCbJlt
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: xF8XVo+hmUZBGfks7m/h': 503/bad base64 decode
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:  tsx0xac075eac  Failed to send Request msg MESSAGE/cseq=34755 (tdta0xac06ee7c)! err=480900 (bad base64 decode)
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject:     pjsua_im.h  Failed to deliver message 'glghkgBhvhCAQ0EIRYfIk9wZW5TU0wgR2VuZXJhdGVkIENl
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: cnRpZmljYXRlIjAdBgNVHQ4EFgQUyZKjxGp5tVD+WWuaDKmOPpcZqp0wegYDVR0j
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: BHMwcaFkpGIwYDELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRIwEAYDVQQHDAlT
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: YW4gRGllZ28xFTATBgNVBAoMDERpZ2l1bSwgSW5jLjEZMBcGA1UEAwwQRGlnaXVt
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: IEFwcHNlcnZlcoIJAMWafhc9U5+1MA0GCSqGSIb3DQEBBQUAA4GBABs6EOQtrWJw
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: 8H713AY2i2AktOt5ZqR7QWv3lwTOy94pzl7CvgFicSidJ9jysFzp+xHCjHXn/5Jq
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: JWMxQT3QC64zz7a9Us2aVzDB1b/A2zEYeT5Psyn5651FjaJGW5ROVFZHFd+Ab2b2
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: njTBwtzymKZUtzTcR1aywksAbyr1ckCg
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: -----END CERTIFICATE-----
2025-11-23T22:39:31+01:00 10.185.30.19 lisa: [  612]N/pjproject: ---': 503/bad base64 decode
35

Unfortunatley I leveraged Sangomas technical support and after a long while of production unit not being able to resolve the issue timely I just swapped to Yealink phones and EPM. I never did get the issue resolved.

36

You are not solo in this issue, if you dont use TLS it seems te work…. kind of.

EPM replies on you having parts of the phone registered in the Sangoma Cloud Portal as EPM (i think) makes calls to that.

The next thing is you need to make sure that your SSL and TLS certs are all good. There may be issues with certain versions.

Make sure your ports are double checks and communicating. (TCP pointing where you need). Yes TCP because UDP isnt encrypted.

Notes to Sangoma:

The lack of any ability to install cert updates post EPM and that EPM can’t update the phones and web portal locks out seems to be a big oversight. Web Access shouldnt be locked out ever unless I as a customer opted to do so. reall means that the phones aren’t locked to just FreePBX but also that in case of this exactly we can get better insights. .

I have 8 phones sitting as bricks in the back office because of this above bug……

37

Certificates of my domain are trusted and openssl/curl/browser confirm.

My understanding is that whe TLS is enabled everywhere FreePBX try to push a certificate to the phone via DPMA, a certificate not related to my domain and issued to Digium**. This exchange fails with bad base64 encoding but the phone store this corrupted certificate in its trust store.

At this point every attempt to establish a secure TLS channel fails becuase the trust store is corrupted, before the certificate of my domain is ever exchanged.

I installed a basic, minimal, fresh FreePBX machine in virtual hardware and the problem persist so in no way is related to my specific production PBX.

I think Sangoma should be aware of the issue if it was already discussed with you.

Current options are:

  • avoid TLS completely
  • skip certificate verification (in phone template), which is almost the same
  • use SIP-TLS with HTTP Provisioning and HTTP PhoneApps

HTTPS Provisioning alonge doesn’t works; but I’m pretty sure at some point in the past year was working.

38

You would think, but it was never resolved, not fully. I hope that this gets resolved properly for you. I would like to put to use the pile of quite expensive non refundable phones to use. Is Sangoma Technical Support working with you at least as well?

39

Did you manually download the latest firmware for the phone and install it by logging into the web gui of the phone? I’ve had some of the older S series that wouldn’t provision until the firmware was manually updated.

40

If you were asking to me yes; at the beginning firmware updating by EPM was not working and I had to manually update every phone. Now it’s working both for upgrade and to downgrade.

About the issue described, I tried to upgrade and downgrade, bot manually and by EPM with no success.

But…

41

A few days ago something unusual happened. For several days I had been relying on the workaround “skip TLS certificates verification”, but then suddenly all Sangoma phones became unable to provision or register over TLS, even with that flag still enabled in Endpoint Manager.

After some investigation I noticed that in “Asterisk SIP Settings” the TLS certificate selection had become blank. Following a couple of hours of rebuilding the configuration, toggling and restoring registration/provisioning protocols, and rebooting both phones and the PBX, the syslog of my test phone no longer showed the “bad base64 encoding” error. Instead, it reported “certificate installed successfully.” Remarkably, after several months of malfunction, the test phone could once again be provisioned via HTTPS and DPMA/TLS, and it registered over SIP‑TLS even with “skip TLS certificates validation” disabled.

Now it has been working correctly for quite a few days without any recurrence of the issue.

My explanation is this: the “spontaneous” resolution happened right after a TLS certificate renewal with the generation of a new keypair. In previous renewals since April 2025, the same keypair had apparently always been reused.

My current, limited, understanding is that the public key of the TLS certificate is sent over DPMA base64‑encoded. My guess is that the problem started when a specific private key was generated around April, producing a public key with a particular sequence of characters that triggered a bug in this process and raised the base64 encoding error we experienced multiple times.

Since the renewal with a fresh keypair, the problem has not reappeared. Hopefully Sangoma can fix this bug so that it won’t affect future renewals.