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.

appropriate checks in tls1_check_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.

path with spaces.

PR: 2835

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.

for debugging purposes. Needs "enable-ssl-trace" configuration option.

PR: 2830
Submitted by: Robin Seggelmann

specific code path.

improve performance on Atom and P4.