Avid® MediaCentral Platform ServicesCreating Self-Signed Certificates for Clustered Systems

Important Information

The procedures in this document only apply to a cluster installation. If you have a single MCS server, refer to the instructions in the “Creating Self-Signed Certificates for Single Servers” document.

During the installation process, a dedicated IP address and hostname were assigned to the cluster. Because the clients do not know which node is the owner of the database, they must use the cluster host name or IP address when connecting to MediaCentral Platform Services (MCS) through their web browser.

However, the SSL certificate that is automatically generated by Jetty picks up the FQDN of the machine on which it is generated. It does not pick up the cluster name (or IP address). Furthermore, each node in the cluster will generate a certificate with a different embedded FQDN.

n Jetty picks up the FQDN from the DNS Search Path entry in the server’s Linux resolve.conf file. This value was configured in the “Configuring the Hostname and Static Network Route” process as detailed in the Avid MediaCentral Installation and Configuration Guide.

As a result of the different SSL certificates served by the cluster, each with different “issued to” values, name mismatches will be repeatedly flagged by the browser. This will be the case even if the certificate is otherwise trusted. Thus, using automatically generated SSL certificates in a cluster setup is not possible.

To eliminate the “name mismatch” errors, a new certificate is generated on one of the cluster nodes, explicitly specifying the cluster’s FQDN. Once created, that certificate is copied to all other cluster nodes.

Generating a self-signed certificate in a cluster involves the following steps:

• Identifying the Cluster Nodes

The certificate is created on a non-master node and later replicated to the master node.

2

• Generating the Certificate

The new SSL certificate and keystore are generated for each non-master node in the cluster.

• Updating the application.properties File

The custom password information is added to the MCS configuration file.

• Verifying the Certificate through a Failover

A manual failover is initiated to ensure that the certificate is accessible from both the master and slave nodes.

Once the certificate is created on the MCS server, you must also configure the web browser (Chrome or Safari) on the MediaCentral UX client systems to use the certificate.

See the following sections to configure the client’s web browser:

• Configuring Google Chrome

• Configuring Safari

Identifying the Cluster Nodes

In this procedure you will identify the names and role of each node in the cluster.

To identify the cluster nodes:

1. Log into Linux on any node in the cluster as the root user.

2. Start the Cluster Resource Monitor:

crm_mon

This returns the status of all cluster-related services on all nodes. The following is an example of a four-node cluster:============Last updated: Thu Jul 16 16:20:01 2015Last change: Mon Jul 13 10:06:51 2015 via crm_attribute on wavd-mcs02Stack: classic openais (with plugin)Current DC: wavd-mcs04 - partition with quorumVersion: 1.1.11-97629de4 Nodes configured, 4 expected votes24 Resources configured============

Online: [ wavd-mcs01 wavd-mcs02 wavd-mcs03 wavd-mcs04 ]

Clone Set: AvidConnectivityMonEverywhere [AvidConnectivityMon] Started: [ wavd-mcs01 wavd-mcs02 wavd-mcs03 wavd-mcs04 ]AvidClusterMon (lsb:avid-monitor): Started wavd-mcs01MongoDB (lsb:mongod): Started wavd-mcs01

3

Redis (ocf::avid:redis): Started wavd-mcs01 Resource Group: postgres postgres_fs (ocf::heartbeat:Filesystem): Started wavd-mcs01 AvidClusterIP (ocf::heartbeat:IPaddr2): Started wavd-mcs01 pgsqlDB (ocf::avid:pgsql_Avid): Started wavd-mcs01 Master/Slave Set: ms_drbd_postgres [drbd_postgres] Masters: [ wavd-mcs01 ] Slaves: [ wavd-mcs02 ] Clone Set: AvidAllEverywhere [AvidAll] Started: [ wavd-mcs01 wavd-mcs02 wavd-mcs03 wavd-mcs04 ]AvidIPC (lsb:avid-interplay-central): Started wavd-mcs01AvidUMS (lsb:avid-ums): Started wavd-mcs01AvidUSS (lsb:avid-uss): Started wavd-mcs01AvidACS (lsb:avid-acs-ctrl-core): Started wavd-mcs01 Clone Set: AvidICPSEverywhere [AvidICPS] Started: [ wavd-mcs01 wavd-mcs02 wavd-mcs03 wavd-mcs04 ]

The master node can be identified in a number of ways:

- It is always the owner of the AvidClusterIP resource.

- It is listed as “master” under the drbd_postgres resource.

