Just touched a Grandstream Ht704 yesterday for the first time in a while in order to update firmware.
I dropped the new file onto the server, updated the config file, and rebooted the unit. It did not upgrade.
Looked in the Apache log and there is was a error 408.
Testing proved out the same resolution.
Booger - I am having this problem also - modifying that file does indeed install a certificate that the Yealink’s will then provision to - but FreePBX complains that the file is tampered with - which does not look good to the casual observer (customer) - have you had any luck with Yealink Tech Support - seems like they would like to fix this since bigger-key SSL Certs are theoretically more secure than smaller-key ones.
I have Grandsteams at this customer also - I wonder if I am going to have the same problem with them (GXP2135’s and 2170’s) - I really want to do all provisioning HTTPS to minimize the attack-surface of the boxes.
This is frustrating - there has to be a ton of T4X’s our there that this affects.
You can revert the change after getting the good certificate. Future renewals should still be fine because a renew does not regen the key.
Cool - That is what I did to get the working cert and then reverted the file so it quit complaining - I guess that is an OK work-around until somebody (Probably Yealink) fixes the problem. I was worried that I would have to leave that change in place because Let’s Encrypt only gens 90-Day Certs - but if it’s a one-time thing that is fine.
Yealink is not going to fix something that is not likely their problem.
Also they will not fix it because the affected line of phones are EoL.
Another option would be to self-sign the module, but probably not worth the trouble as a one-off if you don;t already have signing set up.
But this is a good reminder to get my re-work of the module PR ready. I’ve been sitting on it way too long. A lot of good stuff in it: acme.sh backed and most if the goodies that come with it - dns and tls-alpn challenges, alternate cert authorities, alternate chains. specifying key length/type, etc.
I am battling this problem.
I have tried changing the private key bit length to 2048 as suggested, and rebuilt my cert but I still get the 408 error when the phone tries to provision.
any further suggestions of what to try?
Everything above was before the root cert expiry.
Now, you have to disable trusted certs. These models will never get a firmware update with new root trusts.
You seem to have. I would load the CA chain manually into the phone on that screen and test again.
You can find that here:
/etc/asterisk/keys/YOURFQDN-ca-bundle.crt
Load the CA chain as mentioned above and also try setting CA certificates as Custom certificate instead of All certificates. That is what helped me.
@sorvani Thank you for battling this for … years. I had an issue come up where soft phones no longer registered to pjsip over tls using certman managed letsencrypt certs but if I did my own thing with acme.sh or straight certbot they worked fine.
I found your thread here and figured I might try
sed -i 's/4096/2048/g' /var/www/html/admin/modules/certman/vendor/analogic/lescript/Lescript.php
just to see if it makes any difference and it did!
I just want to add my test results. I have a Yealink SIP-T46U on newer than latest firmware (somehow), Firmware Version 108.86.0.75 Hardware Version 108.0.0.0.1.1.0.
I was unable to connect over TLS with my LetsEncrypt certificate, and I tried everything including uploading the entire certificate chain and disabling check certificate on the server side as well as the phone side. Nothing worked. I got a 90 day trial certificate from GoGetSSL, then changed the cert for PJSIP to that one, and after restarting asterisk (you can’t just apply/reload, you have to restart), the phone registered. I did a factory reset of the phone and it still auto-provisioned and registered. I confirmed it does not have any of the manually assigned certificates saved. I then did the edit above, changing the Lescript.php from 4096 to 2048, deleted my old letsencrypt certificate, regenerated, then went into PJSIP settings and selected the cert and restarted asterisk, then restarted the phone for good measure. It connected just fine.
It seems the issue is the 4096 bit length. I did see a post somewhere that indicated that turning on header compression resolved the issue but I can’t find that in my history anymore. The big problem is since the php file is altered, now there’s an ugly warning at the top of each page indicating a file has been changed. I plan to make a post on the Yealink forum since this is a Yealink issue, they have a 24 hour waiting period before I can do so though.
I will note that for the entire 9 year history of Lescript.php, the key length has been 4096, so I am not sure what happened. There’s no way to file issues against the code and it is used as a vendor file (I don’t know the appropriate term anymore, we used to call them libraries?) so the best solution is to have it become a variable upstream and add an option to the interface. I would do a fork and pull request myself but it feels like that’s beyond my abilities.