Import Externally Signed Certificates¶

Using the UI

Click the username in the top right-hand corner and select Certificates on the drop-down list.

The list of certificates displays.

Note

The certificate management for the ARTESCA+ Veeam Unified Software Appliance differs from the regular ARTESCA one. It also depends on the architecture model.

Primary Repository Architecture

To enforce the security of the primary repository architecture, the certificate management is disabled.

Secondary Repository Architecture

On a secondary repository architecture, only the ARTESCA+ Veeam S3 endpoint certificate management is disabled.
Click Replace Certificate next to the certificate you want to replace.

Tip

Click View to access the certificate’s details. Refer to View a Signed Certificate for more information.
(Optional) Edit the CSR with Organization specific information.

This optional step allows you to enrich the CSR with your Organization’s specific information and your Common Name to comply with your certificate management authority.
1. Check the Edit CSR with Organization specific information box. It expands to display a form with optional fields to fill in.
2. Fill in the form with your Organization’s specific information.
3. Click Apply to save your information and enrich your CSR.
Copy or download the Certificate Signing Request (CSR).
Submit the CSR to your Certificate Authority. You must receive a new certificate.
Import the certificate you received on the previous step, either by dragging or dropping the file.
Important

Make sure to include all certificates from the trust chain in the resulting bundle, and in the following order:
1. Leaf certificate
2. Intermediate certificate(s) (optional)
3. Root certificate

Using the CLI

To use externally signed certificates (instead of letting ARTESCA manage them), follow these steps for each existing certificate:

Retrieve a Certificate Signing Request (CSR) corresponding to the considered certificate.
Use your CA to sign it.
Replace the generated certificate with your own in the existing Secret.

Here are the detailed steps, applied to each certificate:

Special case: Import Externally Signed Certificates for S3 Endpoints

There are two cases to consider (repeat the steps for each endpoint):

Certificate not generated yet

In this scenario, follow these steps:

Generate a certificate with the following mandatory x509 v3 extensions (the choice of Subject is not important for the functioning of ARTESCA, refer to your security team for recommendations):
- Subject Alternative Names: must include DNS:<your S3 endpoint> and DNS:*.<your S3 endpoint> (this wildcard domain is used for virtual-host style S3 access)
- Key Usages: must include digitalSignature and keyEncipherment
- Extended Key Usages: must include serverAuth
Copy the generated certificate and private key to your bootstrap node. They will be named s3.key and s3.crt respectively in the following steps.
Define a Secret name (make sure it is not already in use):
[artesca-os@bootstrap ~]$
SECRET_NAME="s3-cert"

Create a TLS Secret containing the key and certificates:

[artesca-os@bootstrap ~]$

sudo kubectl --kubeconfig /etc/kubernetes/admin.conf \
    -n zenko create secret tls $SECRET_NAME \
    --key="s3.key" --cert="s3.crt"

Define your endpoint in a variable:

[artesca-os@bootstrap ~]$

S3_ENDPOINT="s3.my-company.com"

Add an entry for your endpoint in the Zenko deployment:

[artesca-os@bootstrap ~]$

sudo kubectl --kubeconfig /etc/kubernetes/admin.conf patch \
    --namespace zenko zenko/artesca-data \
    --type json --patch '
      [{
         "op": "add",
         "path": "/spec/ingress/certificates/-",
         "value": {
           "hosts": ["'$S3_ENDPOINT'", "'*.$S3_ENDPOINT'"],
           "secretName": "'$SECRET_NAME'"
         }
      }]
    '

Certificate already generated using one of the above methods

In this scenario, you have to follow the same procedure as above for the three certificates:

zenko/zenko-crt-secret

For S3 endpoints, there are two cases to consider (repeat the steps for each endpoint):

The certificate was already generated by using one of the above methods (built-in or custom CA).

In this scenario, assuming the chosen Secret name was s3-cert, follow these steps:

The certificate has not been generated yet.

In this scenario, follow these steps:
1. Generate a certificate with the following mandatory x509 v3 extensions (the choice of Subject is not important for the functioning of ARTESCA, refer to your security team for recommendations):
  - Subject Alternative Names: must include DNS:<your S3 endpoint> and DNS:*.<your S3 endpoint> (this wildcard domain is used for virtual-host style S3 access)
  - Key Usages: must include digitalSignature and keyEncipherment
  - Extended Key Usages: must include serverAuth
2. Copy the generated certificate and private key to your bootstrap node. They will be named s3.key and s3.crt respectively in the following steps.
3. Define a Secret name (make sure it is not already in use):
  [artesca-os@bootstrap ~]$
  SECRET_NAME="s3-cert"
4. Create a TLS Secret containing the key and certificates:
  [artesca-os@bootstrap ~]$
  sudo kubectl --kubeconfig /etc/kubernetes/admin.conf \ -n zenko create secret tls $SECRET_NAME \ --key="s3.key" --cert="s3.crt"
5. Define your endpoint in a variable:
  [artesca-os@bootstrap ~]$
  S3_ENDPOINT="s3.my-company.com"
6. Add an entry for your endpoint in the Zenko deployment:
  [artesca-os@bootstrap ~]$
  sudo kubectl --kubeconfig /etc/kubernetes/admin.conf patch \ --namespace zenko zenko/artesca-data \ --type json --patch ' [{ "op": "add", "path": "/spec/ingress/certificates/-", "value": { "hosts": ["'$S3_ENDPOINT'", "'*.$S3_ENDPOINT'"], "secretName": "'$SECRET_NAME'" } }] '