Not all platforms define BN_ULLONG. Define SCTS_TIMESTAMP as a type
which should work on all platforms.
(cherry picked from commit 6634416732b94627eba1c47de3c3a6321a5458f0)
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.
The flag SSL_OP_MSIE_SSLV2_RSA_PADDING hasn't done anything since OpenSSL
0.9.7h but deleting it will break source compatibility with any software
that references it. Restore it but #define to zero.
(cherry picked from commit b17d6b8d1d49fa4732deff17cfd1833616af0d9c)
Kurt Roeckx [Mon, 23 Dec 2013 18:45:26 +0000 (19:45 +0100)]
Use defaults bits in req when not given
If you use "-newkey rsa" it's supposed to read the default number of bits from the
config file. However the value isn't used to generate the key, but it does
print it's generating such a key. The set_keygen_ctx() doesn't call
EVP_PKEY_CTX_set_rsa_keygen_bits() and you end up with the default set in
pkey_rsa_init() (1024). Afterwards the number of bits gets read from the config
file, but nothing is done with that anymore.
We now read the config first and use the value from the config file when no size
is given.
Scott Schaefer [Mon, 23 Dec 2013 18:01:38 +0000 (19:01 +0100)]
Document pkcs12 -password behavior
apps/pkcs12.c accepts -password as an argument. The document author
almost certainly meant to write "-password, -passin".
However, that is not correct, either. Actually the code treats
-password as equivalent to -passin, EXCEPT when -export is also
specified, in which case -password as equivalent to -passout.
Include TA in checks/callback with partial chains.
When a chain is complete and ends in a trusted root checks are also
performed on the TA and the callback notified with ok==1. For
consistency do the same for chains where the TA is not self signed.
Scott Deboy [Wed, 5 Feb 2014 02:48:59 +0000 (18:48 -0800)]
Don't break out of the custom extension callback loop - continue instead
The contract for custom extension callbacks has changed - all custom extension callbacks are triggered
Scott Deboy [Thu, 12 Sep 2013 19:03:40 +0000 (12:03 -0700)]
Update custom TLS extension and supplemental data 'generate' callbacks to support sending an alert.
If multiple TLS extensions are expected but not received, the TLS extension and supplemental data 'generate' callbacks are the only chance for the receive-side to trigger a specific TLS alert during the handshake.
Removed logic which no-op'd TLS extension generate callbacks (as the generate callbacks need to always be called in order to trigger alerts), and updated the serverinfo-specific custom TLS extension callbacks to track which custom TLS extensions were received by the client, where no-ops for 'generate' callbacks are appropriate.
Return per-certificate chain if extra chain is NULL.
If an application calls the macro SSL_CTX_get_extra_chain_certs
return either the old "shared" extra certificates or those associated
with the current certificate.
This means applications which call SSL_CTX_use_certificate_chain_file
and retrieve the additional chain using SSL_CTX_get_extra_chain_certs
will still work. An application which only wants to check the shared
extra certificates can call the new macro
SSL_CTX_get_extra_chain_certs_only
Andy Polyakov [Wed, 5 Feb 2014 13:08:44 +0000 (14:08 +0100)]
ssl/s3_pkt.c: move multi-block processing to ssl3_write_bytes.
This allows to process multiple fragmets of maximum fragment size,
as opposite to chopping maximum-sized fragments to multiple smaller
ones. This approach relies on dynamic allocation of larger buffers,
which we trade for performance improvement, for several *times* in
some situations.
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.
Remove reference to ERR_TXT_MALLOCED in the error library as that is
only used internally. Indicate that returned error data must not be
freed.
(cherry picked from commit f2d678e6e89b6508147086610e985d4e8416e867)
Always add a dynamically loaded ENGINE to list. Otherwise it can cause
problems when multiply loaded, especially if it adds new public key methods.
For all current engines we only want a single implementation anyway.
change SSL3_CK_EDH_* to SSL_CK_DHE_* (with backward-compatibility)
This change normalizes the SSL_CK_DHE_ #defines to use the common term
"DHE", while permitting older code that uses the more uncommon "EDH"
constants to compile properly.
DHE is the standard term used by the RFCs and by other TLS
implementations. It's useful to have the internal variables use the
standard terminology.
This patch leaves a synonym SSL_kEDH in place, though, so that older
code can still be built against it, since that has been the
traditional API. SSL_kEDH should probably be deprecated at some
point, though.
emit "DHE" instead of "edh" for kX packet trace output
other parts of packet tracing emit the standard "DHE" label instead of
"edh". This change brings the output of ssl_print_client_keyex() and
ssl_print_server_keyex() into accordance with the standard term.
Allow "DHE" and "kDHE" as synonyms of "EDH" and "kEDH" when specifiying ciphers
The standard terminology in https://tools.ietf.org/html/rfc5426 is
"DHE". "openssl ciphers" outputs "DHE" (for the most part). But
users of the library currently cannot specify "DHE", they must
currently specify "EDH".
This change allows users to specify the common term in cipher suite
strings without breaking backward compatibility.
ECDHE is the standard term used by the RFCs and by other TLS
implementations. It's useful to have the internal variables use the
standard terminology.
This patch leaves a synonym SSL_kEECDH in place, though, so that older
code can still be built against it, since that has been the
traditional API. SSL_kEECDH should probably be deprecated at some
point, though.
emit "ECDHE" instead of "EECDH" for kX packet trace output
other parts of packet tracing emit the standard "ECDHE" label instead
of "EECDH". This change brings the output of ssl_print_client_keyex()
and ssl_print_server_keyex() into accordance with the standard term.
Allow "ECDHE" as a synonym of "EECDH" when specifiying ciphers
The standard terminology in https://tools.ietf.org/html/rfc4492 is
ECDHE. "openssl ciphers" outputs ECDHE. But users of the library
currently cannot specify ECDHE, they must specify EECDH.
This change allows users to specify the common term in cipher suite
strings without breaking backward compatibility.