Yealink T4XG phones will not autoprovision over HTTPS with FreePBX 14

@tm1000 Thanks for showing me where it is.

I just finished installing a brand new FreePBX 14 system and setting up a LE cert. I got the same result.

So since the FreePBX code is the same between 13 and 14, then the difference has to exist in the Lescript or openssl setup that is installed.

Lescript is the same between 13 and 14 (its a composer library).

Now openssl on the other hand, yes. Or even apache itself.

I found a GoDaddy cert with a SAN that was not currently in use and added it to the brand new FreePBX 14 instance I just made for testing and changed it to the active cert. I updated the phone to point to that DNS name and the phone immediately provisioned.

So this confirms that other people that say it works must not be using the LE cert.

I also had a chance to test a T42S phone and a T46S phone and those work perfectly with both FreePBX 13 and FreePBX 14 with a Let’s Encrypt cert.

This really narrows it to the T4XG line being the problem in my opinion.

I have updated my post over on the Yealink community saying as much and I hope that something will come of it.

1 Like

Looks like I have the same issue with the Yealink phone T48S Phone Apps take forever to initiate 24 seconds plus over SSL (https)… work perfectly over non SSL phoneapps (http) running latest firmware… to use the opus codec…

Im on PBXACT 14

Certain versions of the T4XS firmware also failed over the last year+.

The last 3 versions are all working fine

I was testing some things with Certificate Manager from another thread and I have found that a LE cert installed via Certbot on a standard FreePBX 14 / SNG7 system works just fine with all versions of Yealink phones and firmware that I had easily available for testing.

To me, this brings it back to something in the Sangoma implementation of LE is different. I mean it works fine in all the browsers, but the phone refuses to talk to it.

But a Certbot generated cert does work? What is the difference? Certbot is known, trusted, and extremely widely used. Sangoma’s implementation of ACME? Who knows? I’m not qualified to answer that. Just looking from the outside in.

As of certman 14.0.6 on FreePBX 14, the built in LE certificate process still does not let the T4XG series phones (firmware XX.83.0.120) work with TLS.

Do you have a bug report on the Issue Tracker for this? Just curious-- would be willing to vote/watch it for higher visibility.

No because it was clearly stated in this thread that they did not care to look at it.

Of course those people are no longer with Sangoma, so I guess it may be worth the time to do it now.

Edit: Ticket opened.

1 Like

this also affects FreePBX 15.

  1. I just performed a new install of FreepBX 15
  2. obtained a LE cert within certman 15.0.18
  3. set cert as active in apache
  4. updated by DHCP to point to the new PBX for boot files
  5. defaulted a Yealink T42G

This is all the shows up in the PBX log. Same as in FreePBX 14. HTTP error 408.

[[email protected] tftpboot]$ sudo tail /var/log/httpd/access_log - - [17/Jan/2020:04:15:41 +0000] "GET /admin/ajax.php?module=search&command=global HTTP/1.1" 200 9427 "" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0" - - [17/Jan/2020:04:15:56 +0000] "POST /admin/config.php?display=sipsettings HTTP/1.1" 200 135281 "" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0" - - [17/Jan/2020:04:15:56 +0000] "GET /admin/assets/less/cache/lessphp_9e018ea8f09ca04d937648f01e33eb196b09ae1d.css HTTP/1.1" 200 87893 "" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0" - - [17/Jan/2020:04:15:57 +0000] "GET /admin/ajax.php?module=search&command=global HTTP/1.1" 200 9427 "" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0" - - [17/Jan/2020:04:15:59 +0000] "POST /admin/ajax.php?command=reload HTTP/1.1" 200 93 "" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0" - - [17/Jan/2020:04:25:35 +0000] "-" 408 - "-" "-" - - [17/Jan/2020:04:26:23 +0000] "-" 408 - "-" "-" - - [17/Jan/2020:04:26:55 +0000] "-" 408 - "-" "-" - - [17/Jan/2020:04:27:23 +0000] "-" 408 - "-" "-" - - [17/Jan/2020:04:32:06 +0000] "-" 408 - "-" "-" - - [17/Jan/2020:04:32:35 +0000] "-" 408 - "-" "-" - - [17/Jan/2020:04:33:04 +0000] "-" 408 - "-" "-" - - [17/Jan/2020:04:33:34 +0000] "-" 408 - "-" "-"

i created a certbot certificate in addition to the certman cert and it works perfectly.

sudo yum install certbot -y
sudo certbot certonly --agree-tos --non-interactive --standalone --email [email protected] --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 fwconwole certificates --import

Then I went into SysAdmin and set the tpbx15 cert active.

Then I updated my DHCP and rebooted the phone.

You can clearly see the phone request, get a 401 and then request with the creds and get a 200 response. XXXXXXX = masked username from the Provisioning protocols.

