“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 21-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”

1. 1. Which of the following is an SRV record that’s needed on the public DNS for an enterprise MRA deployment?

   1. _collab-edge._tls.<domain>

   2. _cisco-uds._tcp.<domain>

   3. _cuplogin._tcp.<domain>

   4. _sip._tcp.<domain>

2. 2. Which of the following ports needs to be opened between the DMZ and the public Internet for an MRA deployment?

   1. TCP 7001

   2. UDP 36000–36001

   3. TCP 2222

   4. TCP 8443

3. 3. Which of the following certificate pairs are required for an MRA deployment? (Choose two.)

   1. Public or enterprise CA certificate chain used to sign Expressway Core certificate

   2. Public or enterprise CA certificate chain used to sign Expressway Edge certificate

   3. CUCM Tomcat certificates or CA chain

   4. CUCM CallManager certificates or CA chain

   5. IMP Tomcat certificate or CA chain

   6. CUCM CAPF certificates

4. 4. What two ports are used with reverse proxy to allow inbound authenticated HTTPS requests for TFTP file download and SOAP API requests on the CUCM?

   1. TCP 2222 and TCP 8443

   2. TCP 6970 and TCP 8443

   3. TCP 7400 and TCP 8443

   4. TCP 5222 and TCP 8443

5. 5. When an endpoint located outside the corporate network is configured to register to the CUCM using MRA, what is the first communication sent by that endpoint?

   1. TLS handshake with the Expressway Edge to establish a trusted certificate verification

   2. Registration request sent to the CUCM through the Expressway Core and Edge servers

   3. DNS SRV Lookup for _collab-edge._tcp.<domain>

   4. DNS SRV Lookup for _cisco-uds._tcp.<domain>

6. 6. What service on the Cisco Unified Communications Manager should be enabled for MRA?

   1. Cisco CallManager Service

   2. Cisco TFTP Service

   3. Cisco AXL Web Service

   4. Cisco CTI Service

7. 7. Which of the following certificate options should be used on the Cisco Expressways for an MRA deployment?

   1. Self-signed certificates

   2. Single host/domain certificate

   3. Multiple subdomain wildcard certificates

   4. All of these answers are correct.

8. 8. What CUCM certificates are significant for Mobile and Remote Access? (Choose two.)

   1. Public or enterprise CA certificate chain used to sign Expressway Core certificate

   2. Public or enterprise CA certificate chain used to sign Expressway Edge certificate

   3. CUCM Tomcat certificates or CA chain

   4. CUCM CallManager certificates or CA chain

   5. IMP Tomcat certificate or CA chain

   6. CUCM CAPF certificates

9. 9. What is the recommended format for certificates on the Expressway servers for an MRA deployment?

   1. .cer or .crt format

   2. DER-encoded or Base64-encoded format

   3. DER-encoded format

   4. Base64-encoded format

   5. Any format can be used; there is no recommended format.

10. 10. Which of the following statements is true when configuring an MRA solution?

    1. Enabling MRA on the Expressway-C involves turning it on and configuring MRA Access Control settings, but enabling MRA on the Expressway-E only involves turning it on.

    2. Enabling MRA on the Expressway-E involves turning it on and configuring MRA Access Control settings, but enabling MRA on the Expressway-C only involves turning it on.

    3. MRA needs to be enabled only on the Expressway-C, not the Expressway-E.

    4. MRA needs to be enabled only on the Expressway-E, not the Expressway-C.

    5. Enabling MRA is exactly the same on both the Expressway-C and the Expressway-E.

11. 11. When nodes are being discovered on the Expressway-C for an MRA deployment, which of the following statements is true?

    1. The CUCM and CUCM IM and Presence nodes will not show Active until the traversal zones are configured and active.

    2. The CUCM IM and Presence nodes will not show Active until the traversal zones are configured and active.

    3. The CUCM node will not show Active until the traversal zones are configured and active.

    4. The CUCM and CUCM IM and Presence nodes will show Active immediately after they are discovered.

12. 12. What zone type should be selected on the Cisco Expressway Edge server when setting up the traversal component of the MRA solution?

    1. Traversal client zone

    2. Neighbor zone

    3. Traversal server zone

    4. Unified Communications Traversal

    5. DNS zone

    6. ENUM zone

Foundation Topics

Requirements for MRA

Cisco Collaboration Mobile and Remote Access (MRA) is a core part of the Cisco Collaboration Edge architecture. MRA allows endpoints, such as Cisco Jabber, UC phones, and CE software-based Telepresence endpoints, to securely utilize registration, call control, provisioning, messaging, and presence services that are provided by Cisco Unified Communications Manager when the endpoint is not within the enterprise network. Cisco Expressway series components are used to provide secure access and firewall traversal to the endpoints that register with the Cisco Unified Communications Manager.

Although the MRA solution operates in a similar fashion to a standard firewall traversal solution for B2B communications, there are some significant differences between them. First, MRA is only supported for SIP; there is no H.323 support in the MRA solution. Second, certificates are required for MRA; there is no way to build the traversal zones with a basic TLS or TCP SIP connection. TLS Verify is required for MRA. Third, some specific settings must be configured to enable MRA on the Expressway servers. Fourth, the zones created between the Cisco Expressway Core and Cisco Expressway Edge servers are not the same traversal client zone and traversal server zone used in a standard firewall traversal solution. Finally, the DNS SRV records that need to be created are different from what is required for a traditional firewall traversal solution.

MRA consists of four main components. One of the components is Firewall Traversal Services. MRA supports internal firewalls between Cisco Expressway Core and Cisco Expressway Edge, and an external firewall between Cisco Expressway Edge and the Internet. The firewall traversal capabilities of MRA use the same Assent traversal protocol of standard firewall traversal, but traversal chaining is not supported with MRA. Another component is DNS records. Internal and external DNS records are essential to enable endpoints to detect whether they should register directly with Cisco Unified Communications Manager or proxy registration through the MRA deployment. Certificates are another component of MRA. This solution provides secure communication over Transport Layer Security (TLS). Trust between TLS entities is established based on certificates. Implementing the necessary certificates for a public key infrastructure (PKI) is an important part of Cisco Collaboration MRA implementation. The last component in an MRA solution is reverse HTTPS proxy. To support secure data services, such as visual voicemail, contact photo retrieval, Cisco Jabber custom tabs, and so on, a reverse HTTPS proxy runs on the Cisco Expressway Edge server. If these services are not needed in an enterprise deployment of MRA, this component does not need to be set up. Once these components are set up, the MRA deployment can support two main features:

