Yealink T4XG phones will not autoprovision over HTTPS with FreePBX 14

tm1000 · January 17, 2020, 6:24pm

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

This is what was said.

And this was previously addressed in [FREEPBX-14631] Add Cross signed IdenTrust Cert to certificate.pem - Sangoma Issue Tracker 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:

Go clone the git repo that certman uses and see if the certs you get from that library work out of the box: GitHub - analogic/lescript: Simplified PHP ACME client
In certman itself it combines the X3 cert back into any lets encrypt certificate: certman/Certman.class.php at release/14.0 · FreePBX/certman · GitHub. 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.

billsimon · January 17, 2020, 8:17pm

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.

tm1000 · January 17, 2020, 11:35pm

FREEPBX-14631 was created by @matthias1232 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 · January 31, 2020, 11:35pm

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

jcolp · February 12, 2021, 3:29pm

@sorvani Requested action completed successfully.

sorvani · February 12, 2021, 3:34pm

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.

sorvani · February 12, 2021, 3:42pm

@jerrm Moving the conversation here.

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

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

sudo certbot certonly --agree-tos --non-interactive --standalone --email [email protected] --no-eff-email --preferred-challenges http --domains demo2.bundystl.com --pre-hook "systemctl stop httpd" --post-hook "systemctl start httpd" 
sudo cp /etc/letsencrypt/live/demo2.bundystl.com/chain.pem /etc/asterisk/keys/demo2.bundystl.com-ca-bundle.crt
sudo cp /etc/letsencrypt/live/demo2.bundystl.com/privkey.pem /etc/asterisk/keys/demo2.bundystl.com.key
sudo cp /etc/letsencrypt/live/demo2.bundystl.com/cert.pem /etc/asterisk/keys/demo2.bundystl.com.crt
sudo fwconsole certificates --import

I set demo.bundystl.com as the active cert in Sysadmin.

I set my DHCP option to https on demo.bundystl.com

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 demo.bundystl.com 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 demo.bundystl.com
I set the system back to demo.bundystl.com and error 408 again.

jerrm · February 12, 2021, 3:56pm

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

sorvani · February 12, 2021, 3:57pm

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

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

sorvani · February 12, 2021, 4:04pm

Ran both anyway. was faster than looking

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

jerrm · February 12, 2021, 6:00pm

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

openssl rsa -in /etc/asterisk/keys/demo.bundystl.com/private.pem -text | grep Private-Key
openssl x509  -noout -text -in /etc/asterisk/keys/demo.bundystl.com/cert.pem | 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 acme.sh version of the module, I can make sure it has appropriate options to make it work.

sorvani · February 12, 2021, 7:19pm

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.

sorvani · February 12, 2021, 7:42pm

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.

jerrm · February 12, 2021, 7:54pm

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

sorvani · February 12, 2021, 8:17pm

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.

sorvani · February 15, 2021, 5:13pm

This morning, I am

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.

jerrm · February 17, 2021, 3:33pm

Good to know - acme.sh 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.

sorvani · February 17, 2021, 3:38pm

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.

jerrm · February 17, 2021, 4:22pm

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.