Applications that exchange sensitive data with e.g., a backend server
typically need to ensure they have a secure connection to their peer. To
do this, first obtain a non-secure connection to the peer (eg via a TCP
socket connection). Then create an SSL context via
ssl_context/3.
For the client initiating the connection, the role is’client’,
and you should pass options host/1
and cacerts/1
at the very least. If you expect the peer to have a certificate which
would be accepted by your host system, you can pass
cacerts([system(root_certificates)]), otherwise you will
need a copy of the CA certificate which was used to sign the peer's
certificate. Alternatively, you can pass cert_verify_hook/1
to write your own custom validation for the peer's certificate.
Depending on the requirements, you may also have to provide your /own/
certificate if the peer demands mutual authentication. This is done via
the
certificate_file/1, key_file/1
and either password/1
or
pem_password_hook/1.
Once you have the SSL context and the non-secure stream, you can call
ssl_negotiate/5
to obtain a secure stream. ssl_negotiate/5
will raise an exception if there were any certificate errors that could
not be resolved.
The peer behaves in a symmetric fashion: First, a non-secure
connection is obtained, and a context is created using ssl_context/3
with the role set to server. In the server case, you must provide
certificate_file/1
and key_file/1,
and then either password/1
or
pem_password_hook/1.
If you require the other party to present a certificate as well, then
peer_cert(true) should be provided. If the peer does not present a
certificate, or the certificate cannot be validated as trusted, the
connection will be rejected.
By default, revocation is not checked. To enable certificate
revocation checking, pass require_crl(true) when creating the SSL
context. See section 6 for more
information about revocations.
