...
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:
...
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.