The Expressway-C connector host must be registered to Cisco Webex in order for hybrid services to work.
Expressway-C is deployed in the internal network, and the way it registers to the cloud is through an outbound HTTPS connection—the
same type that is used for any browser that connects to a web server.
Registration and communication to the Cisco Webex cloud uses TLS. Expressway-C is the TLS client, and the Cisco Webex cloud is the TLS server. As such, Expressway-C checks the server certificate.
The certificate authority signs a server certificate using its own private key. Anyone with the public key can decode that
signature and prove that the same certificate authority signed that certificate.
If Expressway-C has to validate the certificate provided by the cloud, it must use the public key of the certificate authority
that signed that certificate to decode the signature. A public key is contained in the certificate of the certificate authority.
To establish trust with the certificate authorities used by the cloud, the list of certificates of these trusted certificate
authorities must be in the Expressway's trust store. Doing so, the Expressway can verify that the call is truly coming from
the Cisco Webex cloud.
With manual upload, you can upload all relevant certificate authority certificates to the trust store of Expressway-C.
With automatic upload, the cloud itself uploads those certificates in the trust store of Expressway-C. We recommend that you
use automatic upload. The certificate list might change, and automatic upload guarantees that you get the most updated list.
If you allow automatic installation of certificate authority certificates, you are redirected to https://admin.webex.com (the management portal). The redirection is done by the Expressway-C itself without any user intervention. You, as the Cisco Webex administrator, must authenticate through an HTTPS connection. Soon after, the cloud pushes the CA certificates to the Expressway-C.
Until the certificates are uploaded to the Expressway-C trust store, the HTTPS connection cannot be established.
To avoid this problem, the Expressway-C is preinstalled with Cisco Webex-trusted CA certificates. Those certificates are only used to set up and validate the initial HTTPS connection, and they don't
appear in Expressway-C trust list. Once the certificates of the trusted certificate authorities are pulled from the cloud
through this initial HTTPS connection, those certificates are available for platform-wide usage; then, they appear in the
Expressway-C trust list.
This process is secure for these reasons:
Requires admin access to Expressway-C and to https://admin.webex.com. Those connections use HTTPS and are encrypted.
Certificates are pushed from the cloud to Expressway using the same encrypted connection.
This list shows the certificate authority certificates that the Cisco Webex cloud currently uses. This list might change in the future:
C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root
C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root
C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certificate Authority
C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2
C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2
C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary
C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority
A list of certificate authority certificates is also required for the Expressway-E in the traversal pair. Expressway-E communicates
with the Cisco Webex cloud using SIP with TLS, enforced by mutual authentication. Expressway-E trusts calls coming from and going to the cloud,
only if the CN or SAN of the certificate presented by the cloud during TLS connection setup matches the subject name configured
for the DNS zone on Expressway ("callservice.webex.com"). The certificate authority releases a certificate only after an identity check. The ownership of the callservice.webex.com domain must be proved to get a certificate signed. Because we (Cisco) own that domain, the DNS name "callservice.webex.com" is direct proof that the remote peer is truly Cisco Webex.