In 4.2, it is possible to use TLS for connections through a sipXbridge gateway. This provides encryption and authentication for the external connection between sipXecs and other systems which support TLS.
In order for TLS to work, the two systems will exchange certificates, and each system must be able to validate the other's certificate. Since sipXecs certificates are self-signed by our own Certificate Authority, you must install our CA certificate on the other system. XX-7320 tracks an issue to allow export of a sipXecs CA certificate so that it can be saved for install on another external system. Until that issue is resolved, the CA certificate can be found on the sipXecs system at /etc/sipxpbx/ssl/authorities/ca.<hostname>.crt. Install this certificate on the remote system following whatever procedure it requires.
Similarly, the remote system's CA certificate must be imported into sipXecs. This is done on the Certificate Authorities panel under System -> Certificates. 
Basic TLS interop (through a bridge) is ready to go now - just set the Gateway transport to TLS and change the port to match the remote TLS port (normally 5061). Note that the remote system may need to be configured to send to port 5081 (the TLS port of a sipXbridge gateway). 
An additional advantage of using TLS for remote gateways which is coming soon (possibly in 4.2), is that users of the remote system can be mapped to a sipXecs user, and may then use resources which require permissions (e.g. ITSP gateways, etc). This feature is tracked by XX-6398 . At the time of writing, it is required to set up a configuration file manually to map from the remote FDQN to an internal user, and to create the internal user and assign appropriate permissions. The configuration file is called peeridentities.xml and has the following format:
<peeridentities xmlns="http://www.sipfoundry.org/sipX/schema/xml/peeridentities-00-00"> <peer> <trusteddomain>trusteddomain.com</trusteddomain> <internaluser>~~pi~trusteddomain.com</internaluser> </peer> <peer> <trusteddomain>10.10.1.2</trusteddomain> <internaluser>~~pi~10.10.1.2</internaluser> </peer> </peeridentities>
Eventually the special internal users (of the form ~~pi~<fqdn>) will be created automatically, and permissions will be assigned to them through the sipXconfig interface.