Zoom Node Deployment Considerations

This section contains several examples of how Zoom Node can support various Service Modules like Zoom Meetings Hybrid and Zoom Phone Local Survivability (ZPLS). Typical deployments with a dedicated IP address can look like the following collection of diagrams.

Every service deployed on Zoom Node requires a unique IP address. A Zoom Node will have up to five (5) IP addresses assigned to it if the Node has been assigned a specific address for management and one for each service deployed (up to four) on the Node. A Zoom Node running a single service (such as ZPLS) can be deployed with a single IP address if the Node and service are assigned to share the same IP address.

Several deployment options are shown below. Note the number of IPs and certificates (CN/SANs) for the various deployment options.

Option 1: Zoom Meetings Hybrid deployed with dedicated IPs and hostnames

This above image summarizes the IP and certificate configuration requirements for deploying Zoom Meetings Hybrid in on-premises or hybrid cloud environments.

The table below breaks down the example Node and includes its active proxy and MMR Service Modules:

The above image outlines the minimum configuration needed to deploy Zoom Phone Local Survivability (ZPLS). ZPLS enables continued phone service availability in the event of internet or cloud disruption by running survivability logic locally on a Zoom Node VM.

The following hostnames must be configured in DNS and included in the TLS certificate:

• node1.customer.com

• zplsl.customer.com

Hostname Functional Mapping

TLS Certificate Configuration

Certificates must be generated or procured (public or private CA) to include both the CN and SANs listed above. This enables proper TLS validation for secure intra-module communication.

IP Address Requirements

While five (5) IPs are required for general deployment, only two (2) IP addresses are actively used in the ZPLS deployment: one per module, running on a dedicated Node VM.

How do these diagrams compare? The first image shows an example of a Zoom Meetings Hybrid deployment. The second image shows an example of a Zoom Phone Local Survivability deployment.

You can share the first IP/hostname between the OS and first module, if desired, to reduce the number of IP addresses, hostnames, and Subject Alternative Names (SANs) required.

Option 2: Zoom Meetings Hybrid deployed with a shared IP and shared hostname

This configuration repeats the Node structure as seen in the Option 1 Zoom Meetings Hybrid diagram. However, in this deployment, the Node OS shares its IP address with the first deployed module (typically the Zoom Connector Proxy, ZCP). This results in reduced IP utilization while maintaining TLS and functional requirements.

The following hostnames must be configured in DNS and included in the TLS certificate:

• zcp1.customer.com

• mmr1.customer.com

• mmr2.customer.com

• mmr3.customer.com

Hostname Functional Mapping

TLS Certificate Configuration

Certificates must include all SANs to support secure TLS communication between the Zoom Node and the installed Zoom modules.

IP Address Requirements

The above image shows a minimal ZPLS deployment where the Node OS shares its IP address with the installed ZPLS module. This is the only scenario in the Zoom Node framework where a single-host TLS certificate is valid.

The following hostname must be configured in DNS and included in the TLS certificate:

• zplsl.customer.com

Hostname Functional Mapping

TLS Certificate Configuration

In this configuration, a single-host certificate is sufficient since both the OS and ZPLS module share the same hostname and IP address.

IP Address Requirements

Decide which certificate management method works best for your deployments

Each Service Module deployed on Zoom Node requires a valid certificate signed by a publicly trusted Certificate Authority (CA) from Zoom Node's certificate trust list. This includes well-known public authorities.

Zoom Node offers two certificate management methods:

• Auto PKI: This innovative solution automates secure certificate enrollment and renewal with publicly trusted Certificate Authorities (CAs). Zoom covers the costs associated with enrollment and renewal.

• Bring Your Own Certificate (BYOC): With this option, you provide your own certificates, signed by any major publicly trusted CA. You handle certificate enrollment and renewals. Additional considerations apply regarding Zoom Node's potential for up to five hostnames/SANs when using customer-provided certificates, which are detailed further below.

Automatic Certificate Management with Auto PKI

Zoom Auto PKI installs valid publicly trusted CA certificates automatically for the Zoom Node platform, as well as any modules deployed on it. Certificate renewal is automatically handled as well. This simplifies certificate management for all services and the Zoom Node itself.

