| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
feedback and ok tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
timegm(3) is not available on some operating systems we support in
portable. We currently use musl's implementation, for which gcc-13
decided to emit warnings (which seem incorrect in general and are
irrelevant in this case anyway). Instead of patching this up and
diverge from upstream, we can avoid reports about compiler warnings
by simply not depending on this function.
Rework the caching of notBefore and notAfter by replacing timegm(3)
with asn1_time_tm_to_time_t(3). Also make this API properly error
checkable since at the time x509v3_cache_extensions(3) is called,
nothing is known about the cert, in particular not whether it isn't
malformed one way or the other.
suggested by and ok beck
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Our checking here was a bit too aggressive, and did not permit an
IP address in a URI. IP's in a URI are allowed for things like CRLdp's
AIA, SAN URI's etc.). The check for this was also slightly flawed as
we would permit an IP if memory allocation failed while checking for
an IP.
Correct both issues.
ok tb@
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Use x509_verify.h from the libcrypto sources instead of the public copy.
The x509_verify.h header was installed as a public header since early on
we had ideas of using a public API in libtls, but we eventually decided
against that. It makes no sense to install a public header that hides
everything behind LIBRESSL_INTERNAL. The public API will not be exposed
anytime soon if at all.
ok jsing
|
| |
|
|
|
|
|
| |
Simplify x509v3_cache_extensions() by using a wrapper to avoid
duplication of code for locking and checking the EXFLAG_INVALID flag.
OK tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names
used for internal headers. Move all these headers we inherited from
OpenSSL to *_local.h, reserving the name *_internal.h for our own code.
Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h.
constant_time_locl.h is moved to constant_time.h since it's special.
Adjust all .c files in libcrypto, libssl and regress.
The diff is mechanical with the exception of tls13_quic.c, where
#include <ssl_locl.h> was fixed manually.
discussed with jsing,
no objection bcook
|
| |
|
|
|
|
|
|
| |
There are some possible strange side effects noticed by the
openssl cms regress tests that I missed. Backing this out
until I untangle it
ok tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically the standards let the implementation decide to
either check or ignore the certificate properties of trust anchors.
You could either use them simply as a source of a public key which
was trusted for everything, or you were also permitted to check the
certificate properties and fully enforce them. Hooray for freedumb.
OpenSSL changed to checking these with :
commit 0daccd4dc1f1ac62181738a91714f35472e50f3c
Author: Viktor Dukhovni <openssl-users@dukhovni.org>
Date: Thu Jan 28 03:01:45 2016 -0500
BoringSSL currently does not check them, as it also inherited
the previous OpenSSL behaviour. It will change to check them in
the future.
(https://bugs.chromium.org/p/boringssl/issues/detail?id=533)
|
| |
|
|
| |
ok jsing@ tb@
|
| |
|
|
|
|
|
|
| |
The tentacles are everywhere. This checks that all certs in a chain
have keys and signature algorithms matching the requirements of the
security_level configured in the verify parameters.
ok beck jsing
|
| |
|
|
|
|
|
|
|
|
| |
Instead of having the caller allocate and pass in a new
x509_constraints_name struct, handle allocation inside
x509_constraints_validate(). Also make the error optional.
All this is done to simplify the call sites and to make it
more obvious that there are no leaks.
ok jsing
|
| |
|
|
|
|
| |
From Alex Wilson
ok jsing
|
| |
|
|
|
|
| |
certificte chain. This would happen when the verification callback was
in use, instructing the verifier to continue unconditionally. This could
lead to incorrect decisions being made in software.
|
| |
|
|
|
|
|
|
|
|
|
| |
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@
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
With this change we will reject adding SAN DNS, EMAIL, and IP addresses
that are malformed at certificate creation time.
ok jsing@ tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
when we succeed with a chain, and ensure we do not call the callback
twice when the caller doesn't expect it. A refactor of the end of
the legacy verify code in x509_vfy is probably overdue, but this
should be done based on a piece that works. the important bit here
is this allows the perl regression tests in tree to pass.
Changes the previously committed regress tests to test the success
case callbacks to be known to pass.
ok bluhm@ tb@
|
| |
|
|
|
|
|
|
| |
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@
|
| |
|
|
|
|
|
| |
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@
|
| |
|
|
|
|
|
| |
to handly by_dir and fun things correctly. - fixes dlg@'s case and
by_dir regress in openssl-ruby
ok jsing@
|
| |
|
|
|
|
|
|
|
| |
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@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the old verifier, the verify callback can always return 1 instructing
the verifier to simply continue regardless of a certificate verification
failure (e.g. the certificate is expired or revoked). This would result
in a chain being built, however the first error encountered would be
persisted, which allows the caller to build the chain, have the
verification process succeed, yet upon inspecting the error code note
that the chain is not valid for some reason.
Mimic this behaviour by keeping track of certificate errors while building
chains - when we finish verification, find the certificate error closest
to the leaf certificate and expose that via the X509_STORE_CTX. There are
various corner cases that we also have to handle, like the fact that we
keep an certificate error until we find the issuer, at which point we have
to clear it.
Issue reported by Ilya Shipitcin due to failing haproxy regression tests.
With much discussion and input from beck@ and tb@!
ok beck@ tb@
|
| |
|
|
|
|
| |
verification code.
ok jsing@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
regression tests. The use of the new name constraints is not yet activated
in x509_vfy.c and will be activated in a follow on commit
ok jsing@
|
