| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
lib/ssl/test/ssl_ECC_SUITE.erl
|
|
The ssl application uses the new function in many of its test cases.
|
|
Otherwhise test can be wrongly initialized and will fail as they try to run
with a broken setup.
|
|
Problems with failure of ssl_certificate_verify_SUITE when enabling DTLS-1
tests in ssl_basic_SUITE was a combination of the bug fixed by the
previous commit and missing clean up code for dtls_protocol_versions
application environment variable
|
|
Test should check that we get the expected key exchange algorithm
for the provided server cert. We do not want to test OpenSSL s_server.
Do not try to test cipher suites against OpenSSL that it does not
support.
|
|
|
|
|
|
With the new help functions for creating test data we can simplify the
code. And sometimes corrections have been made so that the test actually
perform the test intended.
|
|
The certificate chain handling had become quite entangled and
was not correct.
|
|
* ingela/ECC-tests:
ssl: Make sure common-test priv_dir is used for test case generated files
|
|
We where never really satisfied with this workaround it was
a bit far fetched, so we are pleased to be able to remove it.
|
|
|
|
As per RFC 4492 Sec 5.1, the preferred order of selection of named
curves is based on client preferences.
Currently, the SSL application only picks entries according to the
absolute order of entries as tracked in a hardcoded list in code.
This patch changes things so that the client-specified order is
preferred. It also allows a mode where the server can be configured to
override the client's preferred order with its own, although the chosen
ECC must still be within both lists.
The configuration is done through the following options:
- `eccs`, shared by clients and servers alike, allows the specification
of the supported named curves, in their preferred order, and may
eventually support more values for explicit primes and so on.
- `honor_ecc_order`, a server-only option, is similar to
`honor_cipher_order` and will, by default let the server pick the
client-preferred ECC, and otherwise pick the server-preferred one.
The default value for `eccs` is the same as before, although the
server-chosen ECC now defaults to the client rather than previous
choice.
A function `ssl:eccs()` has been added that returns the highest
supported ECCs for the library.
|
|
|
|
Tests in ECC_SUITE did not always use the certs implied by the
name. Variable naming also confused the intent.
ssl_certificate_verify_SUITE did not clean up properly and tests could
fail due to cache problems.
|
|
The selection of CA cert files in ssl_ECC_SUITE and ssl_test_lib
ought to be refactored, it is quite confusing.
But use this workaround until we get time to make a refactor.
|
|
|
|
Consolidate code that logs TLS/DTLS version during testing
into ssl_test_lib.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* ia/ssl/modern-timetrap:
ssl: Make init functions fail if make_certs:all fails
ssl: Avoid sleep
ssl: modernize timetrap handling
|
|
|
|
When possible avoid sleep in test cases.
|
|
Watchdog is legacy test_server use only ct:timetrap/1
|
|
|
|
The test cases does not use any hooks and including the ts_install_cth
trips up the test case setup on some platforms cuasing the test cases
to fail with {error, enoent}
|
|
Check that the certificate chain ends with a trusted ROOT CA e.i. a
self-signed certificate, but provide an option partial_chain to
enable the application to define an intermediat CA as trusted.
TLS RFC says:
"unknown_ca
A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not
be located or couldn't be matched with a known, trusted CA. This
message is always fatal."
and also states:
"certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case."
X509 RFC says:
"The selection of a trust anchor is a matter of policy: it could be
the top CA in a hierarchical PKI, the CA that issued the verifier's
own certificate(s), or any other CA in a network PKI. The path
validation procedure is the same regardless of the choice of trust
anchor. In addition, different applications may rely on different
trust anchors, or may accept paths that begin with any of a set of
trust anchors."
|
|
Use generated certs instead of hard coded
|
|
with proper defaults
Added ssl_ECC_SUITE
|
