cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
125
Views
0
Helpful
0
Comments
Meddane
VIP Rising star VIP Rising star
VIP Rising star

From version 3.5, Cisco Meeting Server can use other validations Hostname/IP Address If you are deploying or upgrading to version 3.6 (or 3.5). The database cluster nodes might fail to connect to each other. The reason is that each server will try to resolve the server's name (or hostname) of each node in the cluster, which is not available in version prior 3.5.

The database cluster verifymode <full/ca> command allows you to configure other validations. If the command is set to full, the Meeting Server along with certificates, verifies if the server identity name (hostname) matches with the name stored in the server certificates. While, if the command is set to ca, the Meeting Server will validate only the Certificate Authority.

Through this document, and using latest Cisco CMS version 3.6. You will learn How to design digital certificates for Database Clustering and the new validation process using the Server's identity name, for you project implementation.

Requirements:

  • CMS version 3.6
  • CMS1, CMS2 and CMS3 are planned to run a cluster database, CallBridge and WebBridge.
  • CMS1 must be configured with the Scheduler service.
  1. Cluster Database Configuration between cms1 cms2 and cms3
  2. WebAdmin CallBridge and WebBridge Certificates
  3. Enabling the Web Admin Service
  4. Enabling the CallBridge service
  5. Enabling the WebBridge 3 service
  6. CallBridge cluster configuration
  7. Enabling the Scheduler service

topo.PNG

 Cluster Database Configuration between cms1 cms2 and cms3

For the server certificate, you can use a multi-SAN certificate containing all the database server FQDN in the SAN attribute reducing thus the certificate management by using a single certificate for all nodes and all services.

For the client certificate, the Common Name (CN) must be set to postgres. When a server database receives a client certificate, they check that the CN field is equal to postgres to validate the authentication.

For database we need to generate two CSRs with the corresponding private keys, the client and the server.

Use one CMS to generates these two CSRs, once you get the server and client certificates from your CA, copy the two certificates with their private keys to all nodes using WinSCP.

For Server certificate use the following command, give a name for example dbcert, it is important to put the CN to the FQDN of the Master Database cms1 and the FQDN of the slaves in the SAN. For example: cms1.lab.local in the Common Name, cms2.lab.local and cms3.lab.local in the SAN.

cms1>pki csr dbcert CN:cms1.lab.local OU:CCNP O:Collaboration L:lab ST:local C:US subjectAltName:cms2.lab.local,cms3.lab.local

For Client certificate use the following command, give a name for example dbclt.

cms1>pki csr dbclt CN:postgres

On CMS1.

Configure the database client and server certificates created previously and named dbcert and dbclt. The Root-CA certificate is added to verify the validity of the client/ server certificates. Specify which interface to use for the database clustering and initialize the master database.

cms1>database cluster certs dbcert.key dbcert.cer dbclt.key dbclt.cer Root-CA.cer

cms1>database cluster localnode a

cms1>database cluster initialize

On CMS2 and CMS3.

Configure the database client and server certificates created previously and named dbcert and dbclt. The Root-CA certificate is added to verify the validity of the client/ server certificates, specify the interface to use, connect cms2 and cms3 to the master database cms1.

cmsx>database cluster certs dbcert.key dbcert.cer dbclt.key dbclt.cer Root-CA.cer

cmsx>database cluster localnode a

cmsx>database cluster join cms1.lab.local

Meddane_1-1664271631582.png

Meddane_2-1664271631584.png

On both cms1, cms2 and cms3, Verify the status of the database cluster.

The database status on CMS2 and CMS3. The status shown ERROR Cannot find primary node in cluster.

Meddane_3-1664271631588.png

Meddane_4-1664271631590.png

CMS2 and CMS3 fail to connect to the primary node CMS1. So what’s wrong here? let’s check the logs using the syslog follow command on CMS 2 and CMS3.

The output of CMS2’s log indicates the message CMS1: error could not translate host name “cms1 to address.

 CMS2 tries to resolve the server’s name CMS1 but cannot find the IP address 10.1.5.61.

Meddane_5-1664271631600.png

The output of CMS3’s log indicates the message CMS1: error could not translate host name “cms1 to address.

CMS3 tries to resolve the server’s name CMS1 but find the IP address 10.1.5.61.

Meddane_6-1664271631606.png

