[
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 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.
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 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.
> 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 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
