docs/doc/source/security/kubernetes/one-single-root-ca-multiple-server-client-certificates-0692df6ce16d.rst

Certificate Management Guidelines

A recommended guideline is to use one single Root certificate to generate multiple server/client certificates for different uses in the system.

This simplifies the overall configuration of your certificate chains, as well as it means you need only provide a single Root certificate for clients to trust when interfacing to the system.

The following is a use case for system where one single Root is used to generate REST API/Horizon server certificates, central/subcloud registry server certificates, and how to install these certificates and update system’s trusted list.

1. Generate a Root certificate on System Controller or a Linux server with openssl installed.

   Refer to Create Certificates Locally using openssl <create-certificates-locally-using-openssl> on how to generate a Root certificate, and save the Root certificate and corresponding private key in a directory, for example:

   ../root_CA/root-ca-cert.pem
   ../root_CA/root-ca-key.pem

2. Generate REST API/Horizon server certificates for System Controller and subclouds.

   Refer to Create Certificates Locally using openssl <create-certificates-locally-using-openssl> on how to generate server certificates from the Root certificate.

   Pay attention to the notes about the certificate’s on section Install/Update the StarlingX Rest and Web Server Certificate <install-update-the-starlingx-rest-and-web-server-certificate>.

   Optionally, set the subject fields uniquely for systemController and each of the subclouds.

   Generate REST API/Horizon server certificate for the central cloud and each of the subclouds, and save them in a directory, for example:

   .. /REST_certificates/central-rest-server-cert.pem
   .. /REST_certificates/subcloud1-rest-server-cert.pem
   .. /REST_certificates/subcloud2-rest-server-cert.pem
   ...

3. Generate registry server certificates for central cloud and subclouds.

   Refer to Create Certificates Locally using openssl <create-certificates-locally-using-openssl> on how to generate server certificates from the self-signed Root certificate.

   Refer to Install/Update the Local Docker Registry Certificate <installing-updating-the-docker-registry-certificate> for the requirements on certificate’s .

   Optionally set the subject fields uniquely for System Controller and each of the subclouds.

   Generate registry server certificate for central cloud and each of the subclouds, and save them is a directory, for example:

   .. /registry_certificates/central-registry-server-cert.pem
   .. /registry_certificates/subcloud1-registry-server-cert.pem
   .. /registry_certificates/subcloud2-registry-server-cert.pem
   ...

4. Install the Root certificate as trusted on System Controller.

   The single Root certificate only need to be installed on System Controller.

   It will sync to all the subclouds.

   Wait until subclouds are insync.

5. Install the REST API/Horizon server certificates to the central and subclouds.

   Once all subclouds are insync, install the central cloud’s REST API/Horizon server certificate to the central cloud, and the subcloud’s REST API/Horizon server certificate to each of the subclouds.

   This can be done manually or by some auto tools such as ansible.

6. Install the registry server certificates to central and subclouds.

   Similarly, once all subclouds are in-sync, install the central cloud’s registry certificate to the central cloud, and the subcloud’s registry server certificate to each of the subclouds.

   This can be done manually or by some auto tools such as ansible.

7. Provide the single Root public certificate, from step 1 (../root_CA/root-ca-cert.pem), to any remote user using remote clients to interface with the system.

   These remote users/clients will need to be configured to trust this Root .