To solve the issues, we need DNS A record to resolve the name CMS1 to the IP address 10.1.5.61. Fortunately, Cisco Meeting server allows to create a DNS RR record to resolve the server’s name locally.

On CMS2 and CMS3, add a DNS RR record using the following commands.

Meddane_7-1664271631606.png

Meddane_8-1664271631607.png

Now let’s verify the database status on CMS2 and CMS3.

The output show that both are in the Connected status to the primary node CMS1 10.1.5.61.

But both nodes CMS2 and CMS3 fails to connect to each other.

Meddane_9-1664271631613.png

Meddane_10-1664271631621.png

Let’s verify the logs on CMS2 and CMS3.

CMS2 cannot find the IP address 10.1.5.63 of the hostname CMS3.

Meddane_11-1664271631631.png

CMS3 cannot find the IP address 10.1.5.62 of the hostname CMS2.

Meddane_12-1664271631639.png

On the primary node CMS1, verify the database status, we can see that the primary node fails to connect to CMS2 and CMS3.

Meddane_13-1664271631646.png

Let’s check the logs on CMS1. The same issue is displayed, CMS1 fails to find the IP addresses of the server’s name CMS2 and CMS3.

Meddane_14-1664271631661.png

To solve the issues, we need to add two DNS RR Records on CMS1 to resolve the server’s name of CMS2 and CMS3. Configure the following commands as shown below

Meddane_15-1664271631662.png

On CMS2, configure one DNS RR Record to resolve the server’s name of CMS3.

Meddane_16-1664271631663.png

On CMS3, configure one DNS RR Record to resolve the server’s name of CMS2.

Meddane_17-1664271631663.png

On CMS1 verify the DNS Record entries, it must have two DNS RR Records to resolve the server’s name of CMS2 and CMS3.

Meddane_18-1664271631667.png

On CMS2 verify the DNS Record entries, it must have two DNS RR Records to resolve the server’s name of CMS1 and CMS3.

Meddane_19-1664271631670.png

On CMS3 verify the DNS Record entries, it must have two DNS RR Records to resolve the server’s name of CMS1 and CMS2.

Meddane_20-1664271631672.png

Finally, the Database status on CMS1, CMS2 and CMS3 shows that the status is Connected for all nodes.

Meddane_21-1664271631678.png

Meddane_22-1664271631684.png

Note: From version 3.5, Cisco Meeting Server can use other validations Hostname/IP Address If you are deploying or upgrading to version 3.6 (or 3.5). The database cluster nodes might fail to connect to each other. The reason is that each server will try to resolve the server's name (or hostname) of each node in the cluster, which is not available in version prior 3.5.

The database cluster verifymode <full/ca> command allows you to configure other validations. If the command is set to full, the Meeting Server along with certificates, verifies if the server identity name (hostname) matches with the name stored in the server certificates. While, if the command is set to ca, the Meeting Server will validate only the Certificate Authority.

By default, the verifymode is set to ca as shown below.

Meddane_23-1664271631692.png

Meddane_24-1664271631698.png

Meddane_25-1664271631705.png

To enable the verifymode full, the nodes need to be removed from the cluster database.

On all CMS, execute the database cluster remove command.

Meddane_26-1664271631708.png

Meddane_27-1664271631712.png

Meddane_28-1664271631715.png

On all CMS, enable the verifymode full using the database cluster verifymode full command.

Meddane_29-1664271631716.png

Meddane_30-1664271631717.png

Meddane_31-1664271631717.png

On the primary node CMS1, run the database cluster initialize command.

Meddane_32-1664271631721.png

On CMS and CMS3, run the database cluster join cms1.lab.local command.

Meddane_33-1664271631725.png

Meddane_34-1664271631728.png

On CMS1, verify the database status, the verifymode full is now enabled. But the slaves CMS2 and CMS3 are not yet connected to the primary node.

Meddane_35-1664271631734.png

On CMS2 and CMS3, verify the database status, the verifymode full is now enabled.

The output of the database cluster status command displays ERROR: Cannot find primary in cluster.

Meddane_36-1664271631740.png

Meddane_37-1664271631746.png

To identify the problem, let’s execute the syslog follow command on CMS2 and CMS3.

On CMS2, we can see that the logs tell us that the server certificate for cms1.lab.local does not match hostname “cms1”. In other words, the hostname cms1 of the primary node is missing in the Subject Alternative Name SAN of the server certificate.

Meddane_38-1664271631757.png

