Yealink provisioning problem


#1

Hello,
Trying to provision Yealink phone using SSL I have faced the following problem. Yealink provides the list of trusted CAs where we have:

ISRG Root X1 (intermediate certificates: Let’s Encrypt Authority X1 and Let’s Encrypt
Authority X2 are signed by the root certificate ISRG Root X1.)

To certify my server I have created a new LetsEncrypt certificate using certbot. Then I have applied that certificate to the provisioning server and also uploaded it on my Yealink phone. But when I try to provision the phone using that server I get “Unknown CA” Error. I think the problem is that currently certbot generates certificate issued with "Let’s Encrypt Authority X3”. Meanwhile even latest versions of Yealink firmware trust to “Let’s Encrypt Authority X1” and “Let’s Encrypt Authority X2”.
My question is: Is there any way (maybe some key) to force the certbot generate certificate issued by “Let’s Encrypt Authority X2”, not X3.


#2

Hi @amovsisyan

X2 is outdated. See there:

Retired

So you have to find another solution.


#3

Hmm, I think LetsEncrypt should provide some “back door” for the users to be able still generate ‘Retired’ certificates. Otherwise those Yealink users (and probably more) who relied on LetsEncrypt are in a trouble.


#4

It doesn’t really matter which “generation” of intermediate you use.

Your device doesn’t (or at least, shouldn’t) trust the intermediates (Let’s Encrypt Authority X1, X2 or X3) directly.

The trust comes from the fact that the intermediate is signed by one of your trust anchors (be it ISRG Root X1, or DST Root CA X3).

All of the intermediates (X1, X2, X3) and their cross-signed variants are signed in the same way.

If your phone doesn’t trust X3, it wouldn’t trust X2 either.

If you accidentally used the ISRG-signed X3 intermediate on your server instead of the DST-signed X3 intermediate, that could explain the issue with trust on your device (since maybe your device doesn’t trust ISRG Root X1, but might trust DST Root CA X3). Or vice-versa.

Maybe try replacing your intermediate certificate with the opposite. So if you have Let’s Encrypt X3 (ISRG) right now, replace it with Let’s Encrypt X3 (DST). Or the other way around.


#5

Incorrect if your first statement about Yealink is true: it trusts a certain root certificate, the ISRG X1 root cert. The information behind it is outdated (about the X1 and X2 intermediate certs), but that shouldn’t matter.

You’ll need to check which intermediate is send by your server: the X3 intermediate cross signed by IdenTrust (DST Root 3) or the X3 intermediate signed by ISRG Root X1.

If you’re having troubles and Yealink accepts the ISRG root X1 cert, there’s a good chance your server sends the cross signed X3 intermediate, which is currently still the default. Change your intermediate to the X3 cert signed by ISRG Root X1 and it probably would work.


#6

As @Osiris and @_az have explained, the idea is that a site can send intermediate certificates along with the end-entity certificates.

You can view the certificate chain with

openssl s_client -connect yoursite.example.com:443 -servername yoursite.example.com

or you can use the certificate view in your web browser (although it might be confusing or misleading because the browser can use its own cached/remembered certificates to create the trust chain, which can be different from the ones that were directly sent by the server), or you can use the ssllabs.com tester.

The idea is that the root CA’s certificate is built into the client (including your browser, or Yealink). The intermediate certificate is issued and signed by a particular root CA and says “Let’s Encrypt Authority X3 is a trusted CA”, while the end-entity certificate is issued and signed by Let’s Encrypt Authority X3 and says “yoursite.example.com can use the specified public key for TLS connections”.

On the page that @JuergenAuer linked to, you can see that Let’s Encrypt offers an intermediate certificate signed by DST (IdenTrust), a traditional CA that is very widely trusted, and also an intermediate certificate signed by the ISRG root, a new root CA directly controlled and operated by the Let’s Encrypt organization. Most users automatically use, and are recommended to use, the first of these because the DST root is much more widely trusted (especially in older devices and operating systems), but the second is available for use where it’s needed or where it’s known to work.


#7

Yealink’s documentation is unusual:

http://support.yealink.com/faq/faqInfo?id=691

First, they say that they’ve trusted ISRG Root X1 longer than DST Root CA X3.

Second, they specifically call out the X1 and X2 intermediates for some reason.

ISRG Root X1 (intermediate certificates: Let’s Encrypt Authority X1 and Let’s Encrypt Authority X2 are signed by the root certificate ISRG Root X1.)

Note: ISRG Root X1, Let’s Encrypt Authority X1 and Let’s Encrypt Authority X2 certificates are only applicable to SIP-T48G/T46G/T42G/T41P/T40P/T29G/T27P/T23P/T23G/T21§ E2/T19§E2 IP phones running firmware version X.80.0.95 or later.

The first is unusual but understandable. The second… it’s impossible to say what it means without more information from Yealink.

It’s possible that, like Windows XP, their software was incompatible with the X1 and X2 intermediates, and that’s why they’re calling them out. If that’s the case, the X3 and X4 intermediates presumably work better.


#8

Hello guys,
I have verified and, yes, it happened that my generated certificate is a cross signed one (DST Root 3).
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Since yealink documentation says that they trusted ISRG Root X1 longer than DST Root CA X3, most likely that this is the reason of problem (possibly my firmware version trusts only ISRG Root X1).
Is there any way to change my intermediate’s root to ISRG Root X1? I was looking into certbot options but was not able to find anything relating to that…


#9

This isn’t the problem. One Letsencrypt - certificate, the same website:

FireFox shows ISRG Root as Root-Certificate.
Chrome shows DST Root as Root-Certificate.

So you have already one certificate with two root certificates - one direct, one cross signed.

PS: I have the same effect with https://community.letsencrypt.org/


#10

Both FireFox and Chrome showing DST Root as Root-Certificate. Also, I have used following commands to verify:
openssl s_client -connect my.domain.name:443 -servername my.domain.name
Response: depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3

openssl x509 -text -in chain.pem
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3

So it is definitely DST Root CA X3


#11

The feature a commonly used browser can have (such as the downloading of another intermediate certificate which is not contained in the chain), could not be available in another client, like Yealink.

@amovsisyan I don’t think certbot can change the intermediate certificate for you. It just takes the cert provided by the ACME server. You can however manually change it in your webserver configuration.


#12

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