chrisdlangton
commented
2 years ago @achow101 :100: agree
I came across the same issue which led me to raise #36 as it seems there are at least 3 certificate chain validation issues with this library.
i.e. 3 concerns that I looked into, I stopped due to 3 of 3 failures identified. There are very likely more cert chain validation issues present
The facts of this whole issue:
- This is the most mature attempt in the entire python ecosystem
- It is seemingly no longer maintained
pyOpenSSLare just bindings for OpenSSL for this issue- OpenSSL (and everything using it I would hazard a guess) doesn't even to attempt to validate the certificate chain, just the root CA and server cert host and expiry - that's it..
certifiand everything based from iturlibrequestsetc. doesn't do validation at all, period (if the https response was validated by OpenSSL and has data, then no one cares about actually validating any certs)asn1cryptosimilar topyOpenSSLwhich this library knows well as it is built uponasn1cryptoto add the missing validations..cryptographyagain similar topyOpenSSLhowever they at least debated this for quite a few years to no plan to start a solution- No other programming language that I have investigated before python (C#, Ruby, Java, .NET, nodejs, PHP, Golang, Rust) even comes close to having an option even close to the level of maturity as this library, and none have validation built into the programming language or any popular http modules/libs/packages (same situation as python, only they don't have this lib)
So it is a very sorry state for certification validation, and why we are seeing so many breaches, no one actually uses TLS properly anywhere, it's all smoke and mirrors.
fanquake
Some certificates will contain critical extensions that certvalidator doesn't know about. If the caller knows those critical extensions, it can pass them into ValidationContext so that validate_path doesn't error when it gets to the critical extensions check.