Having received a ClientKeyExchange message instead of a Certificate we
know that we are not going to receive a CertificateVerify message. This
means we can free up the handshake_buffer. However we better call
ssl3_digest_cached_records() instead of just freeing it up, otherwise we
later try and use it anyway and a core dump results. This could happen,
for example, in SSLv3 where we send a CertificateRequest but the client
sends no Certificate message at all. This is valid in SSLv3 (in TLS
clients are required to send an empty Certificate message).

Found using the BoringSSL test suite.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

In TLS if the server sends a CertificateRequest and the client does not
provide one, if the server cannot continue it should send a
HandshakeFailure alert. In SSLv3 the same should happen, but instead we
were sending an UnexpectedMessage alert. This is incorrect - the message
isn't unexpected - it is valid for the client not to send one - its just
that we cannot continue without one.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

In TLS during ClientAuth if the CA is not recognised you should get an
UnknownCA alert. In SSLv3 this does not exist and you should get a
BadCertificate alert.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

The Client Auth tests were not correctly setting the Protocol, so that this
aspect had no effect. It was testing the same thing lots of times for
TLSv1.2 every time.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Move the preparation of the client certificate to be post processing work
after reading the CertificateRequest message rather than pre processing
work prior to writing the Certificate message. As part of preparing the
client certificate we may discover that we do not have one available. If
we are also talking SSLv3 then we won't send the Certificate message at
all. However, if we don't discover this until we are about to send the
Certificate message it is too late and we send an empty one anyway. This
is wrong for SSLv3.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Mingw builds on Travis were failing because INT_MAX was undeclared.
Reviewed-by: NRich Salz <rsalz@openssl.org>

The i2d_SCT_LIST function is declared as __owur, therefore we need to check
the result or a --strict-warnings build will fail.
Reviewed-by: NRich Salz <rsalz@openssl.org>

and short-input performance.

[Fix bug in misaligned output handling.]
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

[Also optimize aligaddr usage in single-block subroutines.]
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>
GH: #1323

Reviewed-by: NRich Salz <rsalz@openssl.org>
GH: #1322

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Instead of having fuzz/build.info.fuzz magically and conditionally
included along with the other build.info files, incorporate it in
fuzz/build.info and add the conditions there instead.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NKurt Roeckx <kurt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1313)

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NStephen Henson <steve@openssl.org>

RT#4611
Reviewed-by: NStephen Henson <steve@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

With a number of tools, especially those coming with Visual Studio,
some command options are separated from their argument with a space,
others with a space.  Since we parametrise them, we can't know
beforehand which it will be, so we must allow the input and output
options to have either.

However, spaces at the end of nmake macro values are trimmed, so allow
spaces to exist by adding a reference to an undefined macro at the end.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

This is only done for the platforms where 'OPENSSL_USE_APPLINK' is defined.

Also, change the docs of OPENSSL_Applink to say where to find applink.c
in the installation directory.
Reviewed-by: NRich Salz <rsalz@openssl.org>

The easiest way to take care of manifest files is to integrate them
into the associated binary (.exe or .dll).  MT (the Manifest Tool) is
the utility to use for this.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

RT#4605
Reviewed-by: NRich Salz <rsalz@openssl.org>

The set0 setters take ownership of their arguments, so the values should
be set to NULL to avoid a double-free in the cleanup block should
ssl_security(SSL_SECOP_TMP_DH) fail. Found by BoringSSL's WeakDH test.
Reviewed-by: NKurt Roeckx <kurt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1299)

Reviewed-by: NRich 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: NRich Salz <rsalz@openssl.org>

subject alternate names.

Add nameConstraints tests incluing DNS, IP and email tests both in
subject alt name extension and subject name.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@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: NRichard Levitte <levitte@openssl.org>

With no-deprecated, some nested includes don't happen by default.
Reviewed-by: NRich Salz <rsalz@openssl.org>

With OpenSSL 1.1 and on, the engines are tightly tied to the shared
library they're to be used with.  That makes them depend on the
pointer size as well as the shared library version, and this gets
reflected in the name of the directory they're installed in.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

We're installing architecture dependent (compiled) programs in
architecture specific directories, while architecture independent
programs (scripts) get installed in the general programs directory.
OSSL$EXE: reflects that by having two values.
Reviewed-by: NRich Salz <rsalz@openssl.org>