summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/x509/x509_purp.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* 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)