• Off-Premises Access: Cisco Collaboration MRA offers a consistent experience to clients, such as Cisco Jabber; UC phones; and Cisco DX, MX, SX, and Webex series endpoints, regardless of whether they are in the internal network or on an external network.

• Business-to-Business Communications: Cisco Collaboration Mobile and Remote Access offers secure communication to other businesses.

DNS A-Records and SRV Records

The DNS A-records and SRV records required for an MRA deployment are different from those required for a traditional firewall traversal solution. Additionally, different records need to be configured on an internal DNS and an external DNS. Before deploying an MRA solution, you will need to set up DNS first. Certificates cannot be created until DNS is configured because the PKI certificates depend on the DNS records of the different servers.

Cisco endpoints, especially Jabber, are programmed to use DNS so that they always search for the CUCM SRV record first. If the CUCM cannot be reached, they search for the Expressway-E. The Expressway-E can be located with an SRV lookup whether the endpoint is internal or external to the network, but the endpoint should not search for the Expressway unless it’s external to the corporate network. The endpoint should be able to locate the CUCM using an SRV lookup only if the endpoint is located within the corporate network. This is the reason that the endpoint will always search for the CUCM first. If that path fails, there is an alternative path for the endpoint to register through the Expressway servers using MRA.

The external DNS server must be configured with a _collab-edge._tls.<domain> service record so that external endpoints can discover that they should use Cisco Expressway-E for Mobile and Remote Access. Service records for secure SIP are also required, not specifically for Mobile and Remote Access, but for deploying a secure SIP service on the Internet. The service records must point to each cluster member of the Cisco Expressway-E server. Table 21-2 provides examples of the service records needed on a public DNS for two Cisco Expressway Edge servers clustered together.

Service	Protocol	Domains	Priority	Weight	Port	Target
_Collab-edge.	_tls.	Cisco.com	10	10	8443	Exp-e1.cisco.com
_Collab-edge.	_tls.	Cisco.com	10	10	8443	Exp-e2.cisco.com
_sips.	_tcp.	Cisco.com	10	10	5061	Exp-e1.cisco.com
_sips.	_tcp.	Cisco.com	10	10	5061	Exp-e2.cisco.com

The internal DNS server must be configured with a _cisco-uds._tcp.<domain> SRV record so that internal endpoints can discover that they should use Cisco Unified Communications Manager for direct registration. When using Cisco Unified Communications Manager IM and Presence Services, a _cuplogin._tcp.<domain> SRV record is also required on the internal DNS server. Just as the public DNS SRV records must refer to the Cisco Expressway-E servers, the internal DNS SRV records must refer to all call processing nodes of a Cisco Unified Communications Manager cluster, as well as with all Cisco Unified Communications Manager IM and Presence server SRV records. The internal DNS records must be available to all internal endpoints and to the Cisco Expressway Core. The Cisco Unified Communications Manager and Cisco Unified Communications Manager IM and Presence server SRV records must not be resolvable from outside the internal network. Otherwise, Cisco endpoints and soft clients will not use the necessary Mobile and Remote Access registration via Cisco Expressway-E. Table 21-3 provides examples of the SRV records needed on a private DNS for two Cisco Unified Communications Managers and two Cisco Unified Communications Manager IM and Presence servers clustered together.

Service	Protocol	Domains	Priority	Weight	Port	Target
_cisco-uds.	_tcp.	Cisco.com	10	10	8443	cucm1.cisco.com
_cisco-uds.	_tcp.	Cisco.com	10	10	8443	cucm2.cisco.com
_cuplogin.	_tcp.	Cisco.com	10	10	5061	imp1.cisco.com
_cuplogin.	_tcp.	Cisco.com	10	10	5061	imp2.cisco.com

Firewall Ports and Considerations

Cisco MRA uses a firewall traversal connection to allow inbound and outbound-initiated packet exchange, such as registration and call setup messages. MRA uses the Cisco Expressway Edge as the traversal server that is installed in a demilitarized zone (DMZ), and the Expressway Core is the traversal client that is installed on the internal network. Firewall traversal offers secure communication across firewalls as follows:

1. The Cisco Expressway-C initiates an outbound traversal connection through the internal firewall to specific ports on the Cisco Expressway-E with secure authentication credentials to establish a connection between the two servers.

2. Once the connection has been established, the Cisco Expressway-C sends keepalive packets periodically to Cisco Expressway-E to maintain the connection.

3. When Cisco Expressway-E receives an incoming message, whether it’s a registration or call setup message, from an outside endpoint, it sends the request to the Cisco Expressway-C through the existing traversal connection.

4. The Cisco Expressway-C then sends the message, such as a call setup request, to the Cisco Unified Communications Manager.

5. The Cisco Unified Communications Manager processes the call, and media streams are set up over the existing traversal connection.

For communication to flow through the firewall, appropriate ports must be opened to allow the flow of packets. The following ports must be opened on the internal firewall between the Expressway Core and the Expressway Edge:

• SIP: TCP 7001

• Traversal Media: UDP 36000 to 36001 (for small to medium VM deployments)

• Extensible Messaging and Presence Protocol (XMPP): TCP 7400

• HTTPS (Tunneled over Secure Shell [SSH] between Expressway-C and Expressway-E): TCP 2222

The following ports must be opened on the external firewall between the public Internet and the Cisco Expressway Edge in the DMZ:

• SIP: TCP 5061

• HTTPS: TCP 8443

• XMPP: TCP 5222

• TURN Server Control and Media: UDP 36012 to 59999 (if TURN relays are being used only)

The firewall administrator should open all of the ports from the preceding list before traversal zones are set up between the Expressway-C and the Expressway-E. Certificates must also be set up before traversal zones are created. Whether firewall ports are opened or certificates are established first doesn’t matter as long as both tasks are completed before configuring the traversal zones.

Certificate Requirements and Recommendations

