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. It is also possible to assign permissions to remote TLS peers, so that users of those systems can access internal resources which require permissions.
Export sipXecs Certificate Authority
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 The 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>.crtby clicking on it on the Certificate Authorities panel under System -> Certificates. Install this certificate on the remote system following whatever procedure it requires.
Import remote Certificate Authority
Similarly, the remote system's CA certificate must be imported into sipXecs. This is done on the Certificate Authorities panel under System -> Certificates. It may be necessary to restart the bridge as indicated on the screen but as this will be done after the next step, the message can be ignored here.
Configure TLS ports
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 (often 5061; for sipXecs to sipXecs, use 5081). Note that the remote system may need to be configured to send to port 5081 (the TLS port of a sipXbridge gateway). It is necessary to restart the bridge as indicated on the screen.
Configure TLS Peer permissions (if desired)
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:
| Code Block |
|---|
<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.To enable this mapping, add a TLS Peer under the Users menu, using as the TLS Peer Name the identity which the remote system presents in the SubjAltName field of its certificate (usually the SIP Domain or FQDN of the remote system). You can then specify permissions to be applied when any users from that system dial. 