[[email protected] ~]$ sudo tail /var/log/httpd/access_log -f - - [17/Jan/2020:04:53:00 +0000] "GET /001565649346.boot HTTP/1.1" 401 381 "-" "Yealink SIP-T46G 00:15:65:64:93:46" - XXXXXXXX [17/Jan/2020:04:53:00 +0000] "GET /001565649346.boot HTTP/1.1" 404 215 "-" "Yealink SIP-T46G 00:15:65:64:93:46" - - [17/Jan/2020:04:53:04 +0000] "GET /y000000000000.boot HTTP/1.1" 401 381 "-" "Yealink SIP-T46G 00:15:65:64:93:46" - XXXXXXXX [17/Jan/2020:04:53:04 +0000] "GET /y000000000000.boot HTTP/1.1" 404 216 "-" "Yealink SIP-T46G 00:15:65:64:93:46" - - [17/Jan/2020:04:53:08 +0000] "GET /y000000000028.cfg HTTP/1.1" 401 381 "-" "Yealink SIP-T46G 00:15:65:64:93:46" - XXXXXXXX [17/Jan/2020:04:53:08 +0000] "GET /y000000000028.cfg HTTP/1.1" 200 7974 "-" "Yealink SIP-T46G 00:15:65:64:93:46"

So I did not find this until I tested with the certbot cert. in the Yealink’s syslog (level 3 dump), you eventually see this in the log. Looks like it does not trust the X3 cert authority from LE, but as previously shown, it still connects to the web server. Of note, it will not register in this state if you enable TLS for registration in PJSIP.

<131>Jan 16 23:18:50 lbt [1267]: BADT<3+error > Can not find adapter, please plug up.
<131>Jan 16 23:18:55 sua [1286]: NET <3+error > [255] verify error:num=20:unable to get local issuer certificate:depth=0:/
<131>Jan 16 23:18:55 sua [1286]: NET <3+error > [255] X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
<131>Jan 16 23:18:55 sua [1286]: NET <3+error > [255] verify error:num=27:certificate not trusted:depth=0:/
<131>Jan 16 23:18:55 sua [1286]: NET <3+error > [255] X509_V_ERR_CERT_UNTRUSTED issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
<131>Jan 16 23:18:55 sua [1286]: NET <3+error > [255] verify error:num=21:unable to verify the first certificate:depth=0:/
<131>Jan 16 23:18:55 sua [1286]: NET <3+error > [255] X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
<131>Jan 16 23:18:56 sua [1286]: NET <3+error > [255] Failed to verify remote certificate
<131>Jan 16 23:18:56 GUI [1267:1267]: CUIT<3+error > 336.988.442:check passwd err
<131>Jan 16 23:18:57 GUI [1267:1303]: WIND<3+error > 337.180.857:[DCMN]Recode is 404, Request err.
<131>Jan 16 23:18:57 GUI [1267:1303]: WIND<3+error > 337.192.858:[DCMN]download common error, errcode:404.

But even this failure is not in the syslog for the certman generated certificate. Instead we get an error that the URL is empty. So obviously, something with the certificate is failing to be read, since it has no problem reading an LE cert from the X3 authority.

<131>Jan 17 13:37:49 lbt [1425]: BADT<3+error > Can not find adapter, please plug up.
<131>Jan 17 13:37:55 ATP [1438]: ATP <3+error > Get static config url is empty

Now, as mentioned, the phone pulls the config and other web related stuff but does not register. Wll let’s see if we can make it trust things. First if you disable cert checking it will register. This did not help with the certman cert though, and is not something I would ever recommend as a long term solution.

Turning that setting back on and then uploading the CA bundle into the phone made the error in the phone sys.log go away and let the phone register. Again, this made no difference to the certman cert. Only made the Certbot cert work fully.

You can load it in the config like this. I could have put it in the tftpboot folder also, but I have that folder under version control with git so I didn’t want a cert that changes randomly in there. Instead I symlinked it from keys, (I already have stuff in custom).

sudo -u asterisk ln -s /etc/asterisk/keys/ /var/www/html/custom/

Then I setup the config file for the phone to have this.

static.trusted_certificates.url = = 1

After the phone reboots and gets the cert, it willreboot again.
But then the sys.log shows this.

<131>Jan 17 00:58:53 lbt [1277]: BADT<3+error > Can not find adapter, please plug up.
<131>Jan 17 00:58:58 sua [1296]: NET <3+error > [255] depth=2:/O=Digital Signature Trust Co./CN=DST Root CA X3
<131>Jan 17 00:58:58 sua [1296]: NET <3+error > [255] depth=1:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
<131>Jan 17 00:58:58 sua [1296]: NET <3+error > [255] depth=0:/
<131>Jan 17 00:58:59 GUI [1277:1315]: WIND<3+error > 339.658.335:[DCMN]Recode is 404, Request err.
<131>Jan 17 00:58:59 GUI [1277:1315]: WIND<3+error > 339.693.589:[DCMN]download common error, errcode:404.
<131>Jan 17 00:59:00 GUI [1277:1277]: CUIT<3+error > 340.061.047:check passwd err

moral of this story for me was to disable ‘only accept trusted certificates’ , its still https, but yealinks don’t have ‘certbot’ trust baked in and its not easy to add it.

1 Like

They support X2. And it is simple to add X3 as I noted.

And while it is 100% true that they need to add more support, it is also100% true that Sangoma is doing something different.

It is something that changed between FreePBX 13 and 14. The commit history says it was not the tool, so that means some dependency they use in SNG7 is different than CentOS 6 was.

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.

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

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