The same error message is displayed on CMS3.

Meddane_39-1664271631765.png

To solve the issue, we need to generate another server certificate including the FQDN of all nodes cmsx.lab.local and the hostname of all nodes CMS1, CMS2 and CMS3.

cms1>pki csr dbcert36 CN:cms1.lab.local OU:CCNP O:Collaboration L:lab ST:local C:US subjectAltName:cms2.lab.local,cms3.lab.local,cms1,cms2,cms3

cms1>

Meddane_40-1664271631766.png

Copy the CSR and the private key into your PC and generate a new server certificate named for example dbcert36.cer.

Meddane_41-1664271631786.png

Verify the new dbcert36.cer certificate include the hostname CMS1, CMS2 and CMS3 along with the FQDNs. Ensure that the dbcert36.cer and the corresponding key is copied into all nodes.

Meddane_42-1664271631805.png

Before reconfiguring the cluster database with the new certificate, we need to remove all nodes from the cluster. Execute the database cluster remove command on all CMS.

cmsx> database cluster remove

On CMS1, configure the database server and client certificates named dbcert36 and dbclt. Run the database cluster initialize command.

cms1>database cluster certs dbcert36.key dbcert36.cer dbclt.key dbclt.cer Root-CA.cer

cms1>database cluster initialize

Meddane_43-1664271631806.png

Meddane_44-1664271631809.png

On CMS2 and CMS3, configure the database server and client certificates named dbcert36 and dbclt. Connect CMS2 and CMS3 to the master database CMS1 using the database cluster join cms1.lab.local command.

cmsx>database cluster certs dbcert36.key dbcert36.cer dbclt.key dbclt.cer Root-CA.cer

cmsx>database cluster join cms1.lab.local

Meddane_45-1664271631810.png

Meddane_46-1664271631812.png

Connect CMS2 and CMS3 to the master database CMS1.

Meddane_47-1664271631815.png

Meddane_48-1664271631819.png

Verify the database status on CMS1, the nodes CMS2 and CMS3 are still not connected to the primary node CMS1.

Meddane_49-1664271631823.png

On CMS2 and CMS3, the database status displays ERROR: postgresql has failed to start.

Meddane_50-1664271631829.png

Meddane_51-1664271631834.png

On CMS2 and CMS3, let’s execute the syslog follow command.

The output tells us that the IP address 10.1.5.61 of the primary node CMS1 is missing the server certificate. In other words, the IP address is not found in the SAN of the server certificate.

Meddane_52-1664271631843.png

Meddane_53-1664271631851.png

To solve the issue we need to generate another server certificate including the FQDN of all nodes cmsx.lab.local and the IP address 10.1.5.61 of the primary node CMS1.

cms1>pki csr dbcert3636 CN:cms1.lab.local OU:CCNP O:Collaboration L:lab ST:local C:US subjectAltName:cms2.lab.local,cms3.lab.local,cms1,cms2,cms3,10.1.5.61

Meddane_54-1664271631854.png

Copy the CSR and the private key into your PC and generate a new server certificate named for example dbcert3636.cer.

Verify the new dbcert36.cer certificate include the IP address 10.1.5.61 along with the FQDNs. Ensure that the dbcert3636.cer and the corresponding key is copied into all nodes.

Meddane_55-1664271631871.png

Before reconfiguring the cluster database with the new certificate, we need to remove all nodes from the cluster. Execute the database cluster remove command on all CMS.

cmsx> database cluster remove

On CMS1, configure the database server and client certificates named dbcert3636 and dbclt. Run the database cluster initialize command.

cms1>database cluster certs dbcert3636.key dbcert13636.cer dbclt.key dbclt.cer Root-CA.cer

cms1>database cluster initialize

Meddane_56-1664271631876.png

On CMS2 and CMS3, configure the database server and client certificates named dbcert3636 and dbclt. Connect CMS2 and CMS3 to the master database CMS1 using the database cluster join cms1.lab.local command.

cmsx>database cluster certs dbcert36.key dbcert36.cer dbclt.key dbclt.cer Root-CA.cer

cmsx>database cluster join cms1.lab.local

Meddane_57-1664271631879.png

Meddane_58-1664271631882.png

On CMS1, CMS2 and CMS3, verify the database status, the replication is now good.

Meddane_59-1664271631889.png

Meddane_60-1664271631896.png

Meddane_61-1664271631902.png

 

 

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers