Protecting Data in Transit Using TLS/SSL
Last updated
AMPS Server Documentation 5.3.4
Last updated
AMPS provides the ability to use Secure Sockets Layer (SSL)/ Transport Layer Security (TLS) connections for communication with AMPS clients. See the section in the in the and the documentation for the AMPS clients for details.
AMPS uses TLS to encrypt network traffic between clients and servers. No information about the transport is passed to the AMPS authentication and entitlement system. Encryption at the network level is completely independent of the AMPS authentication and entitlement system, and these features can be used independently.
In this version of AMPS, a transport configured to use TLS defaults to accepting only TLS version 1.1, TLS version 1.2, and TLS version 1.3 protocols.
It is possible to enable older protocols using the SecureSocketProtocols configuration directive. 60East recommends using the default settings unless there is a specific reason to enable older protocols and the security implications of enabling older protocols are well understood.
AMPS supports certificate verification for incoming connections. To add certificate verification for incoming connections, add the VerifyClient option to the Transport and provide a set of trusted certificates to use for verification using the CAFile or CAPath parameter. If the certificate provided by an incoming connection has not been signed by one of the trusted certificates, AMPS will refuse the connection.
AMPS also supports certificate verification for outgoing replication connections. To require that an outgoing replication connection verify the certificate for the destination, provide the VerifyClient option in the Transport for the Replication Destination and provide a set of trusted certificates to use for verification using the CAFile or CAPath parameter. If the certificate provided by the destination server has not been signed by one of the trusted certificates, AMPS will close the outgoing connection before attempting to log on.