- It will be the owner of multiple other resources such as: MongoDB, AvidIPC, AvidUMS and more.

The slave node can be identified as “slave” under the drbd_postgres resource. It will also run additional load-balancing resources such as AvidICPS and AvidAll.

The load-balancing nodes will only run load-balancing resources such as AvidICPS and AvidAll.

3. Make note of the hostnames of the master, slave and load-balancing nodes.

4. Press CTRL-C to exit crm_mon.

Generating the Certificate

In this procedure you use the Java keytool utility to generate a new self-signed certificate, explicitly specifying the contents of the file. The utility also generates the private-public key pair associated with a certificate, and the keystore where they are all stored.

To create the self-signed certificate:

1. On any non-master node in the cluster, log into Linux as the root user.

2. Use the Linux ping command to obtain the Fully Qualified Domain Name (FQDN) of the MCS cluster from DNS:

ping <cluster_name> -c 2

4

In the above command, <cluster_name> is the host name assigned to MCS cluster. “-c 2” indicates that you want to ping the server twice (a count of 2).

Record the hostname, FQDN and IP address. These values will be required when generating the new certificate.

3. Change to a writable directory, for example, /tmp.

cd /tmp

4. Begin the process of generating a new self-signed certificate and inserting it into the Jetty keystore:

keytool -keystore jetty.keystore -alias jetty -genkey -keyalg RSA -storepass <password> -keypass <password> -validity 10950 –ext san=dns:<cluster_name>,dns:<cluster_fqdn>,ip:<cluster_ip>

For simplicity, it is suggested you use the same password for both storepass and keypass.

Take note of the password used. You will need it when updating the application.properties file later in this document.

The meaning of each parameter is presented in the following table:

Parameter Description

-keystore The path and name of the keystore file.

The default name of the file is jetty.keystore (recommended).

If a different name and/or path is used for your keystore, additional changes would be required in the MediaCentral application.properties file.

-keysize The length of the public-private key pairs generated.

Optional for self-signed certificates. However, since December 2010, most Certificate Authorities require a key length (-keysize) of 2048 bits.

-alias A human-readable identifier for the certificate within the key store.

Keystores can hold multiple certificates. A simple alias makes the certificate easy to refer to in any subsequent operations.

-genkey The option to generate a new certificate and public-private key pair.

-keyalg The SSL algorithm used for the certificate.

The default is RSA.

You can use a different algorithm, but you must then change the settings in the application.properties file.

-storepass A password protecting the certificate within the keystore.

-keypass A password protecting the keystore itself.

5

5. A series of questions appears, used by Jetty to populate the certificate. This information is visible when end-users examine the certificate using a browser.

6. Answer the questions according to the following table:

n For a self-signed certificate, only the first question indicating the FQDN (e.g. mcs.mydomain.com) requires an answer.

-validity A validity period for the certificate.

The default validity period is 30 years (365x30=10950).

-ext san dns:<cluster_name> Used to specify the short hostname of the cluster as identified in DNS.

dns:<cluster_fqdn> Used to specify the FQDN of the cluster as identified in DNS.

ip:<cluster_ip] Used to specify the IP address of the cluster as identified in DNS.

You may use one, two or all three of these options in this command. All three options are recommended to allow users to access the MCS cluster by any of the three identifiers.

Parameter Description

Question Answer

What is your first and last name? Enter the fully qualified domain name (FQDN) of the cluster (e.g. mcs.mydomain.com).

This is the FQDN of the cluster, not the FQDN of an individual server within the cluster.

This response is mandatory.

6

7. The final question will ask you to confirm your responses. Enter “yes” (without the quotes) to complete the creation of the new keystore and self-signed certificate.

8. Copy the new Jetty keystore containing the freshly generated self-signed certificate to its final location:

cp jetty.keystore /opt/avid/etc/avid/avid-interplay-central/ssl/jetty.keystore

You will be prompted to overwrite the exiting keystore file. Enter “y” to confirm that you want to overwrite the default jetty.keystore.

9. Copy the new jetty keystore file from this node to all other nodes using the Linux secure copy (scp) command:

scp [user]@[source-hostname]:[source file with path] [destination-hostname]:[path to destination]

The following is presented as an example of the above command:

scp root@wavd-mcs04:/opt/avid/etc/avid/avid-interplay-central/ssl/

jetty.keystore wavd-mcs03/opt/avid/etc/avid/avid-interplay-central/ssl/

You may be informed that the server could not verify the authenticity of the destination and asked if you want to continue. Type “yes” to continue.

