WolfSSL cert issue

[Osiris]

@rg305 A developer on Github said: " We do document WOLFSSL_ALT_CERT_CHAINS in src/internal.c"

[jvanasco]

@dhewg

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?

Originally I thought the same exact thing (although when looking at Ubuntu and OpenSSL's approach to this problem). Hopefully I can clarify this nuance that I totally missed myself.

The official and widespread recommended solution right now is to serve the (newest) R3 Cross-Signed Intermediate, which chains up to the expired DST Root. The R3 has a notAfter date in the future, the expired DST Root has a date in the past.

This succeeds with older Android devices, because their systems do not validate a trusted root's notAfter date. (I'm not sure if this is a "whoops!" or was by design).

Almost all other devices, libraries and programs will correctly fail on validating this certificate chain. However, many libraries and browsers effectively do not care about this failed validation, and will successfully validate the certificate/chain if they can compute an alternate path to another Trusted Root. In this case, the R3 Cross-Signed Intermediate is the same exact key pairing as the ISRG signed Intermediate. Many SSL libraries/apps will actually ignore the specified long cross-signed chain, and short-circuit a validation against the shorter ISRG chain as an implementation detail because they have the trusted key pairing cached or more easily available in their search algorithm. (sidenote: this is why a site can serve a specific chain, but clicking the lock icon on a browser shows an alternate chain.)

OpenSSL did not implement this behavior in their search, but recently switched to provide it. Ubuntu and other OS vendors released updates to support this, both in the form of upgrading OpenSSL and - in some systems - removing the DST Root from the trust store. IIRC, removing the root would typically cause a not-found error in the search logic, which would bypass a fatal error from an expired "notAfter", and then allow the alternate chain searching to continue.

What this all means, is there is no potential security issue for specifying the expired root except for older Android devices. Within the older android ecosystem, there is the theoretical security issue of an expired root being used. For the majority of other modern clients: the specified and expired root is ignored; trust is being validated by building an alternate chain to a valid Trusted Root.

All that being said, the root expiry is guaranteed to cause issues for large number of users. No solution was possible - in theory or practice - that could eliminate issues for all users. The current approach works for the greatest number of users, and causes harm to the smallest number of users. While most servers can upgrade their trust stores, consumer devices generally don't have this ability - legacy apple, windows, nix devices are stuck with trust stores filled with certificates that are all soon expiring, and no simple method for consumers to update.

[dhewg]

Thanks for taking the time to write that down!

@jvanasco

OpenSSL did not implement this behavior in their search, but recently switched to provide it.
snip
and then allow the alternate chain searching to continue.

If you put it like that it kinda sounds like that WolfSSL option.

Meanwhile that option is now exposed via configure switch, so it's not that hidden anymore:

Configure: add option to enable alternate certificate chains (#4455)