During the TLS handshake, a standard TLS client checks the validity of the TLS server certificate. However, this implementation could potentially bring in 'man-in-the-middle' attack, when Jabber deploys over the internet. During login, if an hacker presents Jabber their own server with a valid TLS certificate instead of the expressway, then Jabber in the absence of further control, it accepts that certificate, and the user can be connected to a malicious system. To avoid this issue, Jabber performs an additional validation step which is not part of the standard TLS, it checks that the domain entered during the login process by the user matches the Subject Alternative Names (SAN) included in the certificate. Only if it matches, Jabber tries to connect to the Expressway. Any SAN entry made in the certificate requires to be signed by the Certification Authority (CA), which means only the company that owns the domain will be able to get a CA-signed certificate.

Any SAN entered in the certificate is subject to validation from the Certification Authority (CA), so only the company that owns the domain is able to get a CA-signed certificate. It makes it much more difficult to steal the identity of the Expressway.

In Dedicated Instance Cisco manages the certificates for the UC applications and hence the certificates are signed with the Cisco provided domain only, for e.g.customer.amer.wxc-di.webex.com. However, for an end user to login to the Jabber client with the customer email address, can be achieved by the following options:

Option 1 - Jabber initial end user login

The users can be communicated that for their initial login to the Jabber client, they need to use the Cisco’s voice service domain user@customer.amer.wxc-di.webex.com in the initial screen followed by their username or company’s email address and password in the next screen. Since this is most simplest approach, the steps are illustrated more in detail:

  1. The user needs to enter the Cisco provided voice service domain, for e.g. user@customer.amer.wxc-di.webex.com in the initial Jabber login screen as show in the figure below.


    The customer’s voice service domain is shared by Cisco for every region when the service activation is completed. This information is part of the access details document shared in the Webex App space. For more details, see Dedicated Instance Service Activation.

  2. The user is prompted to enter the username or company’s email id along with the password for authentication as shown in the figure below.


    If SSO is enabled, similar operation will be performed by the IdP.

    Subsequent logins post this does not require the user to perform Step 1, unless the Jabber client is reset.

Option 2: Use the voice service domain

With this approach the Jabber client can differentiate between the customer’s domain entered by the user and the service discovery domain. In the installer if the voice service domain is set to customer.amer.wxc-di.webex.com, the user can login to the Jabber client using their company’s email address and Jabber can still do the service discovery based on the value set in voice service domain. This will remove the necessity to provide voice service domain in the initial jabber login as per the above option.

For windows:

Tools such as Microsoft Orca can be used to create custom Jabber installers, that can include the voice service domain. The users can be instructed to use these installers for Jabber client.

For MAC, iOS, Android:

Tools such as MDM can be used to create custom Jabber installers, that can include the voice service domain.

Option 3: Use the configuration URL

A configuration URL can be used to set Jabber parameters before the initial login, such as the voice services domain. An example of a configuration URL: ciscojabber://provision?ServicesDomain=customer.com&VoiceServicesDomain=customer.amer.wxc-di.webex.com

By clicking the above link, the voice service domain can be set in Jabber client running on MAC, Android or iOS devices.


This configuration is not persistent, the user would need to click on the link again if the Jabber client is reset.

It is worth to note that Webex App does not have the above requirement; the client performs the domain check, but it is possible to provision the voice service domain in the Control Hub. When the Webex App connects to Webex, it gets the voice services domain and registers the same. For more information regarding Webex App In-app calling setup, see Webex Application Integration with Dedicated Instance for In-App Calling.

Useful Link: On-Premises Deployment for Cisco Jabber 14.0