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: [email protected]
For additional commands, e-mail: [email protected]
