| Age | Commit message (Collapse) | Author |
|---|
|
When building the certificate chain, prioritise any Cert(0) Full(0)
certificates from TLSA records over certificates received from the peer.
This is important when the server sends a cross cert, but TLSA records include
the underlying root CA cert. We want to construct a chain with the issuer from
the TLSA record, which can then match the TLSA records (while the associated
cross cert may not).
Reviewed-by: Tomáš Mráz <tomas@openssl.org>
|
|
The X509_V_FLAG_X509_STRICT flag enables additional security checks of the
certificates present in a certificate chain. It is not set by default.
Starting from OpenSSL version 1.1.1h a check to disallow certificates with
explicitly encoded elliptic curve parameters in the chain was added to the
strict checks.
An error in the implementation of this check meant that the result of a
previous check to confirm that certificates in the chain are valid CA
certificates was overwritten. This effectively bypasses the check
that non-CA certificates must not be able to issue other certificates.
If a "purpose" has been configured then a subsequent check that the
certificate is consistent with that purpose also checks that it is a
valid CA. Therefore where a purpose is set the certificate chain will
still be rejected even when the strict flag has been used. A purpose is
set by default in libssl client and server certificate verification
routines, but it can be overriden by an application.
Affected applications explicitly set the X509_V_FLAG_X509_STRICT
verification flag and either do not set a purpose for the certificate
verification or, in the case of TLS client or server applications,
override the default purpose to make it not set.
CVE-2021-3450
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
...in case the candidate issuer cert is identical to the target cert.
Fixes #13739
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13749)
|
|
The certificate path validation procedure specified in RFC 5280 does not
include checking the validity period of the trusted (root) certificate.
Still it is common good practice to perform this check.
Also OpenSSL did this until version 1.1.1h, yet
commit e2590c3a162eb118c36b09c2168164283aa099b4 accidentally killed it.
The current commit restores the previous behavior.
It also removes the cause of that bug, namely counter-intuitive design
of the internal function check_issued(), which was complicated by checks
that actually belong to some other internal function, namely find_issuer().
Moreover, this commit adds a regression check and proper documentation of
the root cert validity period check feature, which had been missing so far.
Fixes #13471
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/13585)
|
|
This unifies the behaviour of a single certificate with
an unknown CA certificate with a self-signed certificate.
The user callback can mask that error to retrieve additional
error information. So the user application can decide to
abort the connection instead to be forced by openssl.
This change in behaviour is backward compatible as user callbacks
who don't want to ignore UNABLE_TO_VERIFY_LEAF_SIGNATURE will
still abort the connection by default.
CLA: trivial
Fixes #11297
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11359)
|
|
The check is applied only with X509_V_FLAG_X509_STRICT.
Fixes #12139
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/12909)
|
|
If a presumably self-signed cert is last in chain we verify its signature
only if X509_V_FLAG_CHECK_SS_SIGNATURE is set. Upon this request we do the
signature verification, but not in case it is a (non-conforming) self-issued
CA certificate with a key usage extension that does not include keyCertSign.
Make clear when we must verify the signature of a certificate
and when we must adhere to key usage restrictions of the 'issuing' cert.
Add some comments for making internal_verify() easier to understand.
Update the documentation of X509_V_FLAG_CHECK_SS_SIGNATURE accordingly.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12357)
|
|
Move check that cert signing is allowed from x509v3_cache_extensions() to
where it belongs: internal_verify(), generalize it for proxy cert signing.
Correct and simplify check_issued(), now checking self-issued (not: self-signed).
Add test case to 25-test_verify.t that demonstrates successful fix.
As prerequisites, this adds the static function check_sig_alg_match()
and the internal functions x509_likely_issued() and x509_signing_allowed().
This is a backport of the core of PR #10587.
Fixes #1418
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/12357)
|
|
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/11941)
(cherry picked from commit bbc3c22c0e2b3b4b6f069712dc8322a48506b775)
|
|
without error handling.
This takes up the ball from #11278
without trying to solve everything at once.
[extended tests]
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11852)
|
|
If we encounter certificate with basic constraints CA:false,
pathlen present and X509_V_FLAG_X509_STRICT is set we set
X509_V_ERR_INVALID_EXTENSION error.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/11463)
(cherry picked from commit fa86e2ee3533bb7fa9f3c62c38920cf960e9fec0)
|
|
Basically we use EXFLAG_INVALID for all kinds of out of memory and
all kinds of parse errors in x509v3_cache_extensions.
[extended tests]
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10756)
|
|
Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
directory. Currently, they have different suffixes like
'*_lcl.h', '*_local.h', or '*_int.h'
This commit changes the different suffixes to '*_local.h' uniformly.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)
|
|
Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:
While header files in 'include/internal' are intended to be shared
between libcrypto and libssl, the files in 'crypto/include/internal'
are intended to be shared inside libcrypto only.
To make things complicated, the include search path is set up in such
a way that the directive #include "internal/file.h" could refer to
a file in either of these two directoroes. This makes it necessary
in some cases to add a '_int.h' suffix to some files to resolve this
ambiguity:
#include "internal/file.h" # located in 'include/internal'
#include "internal/file_int.h" # located in 'crypto/include/internal'
This commit moves the private crypto headers from
'crypto/include/internal' to 'include/crypto'
As a result, the include directives become unambiguous
#include "internal/file.h" # located in 'include/internal'
#include "crypto/file.h" # located in 'include/crypto'
hence the superfluous '_int.h' suffixes can be stripped.
The files 'store_int.h' and 'store.h' need to be treated specially;
they are joined into a single file.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9847)
|
|
Fix a few places where calling ossl_isdigit does the wrong thing on
EBCDIC based systems.
Replaced with ascii_isdigit.
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9556)
(cherry picked from commit 48102247ff513d4c57b40b19c1d432f37b9e4b02)
|
|
The check_key_level() function currently fails when the public key
cannot be extracted from the certificate because its algorithm is not
supported. However, the public key is not needed for the last
certificate in the chain.
This change moves the check for level 0 before the check for a
non-NULL public key.
For background, this is the TPM 1.2 endorsement key certificate.
I.e., this is a real application with millions of certificates issued.
The key is an RSA-2048 key.
The TCG (for a while) specified
Public Key Algorithm: rsaesOaep
rather than the commonly used
Public Key Algorithm: rsaEncryption
because the key is an encryption key rather than a signing key.
The X509 certificate parser fails to get the public key.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7906)
|
|
Also, some readers of the code find starting the count at 1 for EE
cert confusing (since RFC5280 counts only non-self-issued intermediate
CAs, but we also counted the leaf). Therefore, never count the EE
cert, and adjust the path length comparison accordinly. This may
be more clear to the reader.
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit dc5831da59e9bfad61ba425d886a0b06ac160cd6)
|
|
At the bottom of https://tools.ietf.org/html/rfc5280#page-12 and
top of https://tools.ietf.org/html/rfc5280#page-13 (last paragraph
of above https://tools.ietf.org/html/rfc5280#section-3.3), we see:
This specification covers two classes of certificates: CA
certificates and end entity certificates. CA certificates may be
further divided into three classes: cross-certificates, self-issued
certificates, and self-signed certificates. Cross-certificates are
CA certificates in which the issuer and subject are different
entities. Cross-certificates describe a trust relationship between
the two CAs. Self-issued certificates are CA certificates in which
the issuer and subject are the same entity. Self-issued certificates
are generated to support changes in policy or operations. Self-
signed certificates are self-issued certificates where the digital
signature may be verified by the public key bound into the
certificate. Self-signed certificates are used to convey a public
key for use to begin certification paths. End entity certificates
are issued to subjects that are not authorized to issue certificates.
that the term "self-issued" is only applicable to CAs, not end-entity
certificates. In https://tools.ietf.org/html/rfc5280#section-4.2.1.9
the description of path length constraints says:
The pathLenConstraint field is meaningful only if the cA boolean is
asserted and the key usage extension, if present, asserts the
keyCertSign bit (Section 4.2.1.3). In this case, it gives the
maximum number of non-self-issued intermediate certificates that may
follow this certificate in a valid certification path. (Note: The
last certificate in the certification path is not an intermediate
certificate, and is not included in this limit. Usually, the last
certificate is an end entity certificate, but it can be a CA
certificate.)
This makes it clear that exclusion of self-issued certificates from
the path length count applies only to some *intermediate* CA
certificates. A leaf certificate whether it has identical issuer
and subject or whether it is a CA or not is never part of the
intermediate certificate count. The handling of all leaf certificates
must be the same, in the case of our code to post-increment the
path count by 1, so that we ultimately reach a non-self-issued
intermediate it will be the first one (not zeroth) in the chain
of intermediates.
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit ed422a2d0196ada0f5c1b6e296f4a4e5ed69577f)
|
|
Only check the CN against DNS name contraints if the
`X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` flag is not set, and either the
certificate has no DNS subject alternative names or the
`X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT` flag is set.
Add pertinent documentation, and touch up some stale text about
name checks and DANE.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6145)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5837)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4431)
|
|
This guards against the name constraints check consuming large amounts
of CPU time when certificates in the presented chain contain an
excessive number of names (specifically subject email names or subject
alternative DNS names) and/or name constraints.
Name constraints checking compares the names presented in a certificate
against the name constraints included in a certificate higher up in the
chain using two nested for loops.
Move the name constraints check so that it happens after signature
verification so peers cannot exploit this using a chain with invalid
signatures. Also impose a hard limit on the number of name constraints
check loop iterations to further mitigate the issue.
Thanks to NCC for finding this issue. Fix written by Martin Kreichgauer.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4393)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4217)
|
|
return true for characters > 127. I.e. they are allowing extended ASCII
characters through which then cause problems. E.g. marking superscript '2' as
a number then causes the common (ch - '0') conversion to number to fail
miserably. Likewise letters with diacritical marks can also cause problems.
If a non-ASCII character set is being used (currently only EBCDIC), it is
adjusted for.
The implementation uses a single table with a bit for each of the defined
classes. These functions accept an int argument and fail for
values out of range or for characters outside of the ASCII set. They will
work for both signed and unsigned character inputs.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4102)
|
|
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3740)
|
|
Make signature security level checking more flexible by using
X509_get_signaure_info(): some signature methods (e.g. PSS, ED25519)
do not indicate the signing digest (if any) in the signature OID.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3301)
|
|
- Reject fractional seconds
- Reject offsets
- Check that the date/time digits are in valid range.
- Add documentation for X509_cmp_time
GH issue 2620
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
|
|
It should not have been removed.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Tim Hudson <tjh@openssl.org>
|
|
Update certificate and CRL time routines to match new standard.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1413)
|
|
Because proxy certificates typically come without any CRL information,
trying to check revocation on them will fail. Better not to try
checking such information for them at all.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Thanks to David Benjamin <davidben@google.com> for reporting this bug.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Remove current_method: it was intended as a means of retrying
lookups bit it was never used. Now that X509_verify_cert() is
a "one shot" operation it can never work as intended.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
We only add setters for X509_STORE function pointers except for the
verify callback function. The thought is that the function pointers
in X509_STORE_CTX are a cache for the X509_STORE functions.
Therefore, it's preferable if the user makes the changes in X509_STORE
before X509_STORE_CTX_init is called, and otherwise use the verify
callback to override any results from OpenSSL's internal
calculations.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
If two CRLs are equivalent then use the one with a later lastUpdate field:
this will result in the newest CRL available being used.
RT#4615
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
In light of potential UKS (unknown key share) attacks on some
applications, primarily browsers, despite RFC761, name checks are
by default applied with DANE-EE(3) TLSA records. Applications for
which UKS is not a problem can optionally disable DANE-EE(3) name
checks via the new SSL_CTX_dane_set_flags() and friends.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
New hostname checking function asn1_valid_host()
Check commonName entries against nameConstraints: any CN components in
EE certificate which look like hostnames are checked against
nameConstraints.
Note that RFC5280 et al only require checking subject alt name against
DNS name constraints.
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
When the proxy cert code was initially added, some application authors
wanted to get them verified without having to change their code, so a
check of the env var OPENSSL_ALLOW_PROXY_CERTS was added.
Since then, the use of this variable has become irrelevant, as it's
likely that code has been changed since, so it's time it gets removed.
Reviewed-by: Tim Hudson <tjh@openssl.org>
|
|
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1264)
|
|
While travelling up the certificate chain, the internal
proxy_path_length must be updated with the pCPathLengthConstraint
value, or verification will not work properly. This corresponds to
RFC 3820, 4.1.4 (a).
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>
|
|
The subject name MUST be the same as the issuer name, with a single CN
entry added.
RT#1852
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>
|
|
Set ctx->error = X509_V_ERR_OUT_OF_MEM when verificaiton cannot
continue due to malloc failure. Also, when X509_verify_cert()
returns <= 0 make sure that the verification status does not remain
X509_V_OK, as a last resort set it it to X509_V_ERR_UNSPECIFIED,
just in case some code path returns an error without setting an
appropriate value of ctx->error.
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Add some functions that were missing when a number of X509
objects became opaque (thanks, Roumen!)
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
