remove prototypes with no matching function
feedback and ok tb@

Eliminate the timegm(3) dependency in libcrypto

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

Eliminate the timegm(3) dependency in libcrypto

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

show more ...

Allow IP addresses to be specified in a URI.

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 e

Allow IP addresses to be specified in a URI.

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@

show more ...

Stop relying on x509_verify.h being public

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 i

Stop relying on x509_verify.h being public

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

show more ...

Refactor x509v3_cache_extensions

Simplify x509v3_cache_extensions() by using a wrapper to avoid
duplication of code for locking and checking the EXFLAG_INVALID flag.

OK tb@

Make internal header file names consistent

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 *_l

Make internal header file names consistent

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

show more ...

Revert "Check certificate extensions in trusted certificates"

There are some possible strange side effects noticed by the
openssl cms regress tests that I missed. Backing this out
until I untangle i

Revert "Check certificate extensions in trusted certificates"

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@

show more ...

Check certificate extensions in trusted certificates.

Historically the standards let the implementation decide to
either check or ignore the certificate properties of trust anchors.
You could either

Check certificate extensions in trusted certificates.

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)

show more ...

Start CBS-ifying the name constraints code.

ok jsing@ tb@

Allow security_level to mestastasize into the verifier

The tentacles are everywhere. This checks that all certs in a chain
have keys and signature algorithms matching the requirements of the
securi

Allow security_level to mestastasize into the verifier

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

show more ...

Rework ownership handling in x509_constraints_validate()

Instead of having the caller allocate and pass in a new
x509_constraints_name struct, handle allocation inside
x509_constraints_validate(). A

Rework ownership handling in x509_constraints_validate()

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

show more ...

Add x509_constraints_validate() to x509_internal.h

From Alex Wilson

ok jsing

In some situations, the verifier would discard the error on an unvalidated
certificte chain. This would happen when the verification callback was
in use, instructing the verifier to continue uncondit

In some situations, the verifier would discard the error on an unvalidated
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.

show more ...

Cache sha512 hash and parsed not_before and not_after with X509 cert.

Replace sha1 hash use with sha512 for certificate comparisons internal
to the library. use the cached sha512 for the validator's

Cache sha512 hash and parsed not_before and not_after with X509 cert.

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@

show more ...

Move the now internal X.509-related structs into x509_lcl.h.
Garbage collect the now unused LIBRESSL_CRYPTO_INTERNAL and
LIBRESSL_OPAQUE_X509. Include "x509_lcl.h" where needed and
fix a couple of un

Move the now internal X.509-related structs into x509_lcl.h.
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

show more ...

Validate Subject Alternate Names when they are being added to certificates.

With this change we will reject adding SAN DNS, EMAIL, and IP addresses
that are malformed at certificate creation time.

Validate Subject Alternate Names when they are being added to certificates.

With this change we will reject adding SAN DNS, EMAIL, and IP addresses
that are malformed at certificate creation time.

ok jsing@ tb@

show more ...

Call the callback on success in new verifier in a compatible way
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 o

Call the callback on success in new verifier in a compatible way
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@

show more ...

Get rid of historical code to extract the roots in the legacy case.
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

Get rid of historical code to extract the roots in the legacy case.
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@

show more ...

Remove the "dump_chain" flag and code. This was a workaround for a problem where
roots were not checked correctly before intermediates that has since been fixed
and is no longer necessary. It is regr

Remove the "dump_chain" flag and code. This was a workaround for a problem where
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@

show more ...

Pull roots out of the trust store in the legacy xsc when building chains
to handly by_dir and fun things correctly. - fixes dlg@'s case and
by_dir regress in openssl-ruby

ok jsing@

Add a bunch of workarond in the verifier to support partial chains and
the saving of the first error case so that the "autochain" craziness from
openssl will work with the new verifier. This should a

Add a bunch of workarond in the verifier to support partial chains and
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@

show more ...

Fix checks of memory caps of constraints names

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

Fix checks of memory caps of constraints names

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

show more ...

Gracefully handle root certificates being both trusted and untrusted.

When a certificate (namely a root) is specified as both a trusted and
untrusted certificate, the new verifier will find multiple

Gracefully handle root certificates being both trusted and untrusted.

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@

show more ...

KNF (whitespace)

Handle additional certificate error cases in new X.509 verifier.

With the old verifier, the verify callback can always return 1 instructing
the verifier to simply continue regardless of a certificat

Handle additional certificate error cases in new X.509 verifier.

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@

show more ...