SSL_CTX_use_certificate_chain_file() is preferred over
SSL_CTX_use_certificate_file().
It allows the use of complete certificate chains instead of loading
only the first certificate in a PEM file.
LibreSSL has deprecated SSLv3_method, so this commit makes that a compile-time
feature.
It also removes a test referencing SSL_OP_CISCO_ANYCONNECT, as the LibreSSL
header says it is amongst "Obsolete flags kept for compatibility. No sane code
should use them."
In OpenSSL world, the SSLv23 option is a poorly name method that will
negotiate what version of TLS or SSL to use. It starts with the best
version the library supports and then precedes to keep trying all the
way down to SSL 2.0.
This abolishes the test.sh script which spawns a bunch of `openssl` instances to
instead run/manage the binary in-process (providing more isolation to boot). The
tests have been updated accordingly and the `connected_socket` dependency was
also dropped in favor of `net2` as it the former doesn't work on Windows.
The current behavior causes a server written using rust-openssl to (if
it cannot negotiate a protocol) fallback to the first protocol it has
avaliable.
This makes it impossible to detect protocol mismatches.
This updates our selection to be more similar to how openssl's
s_server behaves: non-matching protocols are not supplied with a
fallback.
Note that some setups may actually want a fallback protocol supplied
via ALPN. To support those cases, we should consider adding a generic
callback that allows protocol selection to be entirely controlled by
the programmer.
For the purposes of having a sane default, however, not supplying a
default (and mimicing s_server's behavior) is the best choice.
GNU linkers will sometimes aggressively try to strip objects and archives from a
linker command line in a left-to-right fashion. When a linker hits an object
file that doesn't satisfy any unresolved symbols, it will discard the object and
not re-visit it. This means that currently if symbols are depended upon in
libssl then some of the dependencies of libssl (in libcrypto) may have already
been stripped, causing a link error.
By swapping the order of what's linked it reflects the natural flow of
dependencies and the linker should figure everything out for us.
Jimmy Cuadra