Certificate Management

This section describes in general terms the process after obtaining TLS certificates from a Certified Authority (CA) and management with the Recovery Appliance.

A certificate authority (CA) is a company or organization that acts to validate the identities of entities (such as websites, email addresses, companies, or individual persons) and bind them to cryptographic keys through the issuance of electronic documents known as digital certificates. A CA acts as a trusted third party for both the subject (owner) of the certificate and the party relying upon the certificate.

A digital certificate provides:

• Authentication; the certificate serves as a credential to validate the identity of its owner. In this case, it authenticates communication from the Recovery Appliance to its protected databases, to other replication Recovery Appliances, and to cloud archival storage.

• Encryption for secure communication over insecure networks such as the Internet.

• Integrity of documents signed with the certificate so that they cannot be altered by a third party in transit.

The format of these certificates is specified by the X.509 standard.

The techniques vary between CAs for validating the domain to prove that certificate applicant controls the given domain name.

Likewise each CA has its own application steps that are beyond the scope of this chapter to detail.

In general, upon completion of the certificate application process with your chosen CA, you (the applicant) downloads a bundle file containing all of your certificates.

The following assumes that you have that bundle file (*.pfx), named in this example YourCompany.pfx, generated by your chosen CA.

CA Bundle File (*.pfx) of Certificates

The Recovery Appliance TLS encryption requires both a trusted certificate (*.pem) and signed certificate (*.p12). Each certificate needs to be extracted from the bundle file (*.pfx) and then imported into the TLS wallet.

Certificate Creation Using Third Party Software

1. On the Recovery Appliance, obtain a list of all subject alternative names (SAN) by issuing the following command.

   racli list san

   Note:

   If this returns nothing, patch to a newer version.

2. With the SAN information available particularly for common name (CN) and DNS entries, go to your security website and enter this information to obtain the certificate package.

   Use the PKCS#8 format and make sure to specify separate files.

3. Download the certificate ZIP package.

4. Unzip the certificate ZIP package.

   The certificate ZIP package contains several files including trusted certificate and user certificate.

   • The trusted certificate may have chain or root in its name, and it is *.pem format.

   • User certificate is in *.crt format.

   • The *.key file should also in this directory from downloaded package.

5. With openssl pkcs12, sign the user certificate with the trusted certificate to create a *.p12 file.

   openssl pkcs12 -export --in /<DIR>/<NAME>.crt 
   --inkey /<DIR>/<NAME2>.key --certfile  /<DIR>/<NAME3>.pem 
   --passin pass:<YOURPASSWORD> --passout pass: :<YOURPASSWORD>  
   --out /<DIR>/<NAME4>.p12

   Note:

   Do not use ewallet or cwallet for <NAME4>. <NAME4> should refer to local host information or organization name used for <NAME>, <NAME2>, and <NAME3>.

6. Import both the trusted certificate and the signed user certificate into the Recovery Appliance wallet.

   racli add certificate --signed_cert=/<DIR>/<NAME4>.p12 
   --trusted_cert=/<DIR>/<NAME3>.pem

7. Verify the certificates are in the Recovery Appliance wallet.

   racli list certificate 

8. Continue with Configuring TLS Data Security on the Recovery Appliance followed by Configuring TLS Data Security on the Client.