summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/x509 (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Change the OPENSSL_strdup() to strdup()job2021-09-021-3/+4
| | | | OK beck@ tb@
* Fix header file includesjob2021-09-022-8/+9
| | | | OK tb@
* Move the error put functions from X509V3err() to X509V3error()job2021-09-022-52/+32
| | | | OK tb@
* Unroll ASN1_SEQUENCE() ASN1_CHOICE() ASN1_ITEM_TEMPLATE()job2021-09-022-46/+218
| | | | OK jsing@
* OPENSSL_assert() is not appropriate in this contextjob2021-09-021-2/+3
| | | | | | Feedback from tb@ OK tb@
* Replace ossl_assert()/assert() with OPENSSL_assert()job2021-09-022-14/+14
| | | | OK tb@
* Replace OPENSSL_free() with free()job2021-09-022-7/+7
| | | | OK tb@
* Unroll IMPLEMENT_ASN1_FUNCTIONS()job2021-09-022-8/+197
| | | | OK jsing@
* Unroll DECLARE_ASN1_FUNCTIONS()job2021-09-021-9/+56
| | | | OK jsing@
* Rename DEFINE_STACK_OF() to DECLARE_STACK_OF()job2021-09-021-4/+4
| | | | OK tb@ jsing@
* Lay groundwork to support X.509 v3 extensions for IP Addresses and AS ↵job2021-09-026-4/+2377
| | | | | | | | | | | 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@
* Revert previous change that changed our default return for unable tobeck2021-08-301-11/+5
| | | | | | | | find leaf cert issuers. This breaks perl and ruby regress, as noticed by tb that "we tried this before". Jan's regress that cares about 21 vs 20 needs to change ok tb@
* Fix Jan's regress in openssl/x509 to do what it says it does,beck2021-08-301-5/+11
| | | | | | | | then fix the only thing it still has complaints about which is that we don't return the leaf version of the error code when we can't verify the leaf (as opposed to the rest of the chain) ok jan@ tb@
* Don't call the verify callback twice on success.beck2021-08-291-2/+1
| | | | | | | This fixes a problem in the perl regress where it notices the callback is called twice and complains. ok tb@ bluhm@
* Get rid of historical code to extract the roots in the legacy case.beck2021-08-283-78/+33
| | | | | | | | Due to the need to support by_dir, we use the get_issuer stuff when running in x509_vfy compatibility mode amyway - so just use it any time we are doing that. Removes a bunch of yukky stuff and a "Don't Look Ethel" ok tb@ jsing@
* Remove the "dump_chain" flag and code. This was a workaround for a problem wherebeck2021-08-282-16/+4
| | | | | | | roots were not checked correctly before intermediates that has since been fixed and is no longer necessary. It is regress checked by case 2c in regress/lib/libcrypto/x509/verify.c ok jsing@ tb@
* Fix various read buffer overflow when printing ASN.1 strings (which aretb2021-08-243-12/+17
| | | | | | | | not necessarily NUL terminated). Same as schwarze's fix in t_x509a.c r1.9. From David Benjamin and Matt Caswell (part of the fixes in OpenSSL 1.1.1l) ok inoguchi
* Pull roots out of the trust store in the legacy xsc when building chainsbeck2021-08-193-8/+26
| | | | | | | to handly by_dir and fun things correctly. - fixes dlg@'s case and by_dir regress in openssl-ruby ok jsing@
* Add a check_trust call to the legacy chain validation on chain add, rememberingbeck2021-08-181-2/+10
| | | | | | | | | the result in order to return the same errors as OpenSSL users expect to override the generic "Untrusted cert" error. This fixes the openssl-ruby timestamp test. ok tb@
* Refactor the legacy chain validation from the chain adding code into itsbeck2021-08-181-52/+70
| | | | | | own function, in preparation for subesquent change. No functional change. ok tb@
* Similar to x509/x509_purp.c rev. 1.5:schwarze2021-07-231-5/+1
| | | | | | | | | | | | | Delete some code from X509_TRUST_cleanup(3) that had no effect: it called a function on static objects that returns right away unless the argument is dynamically allocated. Pointed out by tb@. This commit is identical to: OpenSSL commit 5e6e650d62af09f47d63bfdd6c92e3b16e9da644 Author: Kurt Cancemi <kurt at x64architecture dot com> Date: Thu Jun 9 21:57:36 2016 -0400
* 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
* Use the x509_verify_cert_cache_extensions fuction instead of manuallybeck2021-07-121-9/+4
| | | | | | | calling the OpenSSL legacy cache extensions goo. Requested by tb@ ok tb@
* Add a bunch of workarond in the verifier to support partial chains andbeck2021-07-102-16/+135
| | | | | | | | | the saving of the first error case so that the "autochain" craziness from openssl will work with the new verifier. This should allow the new verification code to work with a bunch of the autochain using cases in some software. (and should allow us to stop using the legacy verifier with autochain) ok tb@
* Revert "Handle X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE in newtb2021-04-281-4/+1
| | | | | | | | verifier." (r1.27). While this may have "fixed" one corner case, it broke expectations of Perl Net::SSLeay and Ruby OpenSSL regression tests. ok bcook
* Relax SAN DNSname validation and constraints to permit non leading *beck2021-04-271-19/+21
| | | | | | | | | | | wildcards. While we may choose not to support them the standards appear to permit them optionally so we can't declare a certificate containing them invalid. Noticed by jeremy@, and Steffan Ulrich and others. Modify the regression tests to test these cases and not check the SAN DNSnames as "hostnames" anymore (which don't support wildcards). ok jsing@, tb@
* Enable the new verifier again so hopefully the remaining kinks get ironedtb2021-04-241-2/+2
| | | | | | out in this release cycles. discussed with deraadt and jsing
* Switch back to the legacy verifier for the release.tb2021-04-151-2/+2
| | | | | | | | | | | This is disappointing as a lot of work was put into the new verifier during this cycle. However, there are still too many known bugs and incompatibilities. It is better to be faced with known broken behavior than with new broken behavior and to switch now rather than via errata. This way we have another cycle to iron out the kinks and to fix some of the remaining bugs. ok jsing
* Don't leak param->name in x509_verify_param_zero()tb2021-04-051-1/+2
| | | | | | | | | For dynamically allocated verify parameters, param->name is only ever set in X509_VERIFY_set1_name() where the old one is freed and the new one is assigned via strdup(). Setting it to NULL without freeing it beforehand is a leak. looks correct to millert, ok inoguchi
* Provide missing prototype for d2i_DSAPrivateKey_fp(3)tb2021-03-311-1/+2
| | | | ok bcook inoguchi jsing
* 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-132-11/+45
| | | | | | x509v3_cache_extensions(). ok tb@
* Zap a useless variable.tb2021-03-121-4/+2
| | | | suggested by jsing
* Missing void in function definitiontb2021-03-121-2/+2
| | | | ok jsing
* Fix checks of memory caps of constraints namestb2021-03-123-20/+32
| | | | | | | | | | | | | | | x509_internal.h defines caps on the number of name constraints and other names (such as subjectAltNames) that we want to allocate per cert chain. These limits are checked too late. In a particularly silly cert that jan found on ugos.ugm.ac.id 443, we ended up allocating six times 2048 x509_constraint_name structures before deciding that these are more than 512. Fix this by adding a names_max member to x509_constraints_names which is set on allocation against which each addition of a name is checked. cluebat/ok jsing ok inoguchi on earlier version
* Set is_trusted in x509_verify_ctx_add_chain()tb2021-02-261-2/+2
| | | | | | | | If we're about to add a chain we have a trust path, so we have at least one trusted certificate. This fixes a thinko from r1.31 and fixes the openssl(1) cms verify test. ok jsing (who had the same diff)
* Fix two bugs in the legacy verifiertb2021-02-251-6/+10
| | | | | | | | | | | | | | | To integrate the new X.509 verifier, X509_verify_cert() was refactored. The code building chains in the legacy verifier was split into a separate function. The first bug is that its return value was treated as a Boolean although it wasn't. Second, the return alone is not enough to decide whether to carry on the validation or not. Slightly rearrange things to restore the behavior of the legacy verifier prior to this refactoring. Issue found and test case provided by Anton Borowka and jan. ok jan jsing
* Rename depth to num_untrusted so it identifies what it actually represents.jsing2021-02-251-6/+6
| | | | ok tb@
* Avoid passing last and depth to x509_verify_cert_error() on ENOMEM.jsing2021-02-251-3/+2
| | | | | | | | | In x509_verify_ctx_set_xsc_chain(), an ENOMEM case is currently passing the last certificate and depth (which is no longer actually depth) to x509_verify_cert_error(). Given we've hit an ENOMEM situation, neither of these are useful so remove both. ok tb@
* Fix comment explaining last_untrusted. This should really be calledtb2021-02-241-2/+2
| | | | | | num_untrusted, but unfortunately it's public... ok jsing tobhe
* Make the new validator check for EXFLAG_CRITICALtb2021-02-241-8/+15
| | | | | | | | | | | | | | | | | | | | | | As should be obvious from the name and the comment in x509_vfy.h int last_untrusted; /* index of last untrusted cert */ last_untrusted actually counts the number of untrusted certs at the bottom of the chain. Unfortunately, an earlier fix introducing x509_verify_set_xsc_chain() assumed that last_untrusted actually meant the index of the last untrusted cert in the chain, resulting in an off-by-one, which in turn led to x509_vfy_check_chain_extension() skipping the check for the EXFLAG_CRITICAL flag. A second bug in x509_verify_set_xsc_chain() assumed that it is always called with a trusted root, which is not necessarily the case anymore. Address this with a temporary fix which will have to be revisited once we will allow chains with more than one trusted cert. Reported with a test case by tobhe. ok jsing tobhe
* KNFtb2021-02-111-4/+7
|
* Set chain on xsc on chain build failure.jsing2021-01-091-1/+3
| | | | | | | | Prior to calling the callback, ensure that the current (invalid and likely incomplete) chain is set on the xsc. Some things (like auto chain) depend on this functionality. ok beck@
* Bail out early after finding an single chain if we are have been called frombeck2021-01-091-1/+9
| | | | | | | | x509_vfy and have an xsc. There's no point in finding more chains since that API can not return them, and all we do is trigger buggy callbacks in calling software. ok jsing@
* search the intermediates only after searching the root certs, clarifybeck2021-01-081-11/+15
| | | | | | | this in the comments. helps avoid annoying situations with the legacy callback ok jsing@
* Handle X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE in new verifier.jsing2021-01-051-1/+4
| | | | | | Yet another mostly meaningless error value... Noted by and ok tb@
* Gracefully handle root certificates being both trusted and untrusted.jsing2021-01-052-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | When a certificate (namely a root) is specified as both a trusted and untrusted certificate, the new verifier will find multiple chains - the first being back to the trusted root certificate and a second via the root that is untrusted, followed by the trusted root certificate. This situation can be triggered by a server that (unnecessarily) includes the root certificate in its certificate list. While this validates correctly (using the first chain), it means that we encounter a failure while building the second chain due to the root certificate already being in the chain. When this occurs we call the verify callback indicating a bad certificate. Some sensitive software (including bacula and icinga), treat this single bad chain callback as terminal, even though we successfully verify the certificate. Avoid this problem by simply dumping the chain if we encounter a situation where the certificate is already in the chain and also a trusted root - we'll have already picked up the trusted root as a shorter path. Issue with icinga2 initially reported by Theodore Wynnychenko. Fix tested by sthen@ for both bacula and icinga2. ok tb@
* Remove two reduntat memset calls.tb2020-12-161-3/+1
| | | | pointed out by jsing
* Fix some KNF issuestb2020-12-161-7/+8
|
* Fix a NULL dereference in GENERAL_NAME_cmp()tb2020-12-081-6/+46
| | | | | | | | | | | | Comparing two GENERAL_NAME structures containing an EDIPARTYNAME can lead to a crash. This enables a denial of service attack for an attacker who can control both sides of the comparison. Issue reported to OpenSSL on Nov 9 by David Benjamin. OpenSSL shared the information with us on Dec 1st. Fix from Matt Caswell (OpenSSL) with a few small tweaks. ok jsing
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-31 08:42:35 +0000