Six different certificate pairs can be configured in an MRA deployment. However, only two pairs are required to set up the solution. The other four exist in an ideal environment for absolute security pertaining to registration and calling. The first certificate required is a public or enterprise CA certificate chain used to sign the Expressway-C. This is required to establish the traversal client zone connection. The second certificate required is a public or enterprise CA certificate chain used to sign the Expressway-E. This is also required to establish the traversal server zone connection. Both are absolutely required for TLS Verify to operate successfully. The traversal zones used for an MRA deployment will not work without these two certificate pairs. The root CA certificate for the Expressway-C certificate should be added to both the Expressway-C and the Expressway-E. The root CA certificate for the Expressway-E certificate should be added to both the Expressway-E and the Expressway-C. If both servers were signed by the same CA, then they will use the same root CA certificate; therefore, it needs to be added to each server only once.

The next optional certificate is the Cisco Unified Communications Manager Tomcat certificate or CA chain. The Tomcat certificate is for Tomcat trust. This certificate is used for MRA only when the Expressway-C is configured to use TLS Verify mode on Cisco Unified Communications Manager discovery. The Tomcat CA should be added to the Expressway-C, and the root CA certificate for the Expressway-C should be added to the Cisco Unified Communications Manager. If TLS Verify is not used on the Expressway-C for Cisco Unified Communications Manager discovery, this certificate is not needed.

Another optional certificate is the Cisco Unified Communications Manager certificate or CA chain used when the Cisco Unified Communications Manager is in mixed mode for end-to-end TLS. If this certificate is used, the Cisco Unified Communications Manager CA should be added to the Expressway-C, and the certificate CA for the Expressway-C should be added to the Cisco Unified Communications Manager.

The Cisco Unified Communications Manager IM and Presence Tomcat certificate or CA chain is similar to the Cisco Unified Communications Manager Tomcat certificate or CA chain. This certificate is used only when the Expressway-C is configured to use TLS Verify mode on Cisco Unified Communications Manager IM and Presence discovery. The Tomcat CA should be added to the Expressway-C, and the certificate CA for the Expressway-C should be added to the Cisco Unified Communications Manager IM and Presence server. If TLS Verify is not used on the Expressway-C for Cisco Unified Communications Manager IM and Presence discovery, this certificate is not needed.

The last optional certificate is the Cisco Unified Communications Manager Certificate Authority Proxy Function (CAPF) certificate. This certificate is used when remote endpoints authenticate using a Locally Significant Certificate (LSC). By default, LSC is signed by the CAPF, so the CAPF is the CA for phones in this scenario. However, when the CAPF is signed by an external CA, then the CAPF in this scenario acts as a subordinate CA or intermediate CA. The difference between a self-signed CAPF and CA-signed CAPF is that the CAPF is the root CA to LSC when doing a self-signed CAPF, but the CAPF is the subordinate or intermediate CA to LSC when doing a CA-signed CAPF. Table 21-4 identifies each of the six certificate pairs used in an MRA deployment.

Certificate Type	Core	Edge	Required
Public or enterprise CA certificate chain used to sign Expressway Core certificate	Yes	Yes	Yes
Public or enterprise CA certificate chain used to sign Expressway Edge certificate	Yes	Yes	Yes
CUCM Tomcat certificates or CA chain	Yes	No	No
CUCM CallManager certificates or CA chain	Yes	No	No
IMP Tomcat certificate or CA chain	Yes	No	No
CUCM CAPF certificates	No	Yes	No

HTTPS Reverse Proxy Settings

The Cisco MRA reverse proxy settings provide a mechanism to support visual voicemail access, contact photo retrieval, Cisco Jabber custom tabs, and other data applications. HTTPS reverse proxy is a function that is provided by the Cisco Expressway-E using port TCP 8443 for HTTPS traffic. Initial MRA configuration allows inbound authenticated HTTPS requests to the following destinations:

• TCP 6970 (TFTP file download) and TCP 8443 (SOAP API) to all discovered Cisco Unified Communications Manager nodes

• TCP 7400 (XCP router) and TCP 8443 (SOAP API) to all Cisco Unified Communications Manager IM and Presence nodes

Additional hosts can be added to the allow list on the Cisco Expressway-C.

Service Discovery

Before we show how to configure an MRA solution, we should more closely examine the MRA service discovery operation. This discussion will help administrators deploying this solution fully understand the dependencies between the components involved with an MRA solution. Figure 21-1 illustrates the way Cisco MRA service discovery operates on the public network. This example is for a Cisco Jabber client in phone-only mode. Additional steps involving the Cisco Unified Communications Manager IM and Presence Services would need to be included if additional Cisco Jabber services were being utilized.

Figure 21-1 assumes that the initiating endpoint, or Jabber client in this case, does not connect to the corporate network over a VPN. This is the reason that the initial DNS SRV lookup for the _cisco-uds._tcp.domain record fails. The service discovery occurs as follows. First, a Cisco Jabber client located outside the corporate network, and without a VPN connection, sends a DNS SRV record lookup for _cisco-uds._tcp.company.com to a public DNS server. The public enterprise DNS that manages company.com should not have such an SRV record, and therefore, the lookup fails. Next, the Cisco Jabber client sends another DNS SRV record lookup for _collab-edge._tls.company.com. This time the lookup is successful, and the address of the Cisco Expressway Edge is provided to the Jabber client in the DNS response.

Now the Cisco Jabber client can start the Mobile and Remote Access negotiation with the Cisco Expressway Edge server. A certificate is presented to Cisco Jabber and may need to be manually trusted by the user if it is not signed by a certificate authority server that the client PC already trusts. A TLS handshake is exchanged to establish a secure connection. The Cisco Expressway Edge will then act as a proxy for the Cisco Jabber client by passing messages that it receives from Cisco Jabber to Cisco Expressway Core through the firewall traversal connection and return messages from the Expressway Core to the Jabber client.

When a trusted connection between Cisco Jabber and Cisco Expressway Edge is established, Cisco Jabber tries to register to the services that are enabled on Cisco Expressway Core, which in this case is Cisco Unified Communications Manager. The Cisco Expressway Core will send a DNS SRV record lookup for _cisco-uds._tcp.company.com to the internal DNS. The internal DNS will respond with the address of the Cisco Unified Communications Manager. The Cisco Expressway Core will then forward the registration request from the Cisco Jabber client to the Cisco Unified Communications Manager. The Cisco Expressway Core will act as the proxy for messages between the Cisco Unified Communications Manager and the Expressway Edge.

Cisco Unified Communications Manager Settings for MRA

