Part of RT 3997
Per Ben, just jump to common exit code.
Signed-off-by: Rich Salz <rsalz@akamai.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit cc2829e6641092abed8360433dbe67e883fd1cc6)
The function X509_verify_cert checks the value of |ctx->chain| at the
beginning, and if it is NULL then it initialises it, along with the value
of ctx->untrusted. The normal way to use X509_verify_cert() is to first
call X509_STORE_CTX_init(); then set up various parameters etc; then call
X509_verify_cert(); then check the results; and finally call
X509_STORE_CTX_cleanup(). The initial call to X509_STORE_CTX_init() sets
|ctx->chain| to NULL. The only place in the OpenSSL codebase where
|ctx->chain| is set to anything other than a non NULL value is in
X509_verify_cert itself. Therefore the only ways that |ctx->chain| could be
non NULL on entry to X509_verify_cert is if one of the following occurs:
1) An application calls X509_verify_cert() twice without re-initialising
in between.
2) An application reaches inside the X509_STORE_CTX structure and changes
the value of |ctx->chain| directly.
With regards to the second of these, we should discount this - it should
not be supported to allow this.
With regards to the first of these, the documentation is not exactly
crystal clear, but the implication is that you must call
X509_STORE_CTX_init() before each call to X509_verify_cert(). If you fail
to do this then, at best, the results would be undefined.
Calling X509_verify_cert() with |ctx->chain| set to a non NULL value is
likely to have unexpected results, and could be dangerous. This commit
changes the behaviour of X509_verify_cert() so that it causes an error if
|ctx->chain| is anything other than NULL (because this indicates that we
have not been initialised properly). It also clarifies the associated
documentation. This is a follow up commit to CVE-2015-1793.
Reviewed-by: Stephen Henson <steve@openssl.org>
During certificate verfification, OpenSSL will attempt to find an
alternative certificate chain if the first attempt to build such a chain
fails. An error in the implementation of this logic can mean that an
attacker could cause certain checks on untrusted certificates to be
bypassed, such as the CA flag, enabling them to use a valid leaf
certificate to act as a CA and "issue" an invalid certificate.
This occurs where at least one cert is added to the first chain from the
trust store, but that chain still ends up being untrusted. In that case
ctx->last_untrusted is decremented in error.
Patch provided by the BoringSSL project.
CVE-2015-1793
Reviewed-by: Stephen Henson <steve@openssl.org>
Also tighten X509_cmp_time to reject more than three fractional
seconds in the time; and to reject trailing garbage after the offset.
CVE-2015-1789
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
The big "don't check for NULL" cleanup requires backporting some
of the lowest-level functions to actually do nothing if NULL is
given. This will make it easier to backport fixes to release
branches, where master assumes those lower-level functions are "safe"
This commit addresses those tickets: 3798 3799 3801.
Reviewed-by: Matt Caswell <matt@openssl.org>
This reverts commit 47daa155a31b0a54ce09ad2ed4d55fad74096dab.
The above commit was backported to the 1.0.2 branch as part of backporting
the alternative chain verify algorithm changes. However it has been pointed
out (credit to Shigeki Ohtsu) that this is unnecessary in 1.0.2 as this
commit is a work around for loop checking that only exists in master.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Disable loop checking when we retry verification with an alternative path.
This fixes the case where an intermediate CA is explicitly trusted and part
of the untrusted certificate list. By disabling loop checking for this case
the untrusted CA can be replaced by the explicitly trusted case and
verification will succeed.
Signed-off-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit e5991ec528b1c339062440811e2641f5ea2b328b)
Reviewed-by: Rich Salz <rsalz@openssl.org>
valid. However the issuer of the leaf, or some intermediate cert is in fact
in the trust store.
When building a trust chain if the first attempt fails, then try to see if
alternate chains could be constructed that are trusted.
RT3637
RT3621
Reviewed-by: Rich Salz <rsalz@openssl.org>
This should be a one off operation (subsequent invokation of the
script should not move them)
This commit is for the 1.0.2 changes
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reduces number of silly casts in OpenSSL code and likely most
applications. Consistent with (char *) for "peername" value from
X509_check_host() and X509_VERIFY_PARAM_get0_peername().
(cherry picked from commit 297c67fcd817ea643de2fdeff4e434b050d571e2)
Pass address of X509_VERIFY_PARAM_ID peername to X509_check_host().
Document modified interface.
(cherry picked from commit ced3d9158a7a8c676be504bb6cd3b5ffb7cc7f13)
Just store NUL-terminated strings. This works better when we add
support for multiple hostnames.
(cherry picked from commit b3012c698a086937319ed413a113ed7bec1edd1a)
Fixes to host checking wild card support and add support for
setting host checking flags when verifying a certificate
chain.
(cherry picked from commit 397a8e747dc3f964196caed5ca4e08d4b598362a)
When a chain is complete and ends in a trusted root checks are also
performed on the TA and the callback notified with ok==1. For
consistency do the same for chains where the TA is not self signed.
(cherry picked from commit 385b3486661628f3f806205752bf968b8114b347)
Move the IP, email and host checking fields from the public
X509_VERIFY_PARAM structure into an opaque X509_VERIFY_PARAM_ID
structure. By doing this the structure can be modified in future
without risk of breaking any applications.
When verifying a partial path always check to see if the EE certificate
is explicitly trusted: the path could contain other untrusted certificates.
(cherry picked from commit 52073b76753815ef1dcc3ab3f9dba75803f717f4)
PR #3090
Reported by: Franck Youssef <fry@open.ch>
If no new reason codes are obtained after checking a CRL exit with an
error to avoid repeatedly checking the same CRL.
This will only happen if verify errors such as invalid CRL scope are
overridden in a callback.
(cherry picked from commit 4b26645c1a71cf9ce489e4f79fc836760b670ffe)
Submitted by: steve@openssl.org
Include a flag ASN1_STRING_FLAG_MSTRING when a multi string type is created.
This makes it possible to tell if the underlying type is UTCTime,
GeneralizedTime or Time when the structure is reused and X509_time_adj_ex()
can handle each case in an appropriate manner.
Add error checking to CRL generation in ca utility when nextUpdate is being
set.
