aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssl/test/ssl_certificate_verify_SUITE.erl
AgeCommit message (Collapse)Author
2015-06-15ssl: Remove unnecessary suite callbackIngela Anderton Andin
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}
2015-01-30ssl: Remove selfsigned anchor certificate from the certificate chainIngela Anderton Andin
A selfsigned trusted anchor should not be in the certifcate chain passed to the certificate path validation. Conflicts: lib/ssl/src/ssl_certificate.erl
2014-09-10ssl: One more workaround as tcp has no delivery gurantee on application levelIngela Anderton Andin
2014-09-09ssl, public_key: Add new option partial_chainIngela Anderton Andin
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."
2013-12-02ssl: Test case enhancementIngela Anderton Andin
Make sure that test cases does not fail due to timing circumstances, use selective receive even if it means we can not use test library functions in some cases. TCP does not have delivery guarantee to application layer, so sometimes a error message {error, Msg} or {error, closed} can be acceptable.
2013-06-07public_key & ssl: Add ASN-1 dependencyIngela Anderton Andin
As the ASN-1 application relies on a nif in R16 for decodeing (that was not the case in R15), public_key currently has a runtime dependency on ASN-1. Hopefully we will be able to remove this dependency again in the future.
2013-06-04ssl: Structural perarparation to support DTLSIngela Anderton Andin
Also phase in tls module as main API instead of ssl. To make API clearer. As TLS is the new protocol name. Maybe keep some API functions in ssl
2013-05-08ssl: ct:print -> ct:log and assert port_commandIngela Anderton Andin
2013-02-18ssl: Further error handling enhancmentsIngela Anderton Andin
follow up enhancments done in commit e56167dd6ca8d37d26ea7f19933691a3bda41113 Make sure format_error return good strings. Replace confusing legacy atoms with more descriptive atoms.
2013-01-21ssl: Enhance error handlingIngela Anderton Andin
Remove filter mechanisms that made error messages backwards compatible with old ssl but hid information about what actually happened. This does not break the documented API however other reason terms may be returned, so code that matches on the reason part of {error, Reason} may fail.
2013-01-11ssl: CTify test casesIngela Anderton Andin