After an administrator has ensured that all the prerequisite components have been configured, which were covered in the first section of this chapter, the process for configuring MRA in a corporate network begins on the Cisco Unified Communications Manager. The following seven steps must be completed to deploy Mobile and Remote Access endpoints.

Step 1. Make sure that the Cisco AXL Web Service is activated on the publisher node.

1. From Cisco Unified Serviceability, navigate to Tools > Service Activation.

2. From the Server drop-down menu, select the publisher node and click Go.

3. Under the Database and Admin Services section, confirm that the Cisco AXL Web Service is Activated.

4. If the service is not activated, check the corresponding check box and click Save to activate the service.

Step 2. Optionally, configure region-specific settings for MRA endpoints. The default settings may be sufficient in many cases, but if you expect MRA endpoints to use video, you may want to increase the Maximum Session Bit Rate for Video Calls within your region configuration. The default setting of 384 kbps may be too low for some video endpoints, such as the DX series.

1. From Cisco Unified CM Administration, navigate to System > Region Information > Region.

2. Perform any one of the following:

   • Click Find and select a region to edit the bit rates.

   • Click Add New to create a new region.

3. In the Modify Relationship to Other Regions section, configure a new setting for the Maximum Session Bit Rate for Video Calls, such as 6000 kbps.

4. Configure other fields in the Region Configuration window as necessary. For more information on the fields and their configuration options, see the system’s online help.

5. Click Save.

Step 3. After you have created a new region, assign your region to the device pool that your MRA endpoints use.

1. From Cisco Unified CM Administration, navigate to System > Device Pool.

2. Do either of the following:

   • Click Find and select the existing device pool to edit.

   • Click Add New to create a new device pool.

3. Enter a device pool Name.

4. Select a redundant Cisco Unified Communications Manager Group.

5. Assign a Date/Time Group. This group includes the Phone NTP references that may have been set up for MRA endpoints.

6. Assign a region from the Region drop-down menu to the device pool that MRA endpoints will use.

7. Complete the remaining fields in the Device Pool Configuration window as necessary. For more information on the fields and their configuration options, see the system’s online help.

8. Click Save.

Step 4. Use this procedure to set up a Phone Security Profile to be used by MRA endpoints. You must apply this profile to the phone configuration for each of your MRA endpoints.

1. From Cisco Unified CM Administration, navigate to System > Security > Phone Security Profile.

2. Click Add New.

3. From the Phone Security Profile Type drop-down list, select your device type, such as the Cisco Unified Client Service Framework for a Jabber application.

4. Click Next.

5. Enter a Name for the profile. For MRA, the name must be in FQDN format and must include the enterprise domain.

6. From the Device Security Mode drop-down list, select Encrypted. This field must be set to Encrypted; otherwise, Expressway will reject the communication.

7. Set the Transport Type to TLS.

8. Leave the TFTP Encrypted Config check box unchecked for the following phones because MRA will not work for these phones with this option enabled: DX Series, IP Phone 7800, or IP Phone 8811, 8841, 8845, 8861 and 8865.

9. Complete the remaining fields in the Phone Security Profile Configuration window. For more information on the fields and their configuration options, see the system’s online help.

10. Click Save.

Step 5. This step is for Cisco Jabber only. Set up an MRA Access Policy for Cisco Jabber users. Cisco Jabber users must be enabled with MRA access within their user profiles in order to use the MRA feature. The Jabber desktop client includes Cisco Jabber for Windows users and Cisco Jabber for Mac users. The Jabber mobile client includes Cisco Jabber for iPad and iPhone users and Cisco Jabber for Android users.

1. In Cisco Unified CM Administration, navigate to User Management > User Settings > User Profile.

2. Click Add New.

3. Enter a Name and Description for the user profile.

4. Assign a Universal Device Template to apply to users’ Desk Phones, Mobile and Desktop Devices, and Remote Destination/Device Profiles.

5. Assign a Universal Line Template to apply to the phone lines for users in this user profile.

6. If you want the users in this user profile to be able to use the self-provisioning feature to provision their own phones, do the following:

   • Check the Allow End User to Provision Their Own Phones check box.

   • In the Limit Provisioning Once End User Has This Many Phones field, enter a maximum number of phones the user is allowed to provision. The maximum is 20.

7. If you want Cisco Jabber users associated with this user profile to be able to use the Mobile and Remote Access feature, check the Enable Mobile and Remote Access check box. By default, this check box is selected. When you uncheck this check box, the Jabber Policies section is disabled, and the No Service Client Policy option is selected by default. This setting is mandatory only for Cisco Jabber users. Non-Jabber users do not need this setting to be able to use MRA.

8. Assign the Jabber policies for this user profile. From the Jabber Desktop Client Policy and Jabber Mobile Client Policy drop-down list, choose one of the following options:

   • No Service: This policy disables access to all Cisco Jabber services.

   • IM & Presence Only: This policy enables only instant messaging and presence capabilities.

   • IM & Presence, Voice and Video Calls: This policy enables instant messaging, presence, voicemail, and conferencing capabilities for all users with audio or video devices. This is the default option.

9. Click Save.

Step 6. This step is also for Cisco Jabber users only. The user policy that was set up previously must be applied to the appropriate end user. Remember from Chapter 16, “LDAP Integration with Cisco Unified Communications Manager,” and Chapter 17, “Registering SIP Endpoints to the Cisco Unified Communications Manager,” that end users can be set up manually, from an import using LDAP or using BAT. Because each method was covered in these chapters, we will not cover the steps to apply the user policy to the end user at this point in the book. Refer to these other chapters if a review is necessary.

Step 7. Configure and provision endpoints that will use the MRA feature. This step is achieved by ensuring the corresponding settings above are applied to the phone through TFTP when registration is attempted. Refer to Chapter 7, “Cisco Unified Communications Phones,” Chapter 8, “Cisco Telepresence Endpoints,” and Chapter 9, “Endpoint Registration,” for a review in configuring endpoints registering to the Cisco Unified Communications Manager.

High volumes of Mobile and Remote Access calls may trigger denial of service thresholds on the Cisco Unified Communications Manager. The reason is that all the calls arriving at the Cisco Unified Communications Manager are from the same Expressway-C cluster. If necessary, Cisco recommends that you increase the level of the SIP Station TCP Port Throttle Threshold to 750 kbps. To make this change from Cisco Unified CM Administration, navigate to System > Service Parameters, and select the Cisco CallManager service.

Another requirement on the Cisco Unified Communications Manager must be configured before MRA is set up on the Expressway Core. An application user must be configured on the Cisco Unified Communications Manager that has been assigned the AXL API Access role. The Cisco Expressway Core will need this level of access into the Cisco Unified Communications Manager; otherwise, communication will fail. The default administrator account can be used, but Cisco recommends a new application user account be created for each application service that’s set up with the Cisco Unified Communications Manager. The same is also true for MRA deployments that include the Cisco Unified Communications Manager IM and Presence services. The corresponding IM and Presence user must have the Standard AXL API Access role assigned.

TLS Verify Requirements

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both frequently referred to as “SSL,” are cryptographic protocols that provide communications security over a computer network. This TCP protocol aims primarily to provide privacy and data integrity between two communicating hosts or applications.

Client/server applications such as web browsers, email, and VoIP commonly use the TLS protocol to prevent eavesdropping and tampering of information. The protocols these applications use must choose to use or not to use TLS. The easiest way to segregate the information is to use different port numbers for unencrypted traffic, such as port 80 for HTTP, and TLS-encrypted traffic, such as port 443 for HTTPS. The connection is secure because symmetric cryptography is used to encrypt the transmitted data. The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiation at the start of the session. The server and client negotiate the details of which encryption algorithm and cryptographic keys to use before the first byte of data is transmitted. Identification is usually in the form of digital “certificates” that contain the server name, the trusted certificate authority (CA), and the server’s public encryption key. The identity of the communicating parties can be authenticated using this public-key cryptography (asymmetric cryptography) to ensure only the intended recipient can decrypt the traffic. The negotiation of a shared secret is both secure and reliable against eavesdroppers and attacks, including man-in-the-middle attacks. The connection ensures integrity because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.

Once the client and server have agreed to use TLS, they negotiate a stateful connection by using a handshake procedure. The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and presents a list of supported ciphers and hash functions. From this list, the server picks a cipher and hash function that it also supports, and it informs the client of the decision. The server then identifies itself with its digital certificate, which can contain the server name, the trusted certificate authority, and the server’s public encryption key. The client then validates the certificate before proceeding. Public-key encryption is used to share the pre-master secret via the use of RSA or Diffie-Hellman key exchange. This process generates a random and unique session key for encryption and decryption that has the additional property of forward secrecy, which protects past sessions against future compromises of secret keys or passwords.

Remember that the server is validated because the client initiates the secure connection. The client side confirms that the server is who it claims to be and whether it can be trusted with the use of certificates. The client receives the digital certificate from the server side of the TLS negotiation, but the identity must be verified before proceeding. The server certificate may contain the name of the certificate holder. This name is checked against the Common Name (CN) or the Subject Alternative Name (SAN). Also, additional information like a serial number, expiration dates, revocation status, a copy of the certificate holder’s public key (which is used for encrypting messages and digital signatures), and the digital signature of the certificate-issuing authority. This information identifies to the client that the certificate is signed by a certificate authority. If you trust this certificate authority, you can verify using the CA’s public key that it really did sign the server’s certificate. To sign a certificate yourself, you need the private key, which is only known to the CA of your choice. This way an attacker cannot sign a certificate himself and falsely claim to be the server. When the certificate has been modified, the sign will be incorrect, and the client will reject it. Figure 21-2 illustrates the steps involved with a security handshake between a client and a server.

Mutual TLS authentication is also an option that can be chosen. In this type of authentication, both parties authenticate each other through verifying the provided digital certificate so that both parties are assured of the others’ identity. Mutual TLS is very similar to the normal process of the client handling the verification of the server’s certification but including the additional step of the client providing a certificate. This process allows the server side to authenticate the client, allowing both parties to trust each other.

Server-to-server connections rely on mutual TLS for mutual authentication. In the Cisco Collaboration infrastructure, some examples would be a secure connection between endpoints and the Cisco Unified Communications Manager, Cisco Unified Communications Manager SIP trunks to other clusters, and even Cisco Unified Communications Manager SIP trunks with a Cisco Expressway Core.

To secure voice and video traffic, you must understand multiple technologies. Remember, the most common VoIP communication used today is SIP. For secure transmissions of SIP messages, the protocol may be encrypted with TLS. Media identification and negotiation are achieved with the Session Description Protocol (SDP). SDP can also be used for the master key exchange. For the transmission of media streams, SIP employs the Real-time Transport Protocol (RTP) or Secure Real-time Transport Protocol (SRTP). Unencrypted SIP generally uses port 5060, whereas TLS-encrypted SIP utilizes port 5061.

Trusted certificates are very important to create secure connections. This part of the process is where the certificate authority comes into the solution. These certificate authorities are widely used both on the public Internet and private networks to issue digital certificates containing identity credentials binding them to SSL or TLS cryptography keys. However, because these CAs are trust anchors, they must conduct several checks into the identity of the applicant. The checks correlate to the class and type of certificate being applied for. Table 21-5 identifies each of these classes of certificates available and which of these certificates are supported on Cisco Collaboration servers.

For domain validation (DV) certificates, the CA checks only the right of the applicant to use a specific domain name. No company identity information is vetted, and no information is displayed other than encryption information within the Secure Site Seal. For organization validation (OV) certificates, the CA checks the right of the applicant to use a specific domain name and conducts some vetting of the organization. Additional vetted company information is displayed to customers when clicking the Secure Site Seal, giving enhanced visibility into who is behind the site and associated enhanced trust. For extended validation (EV) certificates, the certificate authority checks the right of the applicant to use a specific domain name, and in addition, it conducts a thorough vetting of the organization. The issuance process of EV certificates is strictly defined in the EV guidelines, as formally ratified by the CA/Browser Forum in 2007, that specify all the steps that are required for a CA before issuing a certificate. They include

• Verifying the legal, physical, and operational existence of the entity

• Verifying that the identity of the entity matches official records

• Verifying that the entity has exclusive rights to use the domain that is specified in the EV SSL certificate

• Verifying that the entity has properly authorized the issuance of the EV SSL certificate

EV certificates are available for all types of businesses, including government entities and both incorporated and unincorporated businesses. A second set of guidelines, the EV Audit Guidelines, specify the criteria under which a CA needs to be successfully audited before issuing EV certificates. The audits are repeated yearly to ensure the integrity of the issuance process.

