Yealink T4XG phones will not autoprovision over HTTPS with FreePBX 14

Tags: #<Tag:0x00007f702bc5ada8> #<Tag:0x00007f702bc5ab28>

(Andrew Nagy) #61

Clarification. It was not said the way you interpreted it.

This is what was said.

And this was previously addressed in that was the fix for FreePBX 13 which shows that we did look into it. I would link the new ticket to the old one even though it’s not a duplicate it is related.

Since you seem to know PHP/coding my advice would be:

  1. Go clone the git repo that certman uses and see if the certs you get from that library work out of the box:
  2. In certman itself it combines the X3 cert back into any lets encrypt certificate: I would say it’s probably a good idea to look at this area of the code in general as this may be what is causing the issues.


SSL/TLS testing tools complain when the root is sent along with the rest of the intermediate chain. Maybe the Yealink client doesn’t want it, either.

(Andrew Nagy) #63

FREEPBX-14631 was created by @matthias123 to specifically address missing X3 certificates on Yealink phones. Sooooooooo I dunno! Used to work! But removing it from the code above and seeing if it works in 14 would be a good step

(system) closed #64

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

(Joshua C. Colp) opened #65

(Joshua C. Colp) #66

@sorvani Requested action completed successfully.

(Jared Busch) #67

I wanted to open this thread back up because the issue still exists with FreePBX 15 and I think it is only possibly related to the thread that we were discussing it again.

(Jared Busch) #68

@jerrm Moving the conversation here.

Spun up a new FreePBX 15 system on Vultr.
I pointed and to it.
I created an LE cert within cert manager on

I installed certbot and created a cert on and imported that into cert manager with fwconsole.

sudo certbot certonly --agree-tos --non-interactive --standalone --email --no-eff-email --preferred-challenges http --domains --pre-hook "systemctl stop httpd" --post-hook "systemctl start httpd" 
sudo cp /etc/letsencrypt/live/ /etc/asterisk/keys/
sudo cp /etc/letsencrypt/live/ /etc/asterisk/keys/
sudo cp /etc/letsencrypt/live/ /etc/asterisk/keys/
sudo fwconsole certificates --import


I set as the active cert in Sysadmin.

I set my DHCP option to https on

then defaulted the phone. Here we go. nothing but error 408.

I then switch the cert in sysadmin to demo2

Before I can even tell the phone to look for demo2, it pulls the config, as it was still retrying.

I did then also try to remove the chain. I deleted the cert, ran this.

sudo sed -i 's/4096/2048/g' /var/www/html/admin/modules/certman/vendor/analogic/lescript/Lescript.php

then I made a new cert on
I set the system back to and error 408 again.


Did you also try the second hack to prevent adding the cross-signed root to the chain?

sed  -i 's|$bundle = $b|//$bundle = $b|g' /var/www/html/admin/modules/certman/Certman.class.php

(Jared Busch) #70

copied the wrong thing from the other thread. I only tried the bundle change. not the key length change. My bad, it was 1am :stuck_out_tongue:

Let me also make the key length change and report back.

(Jared Busch) #71

Ran both anyway. was faster than looking :slight_smile:


Forced the update

Reset the DHCP server.

And defaulted the phone.

waiting… T42G series reboots slow on default.
There we are.

Continually retrying.

Updated back to demo2


Unfortunately, it looks like “–updateall” won’t change the key size. Confirm the current cert with:

openssl rsa -in /etc/asterisk/keys/ -text | grep Private-Key
openssl x509  -noout -text -in /etc/asterisk/keys/ | grep Public-Key

If they’re not a 2048 key size, best to delete and start over. To make 100% sure nothing gets picked up from any straggling config, use a new hostname.

I looked at the actual CSR’s generated by both and there are some other differences.

If a fresh cert with these changes doesn’t fix, I’ll start hacking to make the CSRs match as a debugging process. I’d like to know exactly what the problem is. I don’t see Sangoma actually making changes to Lescript.php. However, if they accept my version of the module, I can make sure it has appropriate options to make it work.

(Jared Busch) #73

That located that part of the problem.

A clean test shows that changing the keysize is all that is needed to make this work.

Edit: Destroying the VM and doing it again on a new FQDN to super verify.

(Jared Busch) #74

But, going back to the original issue from 3.5 years ago, this makes no sense as the “only” problem.

Because the keysize was 4096 in FreePBX 13 also. Yet, it worked just fine there.

I’m not desperate to solve that issue, I have no active clients on FreePBX 13 anymore.

But did want to point it out.


Are we sure it wasn’t the cross-signed root? I think you had applied both hacks.

(Jared Busch) #76

I reverted with

fwconsole ma refreshsignatures
fwconsole reload

Then only applied the keysize change and issued a new certificate.
But like I said I am spinning up a new instance and using a new FQDN to validate.

Because I never trust myself on the first go after this many trial runs.

(Jared Busch) #77

This morning, I am :stuck_out_tongue:

Clean install on a new FQDN. I only applied the root cert tweak

sed  -i 's|$bundle = $b|//$bundle = $b|g' /var/www/html/admin/modules/certman/Certman.class.php

Error 408, no go.

Reverted the snapshot and only applied the key size change.

sed -i 's/4096/2048/g' /var/www/html/admin/modules/certman/vendor/analogic/lescript/Lescript.php

The device will pull the config.


Good to know - already defaults to a 2kbit key.

I had considered whether I should use 4kbit as the module’s default to maintain consistency with the current module (even if I don’t think there is much value in 4k over 2k)… With this confirmed, I will make 2k the revised module’s default.

(Jared Busch) #79

Sounds like a plan to me.

And just a summary for anyone that doesn’t read the entire thread, as far as I can tell, FreePBX 13 used the 4k key, and everything worked fine.

At the time of the OP (3.5 years ago now), I had both a FreepBX 13 VM and a FreePBX 14 VM setup for testing.

Using the built in lescript process worked for FreepBX 13 (CentOS 6) and not on FreePBX 14 (Sangoma 7).

I gave up looking and @tonyclewis obviously didn’t care.
I just assumed that it had to be something in openssl and worked around it by using certbot and manually moving my cert in with a posthook.


Doesn’t make sense to me either.

There have been some updates to the Lescript.php library along the way, but from a quick glance at the source, they were always using 4096bit private keys.

The process is pretty simple - generate a key, generate CSR, send to LE, get a cert back. The only “altering” FreePBX does to the LE cert is appending the cross signed to the chain file. The only thing that seems relevant in the current CSR is the key size. From a quick review of the commits, nothing jumps out as a relevant change to the CSR. Maybe the move from acmev1 to acmev2 protocol in Nov 2019?

I’d be curious to know where the fault is/was, but can’t take the time to look that far back if we have a solution to move forward.