[
https://issues.apache.org/jira/browse/HDDS-7391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
István Fajth updated HDDS-7391:
-------------------------------
Description:
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 rotation and
renewal of this certificate is time consuming at once, as it includes the
renewal of all certificates.
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 as the root of trust for new certificates
- in the time period while the old rootCA 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.
- creating the new rootCA certificate should trigger the rotation of all
subordinate CA certificate active in the system, and the new subordinate CA
certificates has to be signed by the rootCA certificate.
Notes:
Let's see an example of how this may happen:
- let's say we have regular certificates valid for n-days in our system, this
is defined by configuration
- n+2 days before the rootCA certificate expiration date, we can only have
subordinate CA certificates that are expiring in n+2 or more days (rootCA and
subordinate CA certificates have the same expiration period)
- every certificate is renewed on the day before the day when the certificate
expires
On the day n+2 days before the rootCA certificate expiration:
- we create the new rootCA certificate, and refresh the trust stores in the
system to contain both the old and new rootCA certificate
- we create the new subordinate CA certificates, and reset the CA server
subsystem in SCMs to use the new subordinate CA certificate for certificate
signature
- any new CSR is signed by the new subordinate CA certificates from this point
on
This ensures that all the certificates to be renewed are renewed as part of the
new chain of trust for which the rootCA certificate is the new one, while the
certificates that are inheriting trust from the old rootCA certificate are
still trusted.
On the day when the old rootCA certificate expires we do not need to do
anything, but remove the old rootCA certificate from the SCM's metadata, as:
- every certificate inheriting the trust from that is already renewed, or will
be renewed at startup of a service that was not live at renewal time
immediately.
- all certificates that may still linger there is untrusted as the rootCA
certificate expired.
- truststores are built up at startup, so they will eventually forget the old
rootCA once they are restarted
was:
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 rootCA 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 are renewed.
- creating the new rootCA certificate should trigger the rotation of all
subordinate CA certificate active in the system
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.
> 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
> Priority: Major
>
> 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
> rotation and renewal of this certificate is time consuming at once, as it
> includes the renewal of all certificates.
> 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 as the root of trust for new certificates
> - in the time period while the old rootCA 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.
> - creating the new rootCA certificate should trigger the rotation of all
> subordinate CA certificate active in the system, and the new subordinate CA
> certificates has to be signed by the rootCA certificate.
> Notes:
> Let's see an example of how this may happen:
> - let's say we have regular certificates valid for n-days in our system, this
> is defined by configuration
> - n+2 days before the rootCA certificate expiration date, we can only have
> subordinate CA certificates that are expiring in n+2 or more days (rootCA and
> subordinate CA certificates have the same expiration period)
> - every certificate is renewed on the day before the day when the certificate
> expires
> On the day n+2 days before the rootCA certificate expiration:
> - we create the new rootCA certificate, and refresh the trust stores in the
> system to contain both the old and new rootCA certificate
> - we create the new subordinate CA certificates, and reset the CA server
> subsystem in SCMs to use the new subordinate CA certificate for certificate
> signature
> - any new CSR is signed by the new subordinate CA certificates from this
> point on
> This ensures that all the certificates to be renewed are renewed as part of
> the new chain of trust for which the rootCA certificate is the new one, while
> the certificates that are inheriting trust from the old rootCA certificate
> are still trusted.
> On the day when the old rootCA certificate expires we do not need to do
> anything, but remove the old rootCA certificate from the SCM's metadata, as:
> - every certificate inheriting the trust from that is already renewed, or
> will be renewed at startup of a service that was not live at renewal time
> immediately.
> - all certificates that may still linger there is untrusted as the rootCA
> certificate expired.
> - truststores are built up at startup, so they will eventually forget the old
> rootCA once they are restarted
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