Enter the password for the root user of the destination server.

You may be prompted to overwrite the existing keystore. Type “yes” to overwrite.

What is the name of your organizational unit? The department within your company issuing the request (e.g. IT).

This response is optional.

What is the name of your organization? The legal name of your company (e.g. Avid Technology Inc.).

This response is optional.

What is the name of your City or Locality? The city or jurisdiction where you are located.

This response is optional.

What is the name of your State or Province? State, province, department, prefecture, etc.

This response is optional.

What is the two-letter country code for this unit?

The ISO country code.

This response is optional.

Question Answer

7

10. Use the Linux md5sum command to check that the jetty.keystore files are identical on each node:

md5sum /opt/avid/etc/avid/avid-interplay-central/ssl/jetty.keystore

Repeat the command on each node and compare the results.

Updating the application.properties File

Once the certificate is created, you must update the MediaCentral configuration to make use of the new certificate. The application.properties file is used to add custom configuration changes to the MediaCentral system.

In this procedure you obtain obfuscated (disguised) passwords from Jetty and add them to the MediaCentral application.properties file. This allows MediaCentral to make use of the SSL certificate.

Be sure to add both the “password” and the “keypassword” to the file (similar to the following):

system.org.ops4j.pax.web.ssl.password=OBF\:1c3x1mf71jnb1sov1jk71mbf1c35system.org.ops4j.pax.web.ssl.keypassword=OBF\:1c3x1mf71jnb1sov1jk71mbf1c35

n Plain-text passwords can also be used. For reasons of security it is recommended you use obfuscated passwords instead.

To update the application.properties File:

1. Using the same node you used in the previous step, log in as the root user.

2. Obtain an obfuscated string for the password(s) used to create the keystore and certificate in the previous procedure:

java -cp /opt/avid/avid-interplay-central/lib/org.eclipse.jetty.jetty-util.jar org.eclipse.jetty.util.security.Password <password>

Where <password> is the password you used to protect the certificate within the keystore.

n Do not copy / paste this command from this document as some characters may be lost in the process.

The system responds by outputting the password, the obfuscated password string (OBF:) and its MD5 hash value (MD5:).

8

The following represents sample output. It is the string following OBF that is needed (“XXXXXX” indicates the password you entered is echoed to the command line in plain-text):

XXXXXX

OBF:1c3x1mf71jnb1sov1jk71mbf1c35

MD5:4c88dafcf38a9b90b1e32efe798f95f0

3. If you used a different password to protect the Jetty keystore itself, repeat the step for the second password.

4. Edit (or create) the MediaCentral application.properties file using a text editor such as vi:

vi /opt/avid/etc/avid/avid-interplay-central/config/application.properties

In most cases, this file will not exist. Create the file using vi and add the lines indicated in the steps below.

You can examine the contents of the default file in the following directory: /opt/avid/avid-interplay-central/config. However, do not make your changes in that file since it will be overwritten any time you upgrade MCS. Make your changes in the file you create in the /opt/avid/etc/avid/avid-interplay-central/config, as indicated in this step.

n If you use the default file as a model, the one you create should only contain the values you wish to override.