Understanding Auto PKI Certificate Enrollment and Renewal

The following scenario can help you understand how certificate enrollment and renewal works.

For example: An administrator has deployed a new Node instance. Each instance requires a valid x509 certificate. The certificate’s private key must never leave this instance.

The Auto PKI process performs the following steps:

1. Template Retrieval: Pulls all supported configuration templates, including options for multiple CA providers, from the Auto PKI service in the Zoom cloud.

2. IP Address Collection: Gathers all IP addresses used by services running on the Node and sends them to the Auto PKI service in the Zoom cloud.

3. DNS Name Provisioning: The Auto PKI cloud service returns a set of DNS names in the format <instance_identifier>.<customer_identifier>.zoomonprem.com. These domains are configured with A/AAAA records.

4. Reserved DNS Name Request: Requests a reserved DNS name in the format rsvd-<randomized_string>.<customer_identifier>.zoomonprem.com.

5. Certificate Request Generation: Generates an x509 certificate request, using the DNS names from the third step in the SAN field and the reserved name from the fourth step in the Common Name (CN) field.

6. Certificate Issuance: Sends the Certificate Signing Request (CSR) to the Auto PKI service in the Zoom cloud. This service then works with CA vendors to issue the certificate, which includes the SAN list and CN field from the previous step.

7. Local Storage: Writes the newly issued x509 certificate from the last step and its corresponding private key (generated earlier) to local storage, making them available for services running on the Node instance.

Auto PKI simplifies certificate management on Zoom Node by automatically monitoring expiration dates and requesting new certificates, eliminating the need for manual renewal.

Bring Your Own Certificates (BYOC)

You can install your own valid, publicly signed certificates on Zoom Node using the local web interface. You can do this either during the initial installation or at a later time. The process will be familiar to those accustomed to installing certificates on web-based applications.

If you opt to use your own certificates, remember that the certificate will be on a server communicating with multiple hostnames. Therefore, the certificate type you choose must support encryption for traffic originating from more than one hostname (certificate CN). All hostnames used for Node and any deployed services must be publicly resolvable by Zoom's cloud services.

Zoom recommends two kinds of certificates:

• Wildcard Certificate

• Multi-SAN Certificate (also known as Multi-Domain Certificate, SAN Certificate, or UCC Certificate)

Wildcard Certificates: Recommended for simplicity

A wildcard certificate can encrypt traffic from any hostname in the domain. For example: A wildcard certificate like *.customer.com can encrypt traffic from host1.customer.com and host2.customer.com or any name within .customer.com.

When you deploy Zoom Node and install the wildcard certificate, it will automatically encrypt traffic for any services you deploy on the Node with the requirement that all Services deployed use a Fully Qualified Domain Name (FQDN) from the wildcard domain.

This minimizes the effort to deploy services on the Node: you don't need to know the names of the services before you deploy them. However, you need to know the service names if using the multi-SAN Certificate method.

Multi-SAN, Multi-Domain, SAN, or UCC Certificates

A Multi-SAN certificate is necessary for Zoom Node because it encrypts traffic from five (5) hostnames. A onetime request for this certificate requires prior knowledge of all necessary information, including planned Node names and the names of all services slated for deployment on the Node. For example, with a module like ZPLS, only one ZPLS module is deployed per Node, so only one additional SAN is needed for the ZPLS service hostname.

The following table can be used an example:

This example is of a typical configuration, with one Node hosting ZPLS on the same IP plus two additional services on separate IPs. Replace “company.com” with your actual domain and use your network's IP addresses.

DNS Resolution Requirements

Zoom requires the hostnames to be publicly resolvable so that two-way trust can be established. All Zoom Node hostnames and all service hostnames deployed on the Nodes must be included in the DNS Zone.

If your organization runs separate internal and external DNS services or domains, the Zoom Node hostnames need to be hosted in a zone resolvable by your external DNS servers (can be restricted to only resolve for Zoom IP ranges). Your internal Zoom users and the Zoom cloud need to communicate using the same set of hostnames.