Not saying it’s not our problem. What I am saying is I don’t know what needs to be fixed. So yeah it is our problem but the solution is unknown and we aren’t actively investigating.
Looks like I posted my first issue on August 17, so if that is considered an early upgrade, then yeah.
Any easy way to clean up all el6 based rpms that might be left?
Edit: Found another post about UCP data and I stated I did it on Friday August 11.
I am more than willing to continue investigating,but I fear it is beyond my skill at this point.
I am going to spin up another new 14 system later tonight or tomorrow for further testing.
1 Like
@tm1000, I just talked to another FreePBX 14 user that has T46G and they work perfectly over HTTPS with a GoDaddy certificate for his site.
So something in the LE cert process I would guess. I don’t have cash to buy a cert just for testing a GoDaddy Cert on my system though.
Can anyone shoot me a link to where the LE process is in the code so I can poke at things?
Code for LE is the same between 13.0 and 14.0
@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… 66.82.0.30 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.
https://issues.freepbx.org/browse/FREEPBX-21011
1 Like
this also affects FreePBX 15.
- I just performed a new install of FreepBX 15
- obtained a LE cert within certman 15.0.18
- set cert as active in apache
- updated by DHCP to point to the new PBX for boot files
- defaulted a Yealink T42G
This is all the shows up in the PBX log. Same as in FreePBX 14. HTTP error 408.
[jbusch@freepbx tftpboot]$ sudo tail /var/log/httpd/access_log
64.53.199.99 - - [17/Jan/2020:04:15:41 +0000] "GET /admin/ajax.php?module=search&command=global HTTP/1.1" 200 9427 "https://pbx15.bundystl.com/admin/config.php?display=sipsettings" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0"
64.53.199.99 - - [17/Jan/2020:04:15:56 +0000] "POST /admin/config.php?display=sipsettings HTTP/1.1" 200 135281 "https://pbx15.bundystl.com/admin/config.php?display=sipsettings" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0"
64.53.199.99 - - [17/Jan/2020:04:15:56 +0000] "GET /admin/assets/less/cache/lessphp_9e018ea8f09ca04d937648f01e33eb196b09ae1d.css HTTP/1.1" 200 87893 "https://pbx15.bundystl.com/admin/config.php?display=sipsettings" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0"
64.53.199.99 - - [17/Jan/2020:04:15:57 +0000] "GET /admin/ajax.php?module=search&command=global HTTP/1.1" 200 9427 "https://pbx15.bundystl.com/admin/config.php?display=sipsettings" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0"
64.53.199.99 - - [17/Jan/2020:04:15:59 +0000] "POST /admin/ajax.php?command=reload HTTP/1.1" 200 93 "https://pbx15.bundystl.com/admin/config.php?display=sipsettings" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0"
64.53.199.99 - - [17/Jan/2020:04:25:35 +0000] "-" 408 - "-" "-"
64.53.199.99 - - [17/Jan/2020:04:26:23 +0000] "-" 408 - "-" "-"
64.53.199.99 - - [17/Jan/2020:04:26:55 +0000] "-" 408 - "-" "-"
64.53.199.99 - - [17/Jan/2020:04:27:23 +0000] "-" 408 - "-" "-"
64.53.199.99 - - [17/Jan/2020:04:32:06 +0000] "-" 408 - "-" "-"
64.53.199.99 - - [17/Jan/2020:04:32:35 +0000] "-" 408 - "-" "-"
64.53.199.99 - - [17/Jan/2020:04:33:04 +0000] "-" 408 - "-" "-"
64.53.199.99 - - [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 tpbx15.bundystl.com --pre-hook "systemctl stop httpd" --post-hook "systemctl start httpd"
sudo cp /etc/letsencrypt/live/tpbx15.bundystl.com/chain.pem /etc/asterisk/keys/tpbx15.bundystl.com-ca-bundle.crt
sudo cp /etc/letsencrypt/live/tpbx15.bundystl.com/privkey.pem /etc/asterisk/keys/tpbx15.bundystl.com.key
sudo cp /etc/letsencrypt/live/tpbx15.bundystl.com/cert.pem /etc/asterisk/keys/tpbx15.bundystl.com.crt
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.
[jbusch@freepbx ~]$ sudo tail /var/log/httpd/access_log -f
64.53.199.99 - - [17/Jan/2020:04:53:00 +0000] "GET /001565649346.boot HTTP/1.1" 401 381 "-" "Yealink SIP-T46G 28.83.0.120 00:15:65:64:93:46"
64.53.199.99 - XXXXXXXX [17/Jan/2020:04:53:00 +0000] "GET /001565649346.boot HTTP/1.1" 404 215 "-" "Yealink SIP-T46G 28.83.0.120 00:15:65:64:93:46"
64.53.199.99 - - [17/Jan/2020:04:53:04 +0000] "GET /y000000000000.boot HTTP/1.1" 401 381 "-" "Yealink SIP-T46G 28.83.0.120 00:15:65:64:93:46"
64.53.199.99 - XXXXXXXX [17/Jan/2020:04:53:04 +0000] "GET /y000000000000.boot HTTP/1.1" 404 216 "-" "Yealink SIP-T46G 28.83.0.120 00:15:65:64:93:46"
64.53.199.99 - - [17/Jan/2020:04:53:08 +0000] "GET /y000000000028.cfg HTTP/1.1" 401 381 "-" "Yealink SIP-T46G 28.83.0.120 00:15:65:64:93:46"
64.53.199.99 - XXXXXXXX [17/Jan/2020:04:53:08 +0000] "GET /y000000000028.cfg HTTP/1.1" 200 7974 "-" "Yealink SIP-T46G 28.83.0.120 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:/CN=tpbx15.bundystl.com
<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:/CN=tpbx15.bundystl.com
<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:/CN=tpbx15.bundystl.com
<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/tpbx15.bundystl.com-ca-bundle.crt /var/www/html/custom/tpbx15.bundystl.com-ca-bundle.crt
Then I setup the config file for the phone to have this.
static.trusted_certificates.url = https://tpbx15.bundystl.com/custom/tpbx15.bundystl.com-ca-bundle.crt
static.security.trust_certificates = 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:/CN=tpbx15.bundystl.com
<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
http://support.yealink.com/faq/faqInfo?id=13
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.