5. Locate (or add) the entry for the password used to protect the certificate (sometimes referred to as the “export” password

system.org.ops4j.pax.web.ssl.password=OBF\:1c3x1mf71jnb1sov1jk71mbf1c35

Replace the obfuscated string (displayed as “1c3x1mf71jnb1sov1jk71mbf1c35” above) with the one you generated.

n Those upgrading from ICS 1.2 or earlier (i.e. from a Windows server to a Linux server) please note the following difference in Linux syntax. If you are re-using the obfuscated string from the Windows server, be sure to add the Linux “escape” character (“\”) in front of the colon in the entry for the password.

A plain text entry would look like the following:

system.org.ops4j.pax.web.ssl.password=<visible password>

n For reasons of security it is recommended you use obfuscated passwords.

9

6. Locate (or add) the entry for the password used to protect the Jetty keystore:

system.org.ops4j.pax.web.ssl.keypassword=OBF\:1c3x1mf71jnb1sov1jk71mbf1c35

Replace the obfuscated string (displayed as “1c3x1mf71jnb1sov1jk71mbf1c35” above) with the one you generated.

7. Save and exit the file:

<Esc>:wq

8. Copy the application.properties file to each machine in the cluster using the Linux secure copy (scp) command:

scp [user]@[source-hostname]:[source file with path] [destination-hostname]:[path to destination]

The following is presented as an example of the above command:

scp root@wavd-mcs04:opt/avid/etc/avid/avid-interplay-central/config/application.properties wavd-mcs03/opt/avid/etc/avid/avid-interplay-central/config/

9. Once the application.properties file has been copied to all nodes, the AvidIPC cluster resource must be restarted to enable the new passwords (command can be issued from any node):

crm resource restart AvidIPC

Once the resource has restarted, the master node can begin serving the new certificate.

n Be aware that this step will disconnect any users currently working on the system.

Verifying the Certificate through a Failover

A successfully created certificate can be verified through the cluster failover process. During a failover, a new master node is assigned to the cluster and the node reads the certificate information. The new master node should start all resources without any errors or failures.

If the certificate is not read correctly by the node, there are no obvious error messages regarding the Jetty keystore configuration. The AvidIPC resource (avid-interplay-central service) simply fails to start. If a node does not start up correctly, verify the configuration of the keystore and application.properties file.

For instructions on triggering a failover, see “Testing Cluster Failover” in the MediaCentral Platform Services Installation and Configuration Guide.

10

Configuring Google Chrome

Trusting a self-signed certificate in Google Chrome is a two-step process. First, you export the certificate from the browser. Then the certificate is imported into the Trusted Root Certification Authorities store. Both these procedures are performed via Chrome menus.

n Please note that the process and examples below are subject to change may not reflect the options available in the latest Chrome browser.

To export the certificate from the browser:

1. Launch Google Chrome and enter the URL of the MCS cluster in the address bar.

http://<FQDN>, where <FQDN> is the Fully Qualified Domain Name of the MCS cluster.

n You are automatically redirected to the secure (SSL) connection (https).

2. Click on the “Advanced” link to expand this dialog.

3. Click the “Proceed to hostname (unsafe)” link to access the MediaCentral UX login.

4. Click on the padlock icon in the Chrome address bar.

11

Details pertaining to the warning appear in a pop-up window:

5. Click on the Certificate Information link.

A dialog pertaining to the SSL certificate appears.

6. In the Certificate dialog, click on the Details tab.

7. Click the “Copy to File…” button.

This starts the Certificate Export wizard.

8. Follow the prompts in the wizard to export the certificate from the browser, saving it in a convenient temporary location, such as the local desktop.

Once you have exported the certificate, it must be added to the Trusted Root Certification Authorities store, as described in the following process.

12

To add the certificate to the trusted certificates store:

1. Click on Google Chrome Customize icon on the top-right edge of the address bar and choose Settings:

2. On the Chrome Settings page, click the “Show advanced settings...” link at the bottom of the page. This expands the page to reveal additional settings.

3. Click the “Manage Certificates...” button within the HTTPS / SSL settings category.

4. In the Certificates dialog, click the “Import…” button.

The Certificate Import Wizard will appear.

5. Click Next on the Import Wizard’s Welcome page.

6. In the File to Import dialog, click the Browse button to locate your certificate.

7. Select the certificate file that you exported in the previous procedure and click Open.

8. Click Next to proceed to the next window.

9. Click the Browse button in the Certificate Store window.

13

10. Browse to the “Trusted Root Certification Authorities” store and click OK to select the store.

11. Click Next to proceed to the next window.

12. The Certificate Import Wizard displays the information you have specified. Click Finish to import the certificate to the browser.

13. A final security warning dialog appears, asking you to confirm installation of the certificate. Click the Yes button to confirm the import of the certificate.

Successful import will result in the following window. Click OK to complete the process.

14. Restart Chrome and enter the FQDN of the MCS server or cluster in the address bar

The browser should connect to MediaCentral UX without issuing certificate warnings.

14

Configuring Safari

In Mac OS, you must add the self-signed certificate to the Mac OS system keychain. This process is completed through the Safari browser.

To add a certificate to the trusted certificates store:

1. Launch Safari and enter the URL of the MCS cluster in the address bar.

http://<FQDN>, where <FQDN> is the Fully Qualified Domain Name of the MCS cluster.

n You are automatically redirected to the secure (SSL) connection (https).

A warning appears indicating a problem with the SSL certificate:

2. Click the “Show Certificate” button to display details about the certificate.

3. Put a check mark in the “Always trust” check-box and click Continue.

4. Enter the Administrator password and click OK.

The self-signed certificate is added to the Mac OS system keychain and the browser continues to the MediaCentral UX login page.

n To view the certificate, use the Mac OS Keychain Access utility.

Copyright © 2015 Avid Technology, Inc. and its licensors. All rights reserved. Created 11/4/15