Custom Certificates for Mutual TLS Authentication between Expressway-E and the Cloud

Document created by Cisco Documentation Team on Apr 12, 2016Last modified by Cisco Documentation Team on Sep 15, 2016
Version 7Show Document
  • View in full screen mode

For extra security, you might want your Expressway to communicate with the cloud through certificates that were signed by a certificate authority.

If your Expressway-E SIP TLS certificate was signed by a private certificate authority (or a certificate authority that is not trusted by the Cisco Collaboration Cloud default trust list), then you can upload the certificate authority's root certificate to your organization's custom trust list on the Services > Hybrid Call > Settings page.

  • To use a custom certificate, you must claim and verify any domain that is used in your organization. Any claimed domains must be present on the Expressway-E certificate as a subject alternate name (SAN).

  • When a SIP-TLS transaction takes place between the Cisco Collaboration Cloud and your Expressway-E, the cloud analyzes the domains that are listed in your Expressway-E SAN list. The cloud then tries to find the organization that claimed any domains in this list.

  • When the cloud finds a match, it can use the custom certificate list that is configured in your organization.

  • If the Expressway-E certificate does not contain your domain as a SAN, or if you did not verify the domain, the cloud cannot identify which certificate store to use. The result is that TLS negotiations fail, even if you have supplied the correct certificates on the Services > Hybrid Call > Settings page.

Certificate Revocation Lists

If your private certificate authority inserts a certificate revocation list (CRL), ensure that the CRL locations are reachable from the public internet. If a CRL is present but not reachable, the Cisco Collaboration Cloud cannot verify whether the certificate was revoked.

In this case, the certificate must not try to access a CRL.




Attachments

    Outcomes