[jira] [Created] (HDDS-7391) Rotation of the rootCA certificate

["István Fajth (Jira)" <ji...@apache.org>]

István Fajth created HDDS-7391:
----------------------------------

             Summary: Rotation of the rootCA certificate
                 Key: HDDS-7391
                 URL: https://issues.apache.org/jira/browse/HDDS-7391
             Project: Apache Ozone
          Issue Type: Sub-task
            Reporter: István Fajth
            Assignee: István Fajth


The current rootCA certificate expiration happens in somewhat over 5 years after the certificate was created.
This event invalidates all certificates that are signed in the trust chain for which the rootCA certificate is the base of trust, this means that in order to rotate and renew this certificate is time consuming at once.

In order to renew the rootCA certificate, instead of a full security re-bootstrap we would like to follow the following procedure:
- before any of the certificates starts to have an expiration date bigger then the rootCA expiration date, we need to create a new rootCA certificate and we need to start using that to sign new certificates
- in the time period while the old CA certificate is still valid, we need to ensure that both rootCA certificate is distributed to the trust stores
- creating the new rootCA certificate has to happen prior to the renewal of any subordinate CA certificates with a similar expiration date is renewed.

Notes:
If during the CA certificate validity period there wasn't any new SCM added to the system and none of the subordinate CA certificates were revoked, then we can time this properly. If any of the following happened, then the subordinate CA certificate in question will have a larger expiration date than the rootCA certificate.
One questionable point here is the event if someone reduced the CA certificate lifetime, and revoked the old subordinate CA certificates, but in this case the rotation of the subordinate CA certificates will ensure a situation where the rootCA certificate has the smallest expiration date within the subordinate CA certificates.

For us if the subordinate CAs expire at the time or later compared to when the rootCA certificate expires, we can start having two co-existent rootCA certificate.
As subordinate CA certificates are existing only in SCMs, when the new rootCA certificate is created, and stored in the SCMs DB, SCMs can initiate the signature of a new subordinateCA certificate, and sign any new certificate request with the new subordinate CA certificate.
So the rotation of the rootCA certificate has to initiate the rotation of the subordinate CA certificates, besides ensuring that the system trusts both active rootCA certificate.
This has to happen at or before any regular certificate is signed in the system that would expire after the old rootCA certificate expires.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org