It created the cert structure in SSL_CTX or SSL if it was NULL, but they can
never be NULL as the comments already said.
Reviewed-by: NDr. Stephen Henson <steve@openssl.org>

Suggested by John Foley <foleyj@cisco.com>.
Reviewed-by: NMatt Caswell <matt@openssl.org>

I left many "#if 0" lines, usually because I thought we would
probably want to revisit them later, or because they provided
some useful internal documentation tips.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

A few minor cleanups to remove pre-processor "#if 1" stuff.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Rewrite ssl3_send_client_key_exchange to retain the premaster secret
instead of using it immediately.

This is needed because the premaster secret is used after the client key
exchange message has been sent to compute the extended master secret.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

The following compile options (#ifdef's) are removed:
    OPENSSL_NO_BIO OPENSSL_NO_BUFFER OPENSSL_NO_CHAIN_VERIFY
    OPENSSL_NO_EVP OPENSSL_NO_FIPS_ERR OPENSSL_NO_HASH_COMP
    OPENSSL_NO_LHASH OPENSSL_NO_OBJECT OPENSSL_NO_SPEED OPENSSL_NO_STACK
    OPENSSL_NO_X509 OPENSSL_NO_X509_VERIFY

This diff is big because of updating the indents on preprocessor lines.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

Always use goto err on failure and call ssl_cert_free() on the error path so all
fields and "ret" itself are freed
Signed-off-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

The only support for SSLv2 left is receiving a SSLv2 compatible client hello.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

Use the same structure for client and server custom extensions.

Add utility functions in new file t1_ext.c.
Use new utility functions to handle custom server and client extensions
and remove a lot of code duplication.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Move custom extension structures from SSL_CTX to CERT structure.

This change means the form can be revised in future without binary
compatibility issues. Also since CERT is part of SSL structures
so per-SSL custom extensions could be supported in future as well as
per SSL_CTX.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Fix typo that stopped SSL_CTX_get_{first,next}_certificate from working.

Security callback: selects which parameters are permitted including
sensible defaults based on bits of security.

The "parameters" which can be selected include: ciphersuites,
curves, key sizes, certificate signature algorithms, supported
signature algorithms, DH parameters, SSL/TLS version, session tickets
and compression.

In some cases prohibiting the use of a parameters will mean they are
not advertised to the peer: for example cipher suites and ECC curves.
In other cases it will abort the handshake: e.g DH parameters or the
peer key size.

Documentation to follow...

Add auto DH parameter support. This is roughly equivalent to the
ECDH auto curve selection but for DH. An application can just call

SSL_CTX_set_auto_dh(ctx, 1);

and appropriate DH parameters will be used based on the size of the
server key.

Unlike ECDH there is no way a peer can indicate the range of DH parameters
it supports. Some peers cannot handle DH keys larger that 1024 bits for
example. In this case if you call:

SSL_CTX_set_auto_dh(ctx, 2);

Only 1024 bit DH parameters will be used.

If the server key is 7680 bits or more in size then 8192 bit DH parameters
will be used: these will be *very* slow.

The old export ciphersuites aren't supported but those are very
insecure anyway.

Don't clear verification errors from the error queue unless
SSL_BUILD_CHAIN_FLAG_CLEAR_ERROR is set.

If errors occur during verification and SSL_BUILD_CHAIN_FLAG_IGNORE_ERROR
is set return 2 so applications can issue warnings.
(cherry picked from commit 2dd6976f6d02f98b30c376951ac38f780a86b3b5)

When setting the current certificate check that it has a corresponding
private key.

New flags to build certificate chains. The can be used to rearrange
the chain so all an application needs to do is add all certificates
in arbitrary order and then build the chain to check and correct them.

Add verify error code when building chain.

Update docs.

New ctrl sets current certificate based on certain criteria. Currently
two options: set the first valid certificate as current and set the
next valid certificate as current. Using these an application can
iterate over all certificates in an SSL_CTX or SSL structure.

If pointer comparison for current certificate fails check
to see if a match using X509_cmp succeeds for the current
certificate: this is useful for cases where the certificate
pointer is not available.

PR#3169

This patch, which currently applies successfully against master and
1_0_2, adds the following functions:

SSL_[CTX_]select_current_cert() - set the current certificate without
disturbing the existing structure.

SSL_[CTX_]get0_chain_certs() - get the current certificate's chain.

SSL_[CTX_]clear_chain_certs() - clear the current certificate's chain.

The patch also adds these functions to, and fixes some existing errors
in, SSL_CTX_add1_chain_cert.pod.

Add callbacks supporting generation and retrieval of supplemental data entries, facilitating RFC 5878 (TLS auth extensions)
Removed prior audit proof logic - audit proof support was implemented using the generic TLS extension API
Tests exercising the new supplemental data registration and callback api can be found in ssltest.c.
Implemented changes to s_server and s_client to exercise supplemental data callbacks via the -auth argument, as well as additional flags to exercise supplemental data being sent only during renegotiation.

Contributed by Trevor Perrin.

client hello message. Previously this could only be retrieved on an initial
connection and it was impossible to determine the cipher IDs of any uknown
ciphersuites.

New function X509_chain_up_ref to dup and up the reference count of
a STACK_OF(X509): replace equivalent functionality in several places
by the equivalent call.

by a certificate chain. Add additional tests to handle client
certificates: checks for matching certificate type and issuer name
comparison.

Print out results of checks for each candidate chain tested in
s_server/s_client.

possible to have different stores per SSL structure or one store in
the parent SSL_CTX. Include distint stores for certificate chain
verification and chain building. New ctrl SSL_CTRL_BUILD_CERT_CHAIN
to build and store a certificate chain in CERT structure: returing
an error if the chain cannot be built: this will allow applications
to test if a chain is correctly configured.

Note: if the CERT based stores are not set then the parent SSL_CTX
store is used to retain compatibility with existing behaviour.

details in s_client.

Also add ctrl to set client certificate types. If not used sensible values
will be included based on supported signature algorithms: for example if
we don't include any DSA signing algorithms the DSA certificate type is
omitted.

Fix restriction in old code where certificate types would be truncated
if it exceeded TLS_CT_NUMBER.

the permitted signature algorithms for server and client authentication
are the same but it is now possible to set different algorithms for client
authentication only.

is required by client or server. An application can decide which
certificate chain to present based on arbitrary criteria: for example
supported signature algorithms. Add very simple example to s_server.
This fixes many of the problems and restrictions of the existing client
certificate callback: for example you can now clear existing certificates
and specify the whole chain.

the certificate can be used for (if anything). Set valid_flags field
in new tls1_check_chain function. Simplify ssl_set_cert_masks which used
to have similar checks in it.

Add new "cert_flags" field to CERT structure and include a "strict mode".
This enforces some TLS certificate requirements (such as only permitting
certificate signature algorithms contained in the supported algorithms
extension) which some implementations ignore: this option should be used
with caution as it could cause interoperability issues.

Only store encoded versions of peer and configured signature algorithms.
Determine shared signature algorithms and cache the result along with NID
equivalents of each algorithm.

TLS v1.2. These are sent as an extension for clients and during a certificate
request for servers.

TODO: add support for shared signature algorithms, respect shared algorithms
when deciding which ciphersuites and certificates to permit.