It is quite likely for there to be multiple certificates with empty
subjects, which are still distinct because of subjectAltName. Therefore
we allow multiple certificates with an empty Subject even if
unique_subject is set to yes.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5444)
Commit 87e8feca (16 years ago!) introduced a bug where if we are
attempting to insert a cert with a duplicate subject name, and
duplicate subject names are not allowed (which is the default),
then we get an unhelpful error message back (error number 2). Prior
to that commit we got a helpful error message which displayed details
of the conflicting entry in the database.
That commit was itself attempting to fix a bug with the noemailDN option
where we were setting the subject field in the database too early
(before extensions had made any amendments to it).
This PR moves the check for a conflicting Subject name until after all
changes to the Subject have been made by extensions etc.
This also, co-incidentally fixes the ca crashing bug described in issue
5109.
Fixes#5109
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5444)
Renamed to EVP_PKEY_new_raw_private_key()/EVP_new_raw_public_key() as per
feedback.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5520)
With the current mechanism, old cipher strings that used to work in 1.1.0,
may inadvertently disable all TLSv1.3 ciphersuites causing connections to
fail. This is confusing for users.
In reality TLSv1.3 are quite different to older ciphers. They are much
simpler and there are only a small number of them so, arguably, they don't
need the same level of control that the older ciphers have.
This change splits the configuration of TLSv1.3 ciphers from older ones.
By default the TLSv1.3 ciphers are on, so you cannot inadvertently disable
them through your existing config.
Fixes#5359
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5392)
OPENSSL_DIR_read() now returns unique file names on VMS, no generation
number. We therefore do not need to handle that case in apps/rehash.c
any more.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5602)
These functions are similar to SSL_CTX_set_cookie_{generate,verify}_cb,
but used for the application-controlled portion of TLS1.3 stateless
handshake cookies rather than entire DTLSv1 cookies.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5463)
We also default to SHA256 as per the spec if we do not have an explicit
digest defined.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5554)
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
... and add some missing known values.
Sort ssl/tls extension array list
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5304)
With "-multi" the OCSP responder forks multiple child processes,
and respawns them as needed. This can be used as a long-running
service, not just a demo program. Therefore the index file is
automatically re-read when changed. The responder also now optionally
times out client requests.
Reviewed-by: Matt Caswell <matt@openssl.org>
Retain open file handle and previous stat data for the CA index
file, enabling detection and index reload (upcoming commit).
Check requirements before entering accept loop.
Reviewed-by: Matt Caswell <matt@openssl.org>
Either files or directories of *.cnf or *.conf files
can be included.
Recursive inclusion of directories is not supported.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5351)
When early data support was first added, this seemed like a good
idea, as it would allow applications to just add SSL_read_early_data()
calls as needed and have things "Just Work". However, for applications
that do not use TLS 1.3 early data, there is a negative side effect.
Having a nonzero max_early_data in a SSL_CTX (and thus, SSL objects
derived from it) means that when generating a session ticket,
tls_construct_stoc_early_data() will indicate to the client that
the server supports early data. This is true, in that the implementation
of TLS 1.3 (i.e., OpenSSL) does support early data, but does not
necessarily indicate that the server application supports early data,
when the default value is nonzero. In this case a well-intentioned
client would send early data along with its resumption attempt, which
would then be ignored by the server application, a waste of network
bandwidth.
Since, in order to successfully use TLS 1.3 early data, the application
must introduce calls to SSL_read_early_data(), it is not much additional
burden to require that the application also calls
SSL_{CTX_,}set_max_early_data() in order to enable the feature; doing
so closes this scenario where early data packets would be sent on
the wire but ignored.
Update SSL_read_early_data.pod accordingly, and make s_server and
our test programs into applications that are compliant with the new
requirements on applications that use early data.
Fixes#4725
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5483)
This is to address issue #3404, only works in Unix-like platforms
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3709)
When compiling with -Wall on a machine with an old compiler it gives a false
positive that the dc variable which is a structure of type DISPLAY_COLUMNS
could be used uninitialised. In fact the dc variable's members will always get
set in the case it is used, otherwise it is left uninitialised.
This fix just causes the dc variable's members to always get initialised to 0
at declaration, so the false positive will not get flagged.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5337)
The memory pointed to by the 'push' is freed by the
X509_NAME_ENTRY_free() in do_body(). The second time
it is referenced to (indirectly) in certify_cert:X509_REQ_free().
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4698)
Add -bind option to s_client application to allow specification of
local address for connection.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5272)
The function can fail so we should check the return code.
Found by Coverity
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/5339)
Check for a failure and free a_tm as appropriate.
Found by Coverity
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/5339)
The s_client psk_use_session_cb callback has a comment stating that we
should ignore a key that isn't suitable for TLSv1.3. However we were
actually causing the connection to fail. Changing the return value fixes
the issue.
Also related to this is that the early_data extension was not marked as
TLSv1.3 only which it should be.
Fixes#5202
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5205)
The assumption that the received buffer has to be NUL-terminated was
faulty.
Fault found in #5224
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5239)
Add SSL_verify_client_post_handshake() for servers to initiate PHA
Add SSL_force_post_handshake_auth() for clients that don't have certificates
initially configured, but use a certificate callback.
Update SSL_CTX_set_verify()/SSL_set_verify() mode:
* Add SSL_VERIFY_POST_HANDSHAKE to postpone client authentication until after
the initial handshake.
* Update SSL_VERIFY_CLIENT_ONCE now only sends out one CertRequest regardless
of when the certificate authentication takes place; either initial handshake,
re-negotiation, or post-handshake authentication.
Add 'RequestPostHandshake' and 'RequirePostHandshake' SSL_CONF options that
add the SSL_VERIFY_POST_HANDSHAKE to the 'Request' and 'Require' options
Add support to s_client:
* Enabled automatically when cert is configured
* Can be forced enabled via -force_pha
Add support to s_server:
* Use 'c' to invoke PHA in s_server
* Remove some dead code
Update documentation
Update unit tests:
* Illegal use of PHA extension
* TLSv1.3 certificate tests
DTLS and TLS behave ever-so-slightly differently. So, when DTLS1.3 is
implemented, it's PHA support state machine may need to be different.
Add a TODO and a #error
Update handshake context to deal with PHA.
The handshake context for TLSv1.3 post-handshake auth is up through the
ClientFinish message, plus the CertificateRequest message. Subsequent
Certificate, CertificateVerify, and Finish messages are based on this
handshake context (not the Certificate message per se, but it's included
after the hash). KeyUpdate, NewSessionTicket, and prior Certificate
Request messages are not included in post-handshake authentication.
After the ClientFinished message is processed, save off the digest state
for future post-handshake authentication. When post-handshake auth occurs,
copy over the saved handshake context into the "main" handshake digest.
This effectively discards the any KeyUpdate or NewSessionTicket messages
and any prior post-handshake authentication.
This, of course, assumes that the ID-22 did not mean to include any
previous post-handshake authentication into the new handshake transcript.
This is implied by section 4.4.1 that lists messages only up to the
first ClientFinished.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4964)
The reason to do this is that some output might start with an 'ok',
which TAP catches and takes for TAP output. The TAP compatible way is
to make all output it shouldn't catch look like comments.
We do this by setting the environment variable HARNESS_OSSL_PREFIX
during tests. When that is set, apps/openssl uses BIO_f_linebuffer
and sets its prefix to the content of that environment variable.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5224)
Most modules are direct implementations of openssl application
sub-commands, but some constitute a support library, which can be used
by more than one program (and is, incidently, by test/uitest).
For practical purposes, we place the support library modules in a
private, static library.
Finally, there are some modules that don't have direct references in
the rest of the apps code, but are still crucial. See them as some
kind of extra crt0 or similar for your platform.
Inspiration from David von Oheimb
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5222)
Everything in apps includes apps.h, because that one declares apps
internal library routines. However, progs.h doesn't declare library
routines, but rather the main commands and their options, and there's
no reason why the library modules should include it.
So, remove the inclusion of progs.h from apps.h and add that inclusion
in all command source files.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5222)
