Directly trusted self-issued end-entity certs - Re: How to rotate cert when only first matching cert been verified

Michael Wojcik Michael.Wojcik at microfocus.com
Fri Jan 1 18:06:47 UTC 2021


> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of ???
> Sent: Friday, 1 January, 2021 00:08

> How to pick up cert from trust store(or cert container as you say)
> is decided by different implementation themselves, do I understand correctly?

Yes, in some cases under partial or complete control by the application. Some APIs, including OpenSSL, give the application a lot of control over the building of the chain; others don't.

And almost everyone does it incorrectly. See for example:

https://duo.com/labs/research/chain-of-fools

https://nakedsecurity.sophos.com/2020/06/02/the-mystery-of-the-expiring-sectigo-web-certificate/

https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/CPT/CPT_Tool_Test-Report_Findings.pdf

(There was another article published not that long ago that surveyed a number of TLS implementations and how they built chains, pointing out how they failed to follow various requirements of PKIX, and what kinds of errors and failures they were prone to. It's similar to the CPT paper linked above, but included comparisons of different OpenSSL versions. I can't seem to find it at the moment.)

The path-validation algorithm in RFC 5280 and the path-building algorithm from RFC 4158 are agonizingly complex. Note, for example, that the description of the path-building algorithm in 4158 is 20 pages, without including the preliminary material or the longer section on optimizations.

TLS simplifies the general problem of X.509 chain construction by limiting what entities are supposed to send (X.509 lets you send any random collection of certificates, or for that matter any other data, in addition to the entity certificate; TLS says "send just a single chain from entity to root or to a certificate signed by the root"). But it's still awful, particularly when things like expiration and cross-signing come into play, and no version of OpenSSL (or any other popular library, as far as I remember) gets it entirely right for all cases.

In practice, if you use a supported OpenSSL release at the latest fix level (that means 1.1.1i at the moment), and you follow good advice about how to use it, and your use case isn't too complex, you provably achieve reasonable security under a typical application threat model. You'll want to make it relatively straightforward to update your trust-anchor collection. If you have to support an environment where things like cross-signing and multiple validation paths become important, that makes things harder. If you have stringent security requirements, that makes things harder. On the other hand, there are so many applications which fail to do even minimal certificate validation, so you can take comfort in knowing you're better than them, anyway.

--
Michael Wojcik



More information about the openssl-users mailing list