WolfSSL cert issue

Hi there,

sorry but yet another thread about this issue...

OpenWrt ships curl with WolfSSL by default.
curl now fails to connect to any server which is cross signed using the now expired DST Root CA X3 cert.

Compared to OpenSSL, WolfSSL checks the cert chain by default and that includes those dates. And there doesn't seem to be a switch to disable that, see also:

There're alot of threads here about this expired cert, mostly the 'solution' is to remove the X3 cert from the chain, but this is about a client without any means to change any of the servers it's connecting to...
And if the solution is remove that cert everywhere, what's the point of it in the first place?

How's that supposed to be fixed now?

Thanks,
Andre

There are two parties both with two choices, making 4 different scenarios:

Client:
A: Use a very strict client;
B: Use a less strict client.

Server:
A: Wants to have compatibility support for older Android phones (<7.1.1);
B: Doesn't care about older Android phones.

Combinations:
AB/BA/BB: no problems;
AA: problem.

So if you're a client A in situation AA, the only thing you can do is be less strict, so you'd end up in situation BA. Or ask thousands of website operators to change their server into B so you'd have scenario AB.

If both parties keep their client and server A, you'll keep being in scenario AA.

2 Likes

Thanks, I feared as much...
That's a really unfortunate situation :frowning:

1 Like

A newer/patched version of WolfSSL?
Some trick to disable root expiry checks for WolfSSL?
A newer version of OpenWRT that doesn't use WolfSSL?
And I getting warm?

looks like wolfssl by choice won't patch that:


The issue is it's being cross-signed by an outdated X3 certificate, found here: https://letsencrypt.org/certs/trustid-x3-root.pem.txt
The communication from Let's Encrypt claims there is an updated X3 certificate for Android devices but I haven't been able to locate it. The linked IdenTrust certificate found here does not validate the chain: https://www.identrust.com/node/1330
Let's Encrypt needs to use a root CA which is not outdated.
We are not currently planning to add support for cross-signed CAs with invalid root certs.

And yet, if they would just ignore any expired cert, the trust can be verified via "ISRG Root X1".

I'd probably say "more modern" or "less naive" than "less strict". If I understand correctly, WolfSSL is basically giving up after failing to validate the long chain instead of what more modern implementations do which is attempt to find an alternate trust path.

Hehe, maybe?

Patching that one specific expiry check sounds like the best approach, OpenWrt as a disto could just add such a patch, but I'm not sure there's anyone comfortable around that code base to do that...

The idea to switch to OpenSSL came up before, but SSL libraries aren't exactly small (from a routers perspective), and that won't fit on space restricted devices as WolfSSL is on there already due to https/wpa etc.

1 Like

Quoting from here:

Android has intentionally chosen not to use the notAfter field of trust anchors

If I read that correctly, the same behaviour could fix it for WolfSSL. Any idea how Andoid came to that decision?

1 Like

wonder how's the current status of hostapd support of mbedtls? was anything changed last year?

Not that I know of, and I'm not sure switching the primary SSL library again is on the table. Like at all :wink:

2 Likes

There are two different behaviors here:

(1) Ignoring notAfter for root certificates

(2) Ignoring extraneous certificates in chain building (even if there is otherwise some reason to reject them or consider them invalid)

Android does the former, which makes it useful to serve an expired X3 certificate to old Android clients (so Let's Encrypt has been recommending that people do this).

OpenSSL now does the latter, which makes it non-harmful to serve an expired X3 certificate to newer OpenSSL clients.

Unfortunately when you have neither (1) nor (2)—like in older OpenSSL and LibreSSL clients and, I guess, still in WolfSSL—the Android workaround causes diminished compatibility.

The thing WolfSSL would most likely need to change on systems that otherwise receive software updates would be (2) rather than (1). Given that change, and given the ISRG X1 root certificate added to the root CA store, devices would be able to interoperate with servers that are still serving the expired X3 (because they would start to ignore it, like newer OpenSSL does).

3 Likes

Yeah, it does like like that, thanks.

But I think LE underestimated the pain this is inflicting. As not just this thread shows: this isn't limited to just older SSL libraries.
Random other example: my GnuTLS linked audacious from debian testing now fails to play back a stream too:

ERROR neon.cc:756 [fopen]: <0x7f5de0025660> Could not open URL
ERROR util.cc:269 [audgui_simple_message]: Error playing https://stream.tonkuhle.de/tonkuhle.mp3:
Server certificate verification failed: bad certificate chain

One may claim that what WolfSSL is doing is "too strict", but using an expired cert intentionally isn't exactly a clean operation either. The single reason for doing so is an implementation detail of older Android clients, but that also breaks more than just a few up to date clients. It that really worth it?

1 Like

That is a gross misstatement.
Another reason was that newer devices would short-circuit the trust path verification and work.
Which it completely true and the vast majority of the Internet falls into that category.
The gray area is the non-Android systems that are not exactly new (enough).
But one would think that they can be made "new enough" - unlike the old Androids (that really died years ago and everyone just forgot to tell them) that will never ever be "new enough" again.
Unless...
There is an uprising of open-source Android developers and they resurrect them... LOL

Oh okay, then I misunderstood that part, my bad!

1 Like

@dhewg
Case in point - this very web site:

openssl s_client -connect community.letsencrypt.org:443 -servername community.letsencrypt.org | head
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = community.letsencrypt.org
verify return:1
CONNECTED(00000005)
---
Certificate chain
 0 s:CN = community.letsencrypt.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

I bet you have one of those new devices that you didn't have to do anything at all to.
And you got here just fine; As did I.

Looks like there's a build time flag which can be used to solve this. It just isn't documented or the docs are hidden somewhere. Or I fail at finding it :wink:

TLDR: WOLFSSL_ALT_CERT_CHAINS

3 Likes

Maybe:
wolfSSL User Manual | Chapter 7: Keys and Certificates | Documentation
[section 7.2]

I can't find WOLFSSL_ALT_CERT_CHAINS there Rudy.

1 Like

@Osiris
I can't find "WOLFSSL_ALT_CERT_CHAINS" anywhere.
That was the closest thing to anything related to a solution, that I could find.