summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/x509/x509_purp.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* X509_check_ca() has 5 return values but still can't failtb2022-05-101-3/+1
| | | | | | | | | | | | | | | The values 0, 1, 3, 4, 5 all have some meaning, none of which is failure. If caching of X509v3 extensions fails, returning X509_V_ERR_UNSPECIFIED, i.e., 1 is a bad idea since that means the cert is a CA with appropriate basic constraints. Revert to OpenSSL behavior which is to ignore failure to cache extensions at the risk of reporting lies. Since no return value can indicate failure, we can't fix this in X509_check_ca() itself. Application code will have to call (and check) the magic X509_check_purpose(x, -1, -1) to ensure extensions are cached, then X509_check_ca() can't lie. ok jsing
* Avoid expensive RFC 3779 checks during cert verificationtb2022-04-211-1/+5
| | | | | | | | | | | | | | | X509v3_{addr,asid}_is_canonical() check that the ipAddrBlocks and autonomousSysIds extension conform to RFC 3779. These checks are not cheap. Certs containing non-conformant extensions should not be considered valid, so mark them with EXFLAG_INVALID while caching the extension information in x509v3_cache_extensions(). This way the expensive check while walking the chains during X509_verify_cert() is replaced with a cheap check of the extension flags. This avoids a lot of superfluous work when validating numerous certs with similar chains against the same roots as is done in rpki-client. Issue noticed and fix suggested by claudio ok claudio inoguchi jsing
* Fix X509_get_extension_flags()tb2022-04-211-2/+2
| | | | | | Ensure that EXFLAG_INVALID is set on X509_get_purpose() failure. ok inoguchi jsing
* Cache sha512 hash and parsed not_before and not_after with X509 cert.beck2021-11-041-4/+6
| | | | | | | | | | | Replace sha1 hash use with sha512 for certificate comparisons internal to the library. use the cached sha512 for the validator's verification cache. Reduces our recomputation of hashes, and heavy use of time1 time conversion functions noticed bu claudio@ in rpki client. ok jsing@ tb@
* Move the now internal X.509-related structs into x509_lcl.h.tb2021-11-011-1/+3
| | | | | | | | Garbage collect the now unused LIBRESSL_CRYPTO_INTERNAL and LIBRESSL_OPAQUE_X509. Include "x509_lcl.h" where needed and fix a couple of unnecessary reacharounds. ok jsing
* Actually error in X509_check_purpose() if x509v3_cache_extensions()tb2021-10-291-2/+2
| | | | | | | | | indicates failure. The previous "error return" X509_V_ERR_UNSPECIFIED translates to 1, i.e., success. This changes to the intended behavior of x509_purp.c r1.3 and matches OpenSSL. This will need various adjustments in the documentation. ok jsing
* Prepare to provide X509_get_extension_flags()tb2021-10-231-1/+11
| | | | ok beck jsing
* Prepare to provide X509_get_{extended_,}key_usage()tb2021-10-221-1/+27
| | | | ok beck jsing
* Add XKU_ANYEKU #define and use it to cache the anyExtendedKeyUsagetb2021-10-211-1/+5
| | | | | | | extension. This is part of OpenSSL commit df4c395c which didn't make it into our tree for some reason. ok jsing
* In X509_check_issued() do the same dance around x509v3_cache_extensions()claudio2021-09-131-3/+11
| | | | | | as in all other palces. Check the EXFLAG_SET flag first and if not set grab the CRYPTO_LOCK_X509 before calling x509v3_cache_extensions(). OK tb@ beck@
* Lay groundwork to support X.509 v3 extensions for IP Addresses and AS ↵job2021-09-021-1/+14
| | | | | | | | | | | Identifiers These extensions are defined in RFC 3779 and used in the RPKI (RFC 6482, RFC 8360). Imported from OpenSSL 1.1.1j (aaf2fcb575cdf6491b98ab4829abf78a3dec8402b8b81efc8f23c00d443981bf) This changeset is a no-op, as there are 10+ issues and at least 2 security issues. Work will continue in-tree. OK tb@, discussed with beck@
* Delete some code from X509_PURPOSE_cleanup(3) that had no effect:schwarze2021-07-231-5/+1
| | | | | | | | | | | | | it called a function on static objects that returns right away unless the argument is dynamically allocated. OK jsing@ tb@ The useless code was independently discovered while writing documentation. This commit is identical to: OpenSSL commit fa3a0286d178eb3b87bf2eb5fd7af40f81453314 Author: Kurt Cancemi <kurt at x64architecture dot com> Date: Wed Jun 8 19:15:38 2016 -0400
* Fix copy-paste error in previoustb2021-03-191-2/+2
| | | | | | | Found the hard way by lists y42 org via an OCSP validation failure that in turn caused pkg_add over TLS to fail. Detailed report by sthen. ok sthen
* Use EXFLAG_INVALID to handle out of memory and parse errors intobhe2021-03-131-10/+40
| | | | | | x509v3_cache_extensions(). ok tb@
* Add new x509 certificate chain validator in x509_verify.cbeck2020-09-131-3/+3
| | | | | | | | | | | | | | | | | | | The new validator finds multiple validated chains to handle the modern PKI cases which may frequently have multiple paths via different intermediates to different roots. It is loosely based on golang's x509 validator This includes integration so that the new validator can be used via X509_verify_cert() as well as a new api x509_verify() which will return multiple chains (similar to go). The new validator is not enabled by default with this commit, this will be changed in a follow on commit. The new public API is not yet exposed, and will be finalized and exposed with a man page and a library minor bump later. ok tb@ inoguchi@ jsing@
* Collapse the x509v3 directory into x509.jsing2020-06-041-0/+893
This avoids the need to grep across directories to find functions and prepares for further rototilling and chainsawing. Discussed with tb@ (who also tested the release build)