Because people are constantly searching the Internet, the browsers constantly are checking the websites that are visited against a CA to authenticate web pages. As an example, web browsers like Google Chrome, Firefox, and Internet Explorer maintain lists of certificate authorities they consider trustworthy. When you access what should be a secure website, the site presents its security certificate to your browser. If the certificate is up-to-date and from a trusted certificate authority, you will see the trusted secure connection. If the certificate lacks any of the requirements, you will see that your web browser will not establish a connection until you accept the risks and proceed.

With the Cisco Collaboration products, only certain certificate options are supported. The Expressway-E will require a public certificate because it is the most public-facing part of the Cisco Collaboration solution and needs to be trusted by outside sources like clients and other businesses. A single host/domain certificate option will suffice with any type of validation desired. If multiple hosts, domains, or subdomains need to be covered, multiple Subject Alternative Name (SAN) certificates are required. Note that the wildcard certification is not supported on the Cisco Expressway series.

In the Cisco Collaboration architecture, it is easy to secure all enterprise network information simply by creating a private network behind the security of a firewall. However, companies may need to work with other businesses or clients for their day-to-day operations. To place voice and video calls outside the network and connect to other networks securely, Cisco offers the Expressway Series. This robust and secure solution comes equipped with Cisco’s proprietary Assent protocol that allows secure firewall-traversal technology for any-to-any collaboration.

Creating Certificates for MRA

The Cisco Unified Communications Manager does not require an MTLS connection to the Expressway Core for the MRA deployment; therefore, this section will cover only the detailed steps on how to sign and load certificates on the Expressway Core and Edge servers. Once all MRA settings have been configured on the Expressway-C, traversal zones can be configured between the Expressway-E and the Expressway-C. TLS Verify is required for these zones, so certificates must be used. If the certificates come from the same CA, the root CA will be the same on both Expressway servers. However, if a different CA is used for the Expressway Core than what is used on the Expressway Edge, the root CA certificate must be uploaded to both Expressways to identify where the certificates were signed. Information required when signing certificates is the same regardless of the CA being used. The instructions provided in this book on how to sign certificates are through a Microsoft certificate server.

The Expressway-C and Expressway-E have a tool built into them that can generate a certificate signing request (CSR). The CSR contains all the information the CA will need to sign the certificate. When the CA signs the certificate, it’s important that it is done with a template that contains the server and client authentication extensions. The certificate generation process seems to confuse a lot of customers and engineers. The basic requirement to get this set up is fairly straightforward. The first consideration is what to use for a CA. There are two commonly used approaches. One method is to use OpenSSL, and the other is to use Active Directory Certificate Services (ADCS). Setting up ADCS in a Microsoft environment is very complex and would warrant discussion that goes beyond the scope of this book. The OpenSSL method is well defined in the VCS Certificate Creation and Use Deployment Guide; therefore, this section will focus only on how to use an ADCS after it has already been configured on a Windows server.

Step 1. On the Expressway, generate a certificate signing request (CSR). For the most part, the following steps pertain to both the Expressway-C and Expressway-E servers.

1. On the Expressway, navigate to Maintenance > Security > Server Certificate.

2. Click Generate CSR to access the Generate CSR page.

3. Fill out the appropriate details, and then click the Generate CSR button:

   • Key Length: (Recommended to use 2048 or higher)

   • Country: (Optional) Abbreviations OK

   • State or Province: (Optional) Abbreviations OK

   • Locality (Town Name): (Optional)

   • Organization (Company Name): (Optional)

   • Organization Unit: (Optional)

   

   Make a note of the Common Name that is autopopulated on the Generate CSR page. This is automatically created using the DNS settings, so the DNS settings on the Expressway must be accurate. The Common Name on the Expressway-C will be used as the Subject Name when the traversal zone is configured on the Expressway-E. The Common Name on the Expressway-E will be used as the Peer address when the traversal zone is configured on the Expressway-C. There are a few points of interest for the Expressway-C certificate. If the IM and Presence Service has already been added to the Expressway-C, a prepopulated Chat Node Alias will appear. This is required for XMPP federation deployments that intend to use both TLS and group chat, such as conference-2-StandAloneCluster5ad9a.%yourdomain%. Also, if the solution is being deployed using TLS between the Expressway-C and Cisco Unified Communications Manager, ensure that the Subject Alternative Name on the certificate contains the names in FQDN format of all the phone security profiles in the Cisco Unified Communications Manager that are configured for encrypted TLS, such as CSFJabber.tftp.com.

4. Under the Certificate Signing Request section, click Show (PEM file). Copy the entire contents of the PEM file to a notepad. Be sure to include the -----Begin Certificate Request----- and -----End Certificate Request----- lines. The contents of this PEM file will be used to sign the Expressway-C certificate using Microsoft ADCS. Figure 21-3 illustrates the settings that need to be configured when generating a CSR.

Step 2. Sign the CSR with the Microsoft ADCS.

1. Browse to the ADCS web interface at https://<IP_address>/certsrv.

2. Log in and select Request a Certificate.

3. Click the Submit a Certificate Request by Using a Base-64-Encoded CMC or PKCS #10 File, or Submit a Renewal Request by Using a Base-64-Encoded PKCS #7 File option.

4. Paste the copied contents from the Expressway-C Server PEM file into the Base-64-Encoded Certificate Request box.

5. Some ADCS servers have a Certificate Template field. If this option is available, choose the most appropriate one for your certificate purpose, and then click Submit.

   

6. The next page that appears will allow you to download the signed certificate in either a DER-encoded or Base64-encoded format. DER stands for Distinguished Encoding Rules, which is a binary format. Base64 is an encoding method that converts binary to plain ASCII text. Some scenarios prevent copying and transferring data in binary, so plain text is needed. Therefore, it is recommended to choose the Base 64 Encoded option before downloading the certificate.

   

7. After the signed certificate has been downloaded, a copy of the root CA certificate will need to be downloaded as well. The root CA certificate establishes a trusted chain that begins at the root CA, or in this case the ADCS, through the root CA certificate, and ends at the certificate that was signed. The use of the root CA certificate provides an added level of security. From the ADCS page, click Home in the top-right corner of the screen.

8. Click the Download a CA Certificate, Certificate Chain or CRL link.

9. Select the Base 64 radio button and click Download CA Certificate.

10. When prompted, save the certificate into the same location as the signed server certificate.

