1. Knowledge Base
  2. Zmanda Enterprise

How to use your custom TLS certificates in Zmanda Classic

How to Replace Default TLS Certificates with Custom in Zmanda Classic

 

This document guides on how to apply the Custom TLS Certificate Utility. This patch is unusable if you do not replace the default certificates installed with Zmanda with your own custom certificates.

This patch would strictly enforce TLSv1.2 across the Zmanda Services.
Once this patch is applied, ensure to access the ZMC using the domain name instead of IP address.

Purpose

Securing your software installation is critical, and one key element is using Transport Layer Security (TLS) certificates. TLS certificates establish secure communication and verify the authenticity of the server or service you're connecting to.

By default, Zmanda includes wildcard certificates, which validate any hostname for ease of setup. However, wildcard certificates pose a security risk, as they can be used to impersonate multiple subdomains or hosts, increasing vulnerability.

To enhance security, it's recommended to replace the default wildcard certificates with custom certificates that are valid only for the specific hostname or machine where the software is installed.

Prerequisites

1. Create a copy of your CA public certificate with the filename .tlsv3_ca.crt

2. Generate a CA-Signed TLS Certificate. Why?

    • This certificate will be used for communication between the Zmanda Management Console (ZMC) and the Backup Server, as well as when accessing the ZMC console in a browser.

      The certificate must be in .crt and .key file formats. Additionally, ensure that the domain name of the machine where ZMC is installed is included in the Subject Alternative Name (SAN)
    • subjectAltName = IP:127.0.0.1, DNS:localhost, DNS:your_domain_name
    •  Name the certificates as .self-signed.crt and .self-signed.key
    3. To generate the remaining X.509 certificates, make sure to include the following extensions and configurations:
      1. Common Name:
        Enter the domain name of the machine where the software is installed as the common name of the certificate.
      2. Basic Constraints
        basicConstraints = critical, CA:FALSE

        This extension specifies that the certificate is not a Certificate Authority (CA) certificate and cannot be used to issue other certificates.
      3. Certificate Type:
        nsCertType = server, client

        This extension indicates that the certificate can be used for both server and client authentication purposes.
      4.  Key Usage:
        keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment

        This extension specifies the permitted uses of the certificate's public key. The critical flag ensures that the certificate cannot be used if the key usage extension is violated.
      5. Extended Key Usage:
        extendedKeyUsage = clientAuth, serverAuth

        This extension further clarifies the purposes for which the certificate can be used, specifically for client and server authentication.
      6. Subject Alternative Name:
        subjectAltName = IP:127.0.0.1, DNS:localhost, DNS:your_domain_name

        This extension allows you to specify additional hostnames or IP addresses that the certificate is valid for. Replace your_domain_name with the actual domain name of the machine where ZMC/Backup Server is installed.

        How to Replace the TLS certificates

        Scenario 1: ZMC and Backup Server are installed on the same machine.

        The following X.509 certificates need to be generated and replaced. Be sure to back up the original certificates, all of which are located at /var/lib/amanda.

        Generate and Replace the Following Certificates:

        • Certificates generated in the prerequisite step:
          • .self-signed.crt
          • .self-signed.key
          • .tlsv3_ca.crt
        • Certificates required by ZMC & Backup Server.
          All certificates must include the domain name (DNS) of the machine (where ZMC & Backup Server are installed) in the Subject Alternative Name (SAN). Follow the configurations mentioned in the 3rd Prerequisite.
          • .tlsv3_vault.crt
          • .tlsv3_vault.key
          • .tlsv3_zmc.crt
          • .tlsv3_zmc.key
          • .tlsv3_zmc_local.crt
          • .tlsv3_zmc_local.key
          • .tlsv3_aee.crt
          • .tlsv3_aee.key
          • .tlsv3_aee_local.crt
          • .tlsv3_aee_local.key
        • After replacing the certificates, apply the Custom TLS Certificate Utility

        Scenario 2: ZMC and Backup Server are installed in different machines.

        The following certificates need to be generated and replaced. Ensure you take a backup of these certificates.

        All certificates are located at /var/lib/amanda on both the ZMC and Backup Server installations.

        • Certificates required by ZMC.
          All certificates must include the domain name (DNS) of the machine (where ZMC is installed) in the Subject Alternative Name (SAN). Follow the configurations outlined in the 3rd Prerequisite.
          • .self-signed.crt (generated in prerequisite)
          • .self-signed.key (generated in prerequisite)
          • .tlsv3_ca.crt (generated in prerequisite)
          • .tlsv3_vault.crt
          • .tlsv3_vault.key
          • .tlsv3_zmc.crt
          • .tlsv3_zmc.key
          • .tlsv3_zmc_local.crt
          • .tlsv3_zmc_local.key
        • Certificates required by Backup Server.
          All certificates must include the domain name of the machine (where the Backup Server is installed) in the Subject Alternative Name (SAN). Follow the configurations outlined in the 3rd Prerequisite.
          • .self-signed.crt (generated in prerequisite)
          • .self-signed.key (generated in prerequisite)
          • .tlsv3_ca.crt (generated in prerequisite)
          • .tlsv3_vault.crt
          • .tlsv3_vault.key
          • .tlsv3_aee.crt
          • .tlsv3_aee.key
          • .tlsv3_aee_local.crt
          • .tlsv3_aee_local.key
        • After replacing the certificates, apply the Custom TLS Certificate Utility

        Cluster Page Already has Servers Set Up

        1. If your ZMC cluster page already contains server entries with information about your AE backup server, it is imperative to ensure that the Subject Alternative Name (SAN) includes the hostname or IP address registered on ZMC. Otherwise, services may deny requests originating from a mismatched hostname.
          1. If the names do not match, you can update the hostnames on both the AE backup server and ZMC by following the steps below.
            1. ZMC
              1. Open the database using mysql
                /opt/zmanda/amanda/bin/mysql ZMC
              2. Run the following query
                update servers_aebackupserver set server_ip = <you server hostname or ip> where server_id= <your server id>;
              3. AE backup server
                1. Go to the amanda directory
                  cd /var/lib/amanda/ae_service/
                2. run the following query
                  /opt/zmanda/amanda/bin/sqlite3 db.sqlite3
                3. once inside the interactive shell run the following query
                  update servers_user set rest_server_ip=<your server hostname or ip> where id =<your server id>;

        FAQ

        1. What happens if the patch is applied without replacing the default certificates?
          - The ZMC and Backup Server services will go down. To rectify this, please reinstall the same version of the ZMC and Backup Server.
        2. What happens when ZMC and Backup Server is upgraded to next version?
          - The utility patch needs to be reapplied along with the certificates.