Certificate Renewal

CORE certificates are used for mutual validation of appliances that are establishing SSLClosedSecure Sockets Layer - a cryptographic protocol that provides communications security over a computer network.-based Client-Server and Server-Server connections. In addition, they carry information required for the CORE server or client access authorization. The certificates are generated for a limited time and are signed by the CORE Root CA certificate.

The certificate renewal does not simply extend its validity but creates a new certificate based on the new key material. The latter fact has a CORE-wide impact when the renewed certificate is the CORE Root CA certificate. This chapter specifies the certificate renewal procedures and best practices.

CORE Certificates

CORE Ceritification Authority

CORE appliance certificates:
CORE server certificate is created during the server bootstrap or when a server is added to the cluster.
CORE client identity certificate is created by the CSRClosedCertificate Signing Request - a message sent from an applicant to a certificate authority in order to apply for a digital identity certificate request during the client's registration or when a client certificate is created by the EP server.
 
CORE CA certificates
CORE certificates are validated using CORE Root CA certificate. It is a self-signed certificate that is initially created during the bootstrap of EP. It is replaced by the next Root CA certificate (self-signed by the next Root CA key) towards its expiration. Refer to the Root CA Renewal Overview.
 
CORE Trust Stores
CORE server - the root_ca.ks file in the CORE Server Certificates Folder.
CORE client - the server-ca.p7b file in the CORE Client Certificates Folder.
 
The trust stores are updated during the Root CA transition period. Refer to the Root CA Renewal Overview

Certificate's validity and alerts

A certificate is valid for the specified period. The default validity duration is as follows:

To change the default values, refer to the system settings (CORE PKI settings). To apply a new setting to an already created certificate, renew the certificate - refer to Appliance Certificate Renewal.

Admins of the CORE clients and servers are alerted to renew their certificates before they expire. CORE system settings control the alert timing relative to the expiration date.

Appliance Certificate Renewal

To renew the CORE appliance's identity certificate, use the following:

The certificate renewal on a CORE appliance results in the following:

Root CA Renewal Overview

Issue: If the Root CA certificate is replaced by the new certificate, then it will error certificates of all clients that are certified by the previous Root CA certificate. not applicable to validate certificates of all clients and servers that identify themselves using certificates signed by the previous Root CA.

Solution: A gradual transition from the old certificate to the new one. The lifecycle of the next Root CA certificate is divided into three periods that partially overlap with the lifecycle of the current Root CA and the one that will follow it (next-next certificate):

  1. On-ramp period. It starts by generating the next Root CA key and certificate. During this period:
    1. CORE servers and clients gradually update their trust stores with the next Root CA certificate. They can do it:
      • directly - by using the dedicated command.
      • indirectly by renewing their certificates or registering as new clients.
    2. The EP keeps using the current Root CA key to sign CSRClosedCertificate Signing Request - a message sent from an applicant to a certificate authority in order to apply for a digital identity certificate requests.
  2. Activity - period. It starts by endorsing the next Root CA key as the Root CA key. During this period:
    1. The next Root CA key signs all new and renewed certificates. In particular, it signs the renewed EP certificate.
    2. SOs of partitions are alerted about clients that have not yet updated their CORE trust stores.
    3. The previous Root CA certificate remains valid (not expired) for a period allowing validation of certificates signed by it (at least 3 yearsClosedFor any time interval setting in years, 1 year is converted to 365 days, based on the default client certificate validity period).
    4. At some point, the new next Root CA key goes on-ramp. Its certificate starts being added to the trust store of CORE appliances - see #1a above.
  3. Off-ramp - period. It starts when a new next Root CA key takes over and enters its activity period.
    1. Regarding our Root CA certificate - see #2c above.

Root CA Renewal Quickstart

The following chart provides an example of the Root CA certificate rotation plan. We assume the following:

To calculate the date of the next certificate's on-ramp, we consider the following:

Root CA Renewal Cycle

The On-ramp Period

Start this period 3 yearsClosedFor any time interval setting in years, 1 year is converted to 365 days and N-months before the expiration of the current Root CA certificate.

The N-months period is required to update trust stores of all CORE appliances with the next Root CA certificate.

  1. Select an EP and its Partner. On both servers;
    1. Stop the EKMClosedEnterprise Key Management - previous name of the product. Service.
    2. Run the ekm_root_ca_prepare_next script.
    3. Start the EKMClosedEnterprise Key Management - previous name of the product. Service.
  2. Run the ucl list -p root command on EP.

      It shows the next-root-ca-key and the next root-ca-key-certificate in addition to the current root-ca-key and the root-ca-key-certificate.

      Run the ucl list -p root command on another EP.
      If it doesn't show the new keys:

        Run ekm_sync_key for these keys from the updated EP to all other EPs.

        For example: on the EP server from step #1 run:

        ekm_sync_key.sh --uid <next-root-ca-key> --partition root --target EP2
        ekm_sync_key.sh --uid <next root-ca-key-certificate> --partition root --target EP2

  3. On all CORE servers (including the above EP and Partner) - update their CORE trust stores by running the ekm_root_ca_trust_next script.
  4. On each CORE client (including the embedded client on EP), delete the current trust store and obtain the updated one:

Optionally, to review the content of the updated trust store, use OpenSSL:

openssl pkcs7 -print -text -inform der -noout -in /etc/ekm/server-ca.p7b

The output shows certificates in the store. Each certificate specifies its issuer: issuer: CN=Unbound UKC Root CA G<n>. The G<n> in the above indicates the generation of the Root CA certificate, starting with G1.

The Activity Period

Start this period at least 3 yearsClosedFor any time interval setting in years, 1 year is converted to 365 days before the expiration of the current Root CA certificate.

At this point, trust stores of all appliances should include the next Root CA certificate. It becomes critical once the EP renews its certificate. In such a case, the certificate of EP becomes signed by the new Root CA key. For a client to validate this signature it must have the new Root CA certificate.

To endorse the next-root-ca-key as the key that signs CORE CSRs and certificate renewal, run ekm_root_ca_move_next on the EP server. The change of the Root CA certificates is indicated as follows:

  • In the key material list of the Root partition (ucl list -p root): 
    • the name of current Root CA receives -G<N> appendix, for example: "root-ca-certificate-G1" and "root-ca-key-G1".
    • the "next-root-ca-<key | certificate>" becomes the current Root CA key and certificate.
  • In UI of each partition:
  • The Client Trust Store Alert Client Trust Store Alert will appear if there are clients with outdated trust stores. Such clients are highlighted in the partition's clients list.

The Off-ramp Period

This period starts when the next-next Root CA certificate is activated by its ekm_root_ca_move_next script.