Step 3. After both certificates have been obtained, return to the Expressway and apply the certificates.

1. Navigate to Maintenance > Security > Server Certificate. This is the same page where the CSR request was generated.

2. Scroll to the bottom of the page, select Browse, and choose the server certificate that was just signed by ADCS.

3. Click Upload Server Certificate Data. Depending on what version of Expressway is being used, the web browser may prompt the administrator to reauthenticate again. A restart may also be required to complete the certificate installation. If so, do not restart the Expressway until the root CA has been installed. Figure 21-4 illustrates the Server Certificate page on an Expressway-C.

   

4. Navigate to Maintenance > Security > Trusted CA Certificate.

5. Select Browse and choose the root CA certificate that was downloaded from ADCS.

6. Click the Append CA Certificate button. A restart of the server may be required.

7. Navigate to Maintenance > Restart Options and click Restart. When prompted to confirm, click OK. The restart will take two to three minutes on the Expressways. Figure 21-5 illustrates the Trusted CA Certificate page.

Now you need to repeat all these steps on the other Expressway. There are some points of interest for the Expressway-E certificate. If multiple domains are being used, be sure that each domain configured for the Cisco Unified Communications Manager is a part of the Subject Alternative Name on the certificate. As with the Expressway-C certificate, if you are deploying the solution with XMPP federation, the same chat node aliases will be required. For successful validation of received certificates, the Cisco Expressway servers must trust the CA that issued certificates and will be exchanged during the TLS handshake. Therefore, if a different CA was used for the Expressway Core and Expressway Edge, the root CA certificate must be added to the counterpart server. For example, if an ADCS was used to sign the Expressway-C CSR, and a public CA was used to sign the Expressway-E CSR, the public root CA certificate will need to be loaded on both servers, as well as the ADCS root CA certificate.

Initializing MRA on Expressway Servers

Before configuring a Cisco MRA solution, make sure certain settings are already configured within the Collaboration environment. All endpoints being used with the MRA solution need to be running a version of software that supports this feature. Cisco Jabber 9.7 or later must be used. Starting with this version, Cisco Collaboration Mobile and Remote Access functionality is enabled by default, and the client can identify that it must connect through Cisco Expressway Edge when there is no response to the _cisco-uds._tcp.<domain> DNS SRV record lookup request. Administrators should also ensure that the local DNS and public DNS servers are configured with the required SRV records for MRA functionality. The _cisco-uds._tcp.<domain> and _cuplogin._tcp.<domain> SRV records must not be resolvable from outside the internal network. The Cisco Expressway-C and Cisco Expressway-E should be configured with initial configurations, such as system name, DNS, and NTP at a minimum. Cisco Unified Communications Manager should be configured to allow registrations from Cisco Jabber clients.

Most of the configuration steps to deploy an MRA solution are performed on the Cisco Expressway Core and Cisco Expressway Edge servers. The Cisco Unified Communications Manager Tomcat certificate that must be installed on the Cisco Expressway Core must be obtained from the Cisco Unified Communications Manager server or servers. These certificates are required only if MTLS is being used between the Expressway Core and the Cisco Unified Communications Manager. The following is an overview of the steps to configure MRA on the Expressway servers:

Step 1. Enable MRA on both Cisco Expressways (Core and Edge).

Step 2. Configure MRA on the Cisco Expressway Core.

1. Configure a SIP domain to route registrations to the Cisco Unified Communications Manager.

2. Install the Cisco Unified Communications Manager Tomcat certificate (if TLS Verify is being used).

3. Discover the Cisco Unified Communications Manager from the Expressway Core.

Step 3. Configure a secure traversal zone connection between the Cisco Expressway Edge and the Cisco Expressway Core.

1. Generate a CSR on both Expressways.

2. Sign both CSRs.

3. Install the signed CA and root CA on each respective Cisco Expressway (Core and Edge).

4. Configure a Unified Communications Traversal (Server) Zone on the Expressway Edge.

5. Configure a Unified Communications Traversal (Client) Zone on the Expressway Core.

To enable the Cisco Collaboration Mobile and Remote Access on the Expressway-C, navigate to Configuration > Unified Communications > Configuration. Change the Unified Communications Mode to Mobile and Remote Access. All other settings can be left as their defaults. Click Save when finished. On the Expressway-E, the menu path is the same to enable MRA, but the menu options are slightly different. Change the Unified Communications Mode to Mobile and Remote Access and leave all other settings as their defaults. Figure 21-6 illustrates some of the settings available when MRA is enabled on the Expressway-C. Figure 21-7 illustrates the settings available when MRA is enabled on the Expressway-E. Use these figures to compare and contrast the differences between the settings.

No more MRA-specific settings have to be configured on the Expressway-E. However, several settings need to be configured on the Expressway-C. First, navigate to Configuration > Domains. If a domain was configured previously, an administrator can click that domain to edit the settings. If not, you will need to create a new domain by clicking the New button. When MRA is not in use, there is only one field to configure in the Domains menu; that is the domain itself. When MRA is enabled, several settings will need to be configured. First, configure the domain in the Domain Name field. In the next section, an administrator will need to enable all the services for this domain that will need to be supported using MRA. The options include SIP Registrations and Provisioning on Expressway, SIP Registrations and Provisioning on Unified CM, IM and Presence Service, and XMPP Federation. Figure 21-8 illustrates the DNS settings related to MRA on the Expressway-C.

Before adding any servers to the Expressway-C, such as the Cisco Unified Communications Manager, you will need to add the Tomcat certificate first. This certificate needs to be added only if TLS Verify is being used for communication between the Cisco Unified Communications Manager and the Expressway-C. Navigate to Maintenance > Security > Trusted CA Certificate. Under the Upload section, click Browse and select the Tomcat certificate that’s intended for this server. Click Open to return to the Trusted CA Certificate page and click the Append CA certificate button to load the certificates. Check the list of certificates to ensure the Tomcat certificate was uploaded successfully.

