SSL Issue with Yealink Phones

[IZT_crobinson]

Hello,

We host and manage multiple PBX's and we have Site to Site VPN's setup. However, there is one customer coming online in which 2 phones will be set up via STUN. The first issue we ran into was that RPS for the Yealink T46S would not work. We tried to manually provision with the URL given by 3CX.

I thought it was the SSL certificate so we got a COMODO SSL Certificate (Approved by Yealink since V81), this still didn't work.

I took some PCAP's and this is what I have:



I'm not an expert at this or anything but the last one before the Rest (Level: Fata, Description: Unknown CA) stuck out to me. Any insight would be helpful.

So with this, what I did was download the two config files 3CX has as /provisioning/RANDOM/y000000000066.cfg and /provisioning/RANDOM/PHONEMAC.cfg

I spun up a web server with the SAME CERTIFICATE, uploaded the two .cfg files, and pointed the phone there. To my suprise, it provisioned correctly. Now it set the phone to the 3CX provisioning link and I can't get it to provision for the life of me. I believe this has something to do with Nginx, but I tried enabling ciphers, TLS version, etc, but I don't know what the difference is.

Phone: Yealink T46S
Firmware: 66.85.0.5
Hardware: 66.0.0.128.0.0.16

3CX: Hosted with custom FQDN
Version: 16.0.5.612

I don't know if anyone else has had issues but on all of out PBX's we can't remote provision. Once provisioned calling works, so it's not a firewall issues (everything is routed on our VPC, and like I said calling works fine, and no SIP ALG either)

Edit 1: The web server I spun up does not work for provisioning, so I believe it is a Yealink issue. Viewing the site from a web browser works, and if disabling "Only Accept Trusted Certificates" it works too.

Local Log has a log of these entries (where it fails to download config):

<131>Jun  9 16:21:16  ATP [826.848]: DURL<3+error > [DCMN]download common error, errcode:60.
<131>Jun  9 16:21:16  ATP [826.848]: ATP <3+error > https to file failed, code = -160, msg = , retry = 1

Any help is much appreciated

 

[Saqqara]

I am guessing you can access the management console, web client without any ssl certificate issues.

If you disable the SSL checking on the phone, does this work ? Within the phone web frontend - Security - Trusted Certificates - Disable 'Only Accept Trusted Certificates'

 

[IZT_crobinson]

@Saqqara Yes, everything works in the browser (no immediate erros, paths all look good). Disabling Only Accept Trusted Certificates works, however once it is provisioned it gets reset (that's what we usually do).

I also get this in the local log:

131>Jun  9 14:04:44  WEB [905:905]: WEB <3+error > 684.590.578:Send msg : [DONOW:NULL] [app_vpPhone], 0x60d03, 0, 1, , 5000
<131>Jun  9 14:04:44  WEB [905:905]: WEB <3+error > 684.591.510:CallDskMsgTimeoutEx [0x60d03] lret[0]
<131>Jun  9 14:04:48  WEB [905:917]: WEB <3+error > 688.115.672:Send msg : [DONOW:NULL] [app_vpPhone], 0x60d03, 0, 1, , 5000
<131>Jun  9 14:04:48  WEB [905:917]: WEB <3+error > 688.116.498:CallDskMsgTimeoutEx [0x60d03] lret[0]
<131>Jun  9 14:04:48  ATP [742.764]: DURL<3+error > [DCMN]download common error, errcode:60.
<131>Jun  9 14:04:48  ATP [742.764]: ATP <3+error > https to file failed, code = -160, msg = , retry = 1
<131>Jun  9 14:04:48  ATP [742.764]: DURL<3+error > [DCMN]download common error, errcode:60.
<131>Jun  9 14:04:48  ATP [742.764]: ATP <3+error > https to file failed, code = -160, msg = , retry = 1
<131>Jun  9 14:04:48  ATP [742.764]: DURL<3+error > [DCMN]download common error, errcode:60.
<131>Jun  9 14:04:48  ATP [742.764]: ATP <3+error > https to file failed, code = -160, msg = , retry = 1
<131>Jun  9 14:04:48  ATP [742.764]: DURL<3+error > [DCMN]download common error, errcode:60.
<131>Jun  9 14:04:48  ATP [742.764]: ATP <3+error > https to file failed, code = -160, msg = , retry = 1
<131>Jun  9 14:04:59  WEB [905:905]: WEB <3+error > 699.898.404:[DCMN]Bio_new_file error filename
<131>Jun  9 14:04:59  WEB [905:905]: WEB <3+error > 699.898.803:Error : get server certs info error! [-2]
<131>Jun  9 14:07:19  WEB [905:905]: WEB <3+error > 839.332.107:Send msg : [DONOW:NULL] [app_vpPhone], 0x60d03, 0, 1, , 5000
<131>Jun  9 14:07:19  WEB [905:905]: WEB <3+error > 839.332.883:CallDskMsgTimeoutEx [0x60d03] lret[0]
<128>Jun  9 14:07:20  GUI [551:551]: ANY <0+emerg > 840.363.257:_log_set ANY =3
<128>Jun  9 14:07:20  lbt [551]: BANY<0+emerg > BANY=3

 

[JohnS_3CX]

Hi,

Are you using a custom FQDN and certs? (unknown certificate CA error)

How exactly does your Site to Site VPN work, is the PBX aware of it or is it entirely transparent?

Any phones on the VPN would appear as local, but any phones over STUN would need to come via the public route meaning that IF the phone is in a STUN deployment, it need to be able to reach the PBX over TLS for provisioning.

State your PBX version, and your phones Firmware version as well as if you are using custom templates please.

 

[IZT_crobinson]

Yes using FQDN and certs

Site to Site is a VTI tunnel routed. It's transparent as far as I know

Everything can reach the phone over the public 5001 for example). After the initial provision, it works for calls just fine.

I put the PBX version, and phone info in the original post.

PBX Version: 16.0.5.612
Phone: Yealink T46S
Phone Firmware: 66.85.0.5
Phone Hardware: 66.0.0.128.0.0.16

 

[JohnS_3CX]

Thanks. It indeed appears something may be breaking the TLS handshake (if the phone IP replies back to the PBX IP that there is an Unknown CA


Now you say you used the same certs in another server and it worked. If we assume for a moment that the certs are ok and accepted by the phone, then the reason they don't work on the PBX is probably due to something not set up correctly on the PBX side.

Can you confirm that the cert and key are installed correctly on the machine as per here please?
https://www.3cx.com/docs/self-hosted-instances-ssh/

 

[B Garfitt]

I had a similar issue with a Go Daddy certificate when we used STUN. I had to add the intermediate certificate into the NGINX certificate file for the phones to provision.

 

[JohnS_3CX]

Exactly, if there is an intermediate cert missing, then the chain breaks and the phone will not be able to verify your main cert.

We don't face this issue with Let's Encrypt if using a 3CX FQDN because this part is taken care of for you automatically.

When using a custom FQDN and your own certs, you will be responsible for ensureing the chain is complete.