Yealink T5x Handsets No longer Auto-Provision or call RemotePB scripts via Authenticated HTTPS


I have a couple of PBXact v15 installations running Yealink T5x Handsets (FW: 96.85.x.x).

  • These handsets have always provisioned out of the box/from factory reset via Authenticated HTTPS (using Yealink redirection service) no problem.

  • These handsets have always called a custom Remote Phonebook script to show & enable dialling Contact manager entries via Authenticated HTTPS no problem.

Since sometime last week (I think), the both these ‘Authenticated HTTPS’ based communications seem to have stopped working. Nothing has changed with the general setup of these installations. I do check & apply any new PBXact System/Module updates quite regularly & I did do this sometime last week (which possibly stopped these functions working as they did previously).

If I specify both the HTTPS-based Provisioning URL & RemotePB script URL in a Web Browser, the PBXacts respond no problem, it just doesn’t do the same from the Yealink handsets themselves.

I have switched a single Yealink handset on BOTH installations to use ‘Authenticated HTTP’ & hey-presto, all is working again.

Does anyone know if something changed in a module update recently that could have broken the ‘Authenticated HTTPS’ communications between PBXact & Yealink handsets ?

PS. I have found some forum articles that suggest Authenticated HTTPS with Yealink handsets didn’t work previously, however, it’s always worked for me on these v15 installations (until now).

Some recent updates which ‘might’ be relevant;

Also for reference;


(Lorne Gaetz) #2

You’re using let’s encrypt? It’s probably related to the recent expiry of a root cert. Is there a phone firmware update to address it?


Hi Lorne,

Yes, I am using LE on both systems.

Actually, I believe even EPM lists an update to FW 96.86.x.x for those Yealink handsets.
I will install that & see if it restores ‘Authenticated HTTPS’ communications on those handsets/systems. I’ll post the outcome once I’ve tried it (probably tomorrow now as its 22:38 here in the uk).

(Jared Busch) #4

Yealink has not released any firmware to handle the LE issues.

On top of that, firmware in EPM is typically months behind anything Yealink releases.

(Jared Busch) #5

Umm @lgaetz, did Sangoma get specially released firmware? Because the last released public firmware is still the X.86.0.18 / X.86.0.23 bundle. FYI, that firmware is from July, even if the update date is newer.

And that firmware comes with a big warning that you can no longer roll back beyond them once you upgrade to them. Also, depending on what firmware you were on first, you can possibly not go directly to X.86.0.23.

(Lorne Gaetz) #6

Several Yealink models have been added in batches in the previous month’s, but I’m not aware of anything special about the firmware we’re publishing. @kgupta1 can you comment?

(Kapil Gupta) #7

Please ensure that your pbxact has the latest module for example sysadmin latest is v15.0.21.89.

Regarding Yealink firmware - Yes while adding new models , We have got the firmware list from Yealink for other models with URL to download the firmware and the same we have recently updated into the EPM. Please find below the latest firmware list from EPM.



VP-2009 Contact Yealink





Ok, so did some testing today using a single Yealink handset on the PBXact as detailed in my original post at the top of this thread;

Yealink T54W - FW: (Part of EPM Yealink FW v1.21)

  • Authenticated HTTPS --> Auto-Provision: Failed / RemotePB: Failed

  • Authenticated HTTP --> Auto-Provision: Success / RemotePB: Success

Yealink T54W - FW: (Part of EPM Yealink FW v1.22)

  • Authenticated HTTPS --> Auto-Provision: Success / RemotePB: Success

  • Authenticated HTTP --> Auto-Provision: Success / RemotePB: Success

The upshot is that the latest EPM supplied Yealink firmware seems to resolve the problem (for the T54W I tested at least).

I also have some Yealink DECT Handsets (W53H/W56H/W59R) connected to a W60B (using FW which exhibit the same issue. The W60B is listed in EPM, however, I don’t see any reference to it (or its Handsets) in the EPM Firmware package - Is this an oversight ?

(Jared Busch) #9

If it is an oversight, it has been for years. A one shot client I dealt with a few years ago added some of those and it was missing then. But they were decently new then, I just assumed they had not yet been agreed to by Yealink.


The Wiki says this;

but it’s unclear if/how that relates to Firmware being included within the EPM Firmware Package.

I realise I can download direct from Yealink, however, as you alluded previously, there does appear to be some version numbering differences between what the EPM FW Package contains & what’s on the Yealink support page. From my testing above, it appears I need FW xx.86.x.xx for all Yealink handset models (& the W60B only has xx.85.x.xx available currently).

So just to clarify, is the general consensus that this issue relates to an invalid/expired LE certificate somewhere within their chain, & if so, would the problem go away if I used a commercial certificate from another provider (eg. GoDaddy, SSL247 etc.) ?

AND, does is not seem feasible that LE are likely to fix this invalid/expired certificate in the near future (even though that’s no help if all these handsets have issues in the meantime) ??

(Jared Busch) #11

well it is my assumption. I dunno about general consensus.

Almost certainly.

I’m leaning to no.

(Philip Young) #12

This seems to still be an issue with discontinued Yealink Phones such as T19P E2 or W60B. Yealink hasn’t made a new firmware version for these models for quite some time and now if one of these is reset to default factory settings it won’t communicate with the Endpoint Manager.


That’s correct - I’ve had to manually update the firmware in each of the T54W & T57W handsets to xx.86.x.xx which seems to resolve the problem.

For the W60B’s, I’ve had to change their configs to use ‘Authenticated HTTP’ (instead of HTTPS) for provisioning & Remote PB URLs, until either the invalid/expired LE Certificate is resolved and/or a v86 firmware is available for that model (These devices are on an internal Subnet/Site-to-Site VPN tunnel, so HTTP is not a deal-breaker for me).

I guess if these options don’t work for you, another would be to use an alternative Certificate provider.

(system) closed #14

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.