| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
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@
|
