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 dc5831da59)
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 ed422a2d01)
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>
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)
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)
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)
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>
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>
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>
Coverity reports a potential NULL deref when "2 0 0" DANE trust-anchors
from DNS are configured via SSL_dane_tlsa_add() and X509_STORE_CTX_init()
is called with a NULL stack of untrusted certificates.
Since ssl_verify_cert_chain() always provideds a non-NULL stack of
untrusted certs, and no other code path enables DANE, the problem
can only happen in applications that use SSL_CTX_set_cert_verify_callback()
to implement their own wrappers around X509_verify_cert() passing
only the leaf certificate to the latter.
Regardless of the "improbability" of the problem, we do need to
ensure that build_chain() handles this case correctly.
Reviewed-by: Matt Caswell <matt@openssl.org>
Make OBJ_name_cmp internal
Rename idea_xxx to IDEA_xxx
Rename get_rfc_xxx to BN_get_rfc_xxx
Rename v3_addr and v3_asid functions to X509v3_...
Reviewed-by: Richard Levitte <levitte@openssl.org>
Make X509_OBJECT, X509_STORE_CTX, X509_STORE, X509_LOOKUP,
and X509_LOOKUP_METHOD opaque.
Remove unused X509_CERT_FILE_CTX
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
A new X509_VERIFY_PARAM_set_auth_level() function sets the
authentication security level. For verification of SSL peers, this
is automatically set from the SSL security level. Otherwise, for
now, the authentication security level remains at (effectively) 0
by default.
The new "-auth_level" verify(1) option is available in all the
command-line tools that support the standard verify(1) options.
New verify(1) tests added to check enforcement of chain signature
and public key security levels. Also added new tests of enforcement
of the verify_depth limit.
Updated documentation.
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
Previously, it was sufficient to have certSign in keyUsage when the
basicConstraints extension was missing. That is still accepted in
a trust anchor, but is no longer accepted in an intermediate CA.
Reviewed-by: Rich Salz <rsalz@openssl.org>
This was a developer debugging feature and was never a useful public
interface.
Added all missing X509 error codes to the verify(1) manpage, but
many still need a description beyond the associated text string.
Sorted the errors in x509_txt.c by error number.
Reviewed-by: Stephen Henson <steve@openssl.org>
As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa()
are expected to return a negative match depth and nothing else when
verification fails. However, this only happened when verification
failed during chain construction. Errors in verification of the
constructed chain did not have the intended effect on these functions.
This commit updates the functions to check for verify_result ==
X509_V_OK, and no longer erases any accumulated match information
when chain construction fails. Sophisticated developers can, with
care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA
info even when verification fail. They must of course first check
and save the real error, and restore the original error as quickly
as possible. Hiding by default seems to be the safer interface.
Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find
matching TLSA records. Previously reported via X509_V_ERR_CERT_UNTRUSTED.
This also changes the "-brief" output from s_client to include
verification results and TLSA match information.
Mentioned session resumption in code example in SSL_CTX_dane_enable(3).
Also mentioned that depths returned are relative to the verified chain
which is now available via SSL_get0_verified_chain(3).
Added a few more test-cases to danetest, that exercise the new
code.
Resolved thread safety issue in use of static buffer in
X509_verify_cert_error_string().
Fixed long-stating issue in apps/s_cb.c which always sets verify_error
to either X509_V_OK or "chain to long", code elsewhere (e.g.
s_time.c), seems to expect the actual error. [ The new chain
construction code is expected to correctly generate "chain
too long" errors, so at some point we need to drop the
work-arounds, once SSL_set_verify_depth() is also fixed to
propagate the depth to X509_STORE_CTX reliably. ]
Reviewed-by: Rich Salz <rsalz@openssl.org>