Now the Cisco Unified Communications Manager can be discovered by the Expressway-C. Navigate to Configuration > Unified Communications > Unified CM Servers. Click the Add button and enter the following parameters. If TLS Verify is being used, the Unified CM Publisher Address must be the URL of the Cisco Unified Communications Manager publisher. If TLS Verify is not being used, this address can be the URL or the IP address of the Cisco Unified Communications Manager Publisher. The Username and Password settings should correspond to the AXL application user credentials created on the Cisco Unified Communications Manager. Verify TLS Verify Mode is set to On if TLS Verify is being used. If not, change this setting to Off. When these settings are saved, the Expressway-C will automatically create a neighbor zone to the Cisco Unified Communications Manager. The last setting on this page is the AES GCM Support setting. If it is enabled, the neighbor zone generated for the Cisco Unified Communications Manager will support AES GCM algorithms to encrypt and decrypt media passing through the zone. The default is Off but can be switched to On depending on how the Cisco Unified Communications Manager is configured to handle media encryption. When finished, click the Add Address button. This will return you to the Unified CM Servers page. In the Currently Found Unified CM Nodes section, verify that the discovery status is displayed as Active. Figure 21-9 illustrates the settings that need to be configured when adding a Cisco Unified Communications Manager to the Expressway-C for discovery.

Administrators can navigate to Configuration > Zones > Zones and verify that the neighbor zone to the Cisco Unified Communications Manager has been created. Clicking into this zone will display all the settings, but they will be grayed out and cannot be changed. There is also a search rule associated with this zone that was automatically created. Navigate to Configuration > Dial Plan > Search Rules to verify this rule exists. These settings will also be grayed out. The Cisco Unified Communications Manager IM and Presence Service and Cisco Unity Connections servers can also be discovered by the Expressway-C if these servers are being used. However, be aware that the status will not show Active on these until the traversal zones are configured and active. Navigate to Configuration > Unified Communications > IM and Presence Service Nodes or Configuration > Unified Communications > Unity Connection Servers to configure the discovery settings for these servers in the same manner as the Cisco Unified Communications Manager.

Collaboration Traversal Zones and Search Rules

After the MRA settings have been configured and the certificates have been exchanged, the next step is to create traversal zones between the Expressway servers. Traversal zones should always be configured on the traversal server first, in this case the Cisco Expressway-E.

Step 1. Configure the traversal server zone on the Expressway E.

1. On the Expressway-E, navigate to Configuration > Authentication > Local Database and add new credentials.

2. Navigate to Configuration > Zones > Zones and add a new traversal server zone. Because this zone is specifically for MRA, the zone Type should be set to Unified Communications Traversal.

3. Supply the username from the authentication database. Notice that no H.323 settings are available under this zone type. The reason is that H.323 is not supported using MRA. If H.323 calls are to be supported, another traversal zone must be established using the standard traversal zone setup.

   To enable Unified Communications Services on this traversal zone, you must configure the SIP settings to use TLS with TLS Verify Mode enabled, and Media Encryption Mode must be set to Force Encrypted. All of these settings default to the aforementioned parameters, and they cannot be changed. Therefore, these settings will not appear in the Unified Communications Traversal Zone settings page.

4. Supply the SIP TLS Verify Subject Name. The Subject Name must match the subject name or the alternative subject name specified in the Cisco Expressway Core server security certificate. This is the Common Name you should have noted from the CSR of the Expressway Core. If you did not write it down, it is the full URL of the Expressway Core.

5. Set the Accept Proxied Registrations setting to Allow.

6. Set the Authentication Policy to Treat as Authenticated.

7. Click Create Zone when finished.

Step 2. To route calls from the Expressway Edge to the Expressway Core through this traversal server zone, you need to configure a search rule as well.

1. Navigate to Configuration > Dial Plan > Search Rules.

2. Click New, configure the settings, and then click Create Search Rule. Figure 21-10 illustrates some of the Unified Communications traversal zone settings on the Expressway-E.

Once you’ve configured the traversal server zone, you can configure the traversal client zone on the Cisco Expressway-C to initiate communication between the two servers.

Step 3. Configure the traversal server zone on the Expressway Core.

1. On the Expressway-C, navigate to Configuration > Zones > Zones and add a new traversal client zone. Again, since this zone is specifically for MRA, you should set Zone Type to Unified Communications Traversal.

2. Supply the Username and Password that were configured in the Authentication database on the Expressway-E.

3. Enter the port that will be used to establish a connection and keep the connection alive. This port needs to match the SIP keepalive port on the Expressway Edge.

4. Set the Accept Proxied Registrations setting to Allow.

5. Set the Authentication Policy to Treat as Authenticated.

6. In the Location Peer 1 Address field, enter the URL of the Expressway Edge.

   Because TLS Verify is being used, this setting must be in the URL format. It must also match the Common Name you should have noted from the CSR of the Expressway Edge. If the IP address of the Expressway-E is used, communication will fail between the traversal client and the traversal server.

7. Click Create Zone when finished.

8. Verify that the state of the zone is Active after saving the client zone.

Step 4. To route calls through the Expressway Edge using this traversal client zone, you need to configure a search rule here as well. However, because calls may be routed to any possible destination, you can use an Any Alias rule. Figure 21-11 illustrates some of the Unified Communications Traversal Zone settings on the Expressway-C.

The MRA deployment is now complete. You can test these settings by trying to register endpoints located both inside the enterprise network and outside the network. If the zones created will support calls as well, test the deployment by trying to place a few calls. Try calling between an internally registered endpoint and an externally registered endpoint. Then try calling between an internally registered endpoint and an endpoint located in another business network. Also, try calling between an externally registered endpoint and an endpoint located in another business network. You should try all call attempts from both directions: initiated from inside out, and initiated from outside in.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 32, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 21-6 lists a reference of these key topics and the page numbers on which each is found.

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

A-Record

ADCS

Asymmetric Cryptography

Base64 Encoded Format

CA

CSR

DER Encoded Format

Diffie-Hellman Key Exchange

DNS

DV Certificates

EV Certificates

Firewall

HTTPS Reverse Proxy

MRA

OV Certificates

PKI

Root CA

Root CA Certificate

RSA

SRV

SSL

Symmetric Cryptography

TLS

TLS Verify

Traversal Chaining

Traversal Client Zone

Traversal Server Zone

Traversal Zone

Unified Communications Traversal Zone

Q&A

The answers to these questions appear in Appendix A. For more practice with exam format questions, use the Pearson Test Prep Software Online.

1. 1. What are the five differences between a standard firewall traversal solution and MRA?

2. 2. What are the four prerequisites that MRA depends on to be configured?

3. 3. What are the six steps in a basic service discovery from an endpoint using the MRA solution?

4. 4. What are the three main categories for deploying an MRA solution?