[
https://issues.apache.org/jira/browse/HDDS-8960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
István Fajth updated HDDS-8960:
-------------------------------
Description:
The rationale behind this task is the fact that the rootCA certificate is only
used to sign the sub-CA certificates assigned to the SCMs, and the
rotation/initialization can only succeed if all SCMs have the sub-CA
certificate and the materials needed for them.
Later on the rootCA certificate is not used to sign anything else, and we just
need it as the trust anchor, the keypair we can simply forget, as the private
key is not needed anymore, while the public key is part of the certificate.
During the rotation of CA certificates, we are creating a new DefaultCAServer
instance, which internally creates and saves the new rootCA certificate and
keys.
Additionally SCM holds a reference to the DefaultCAServer instance with the
rootCA certificate, and during initialization it always creates it.
The DefaultCAServer class is also used with sub-CA certificates as the general
CA server within SCM, and contains logic to check on disk data content to be
sure we are able to sing certificates properly.
The proposal here is to somehow separate the two, as we need this full
functionality for the CA server with the sub-CA certificate, but for the rootCA
certificate, we need the keys only in memory and only until we sign the first 3
(HA case), or the one (non-HA case) sub-CA certificate that will sign
certificates for the rest of the services.
In the original bootstrap we also do not need the rootCA certificate's private
key after we signed the first set of sub-CA certificates.
With this change, we should implement the separation of these two approaches,
and we should clean up any unused rootCA related key material from the metadata
directories.
As the rootCA certificate is replicated via raft, and is present in the SCM's
rocksDB, we might also remove the on disk representation but that might be
useful to have it cached in a file so that we do not need to query the rocksDB
for it, this is to decide during implementation.
Additional complexity is upgrades, as the new code can not immediatelly remove
the rootCA material, as the old code still would rely on it, so this needs
integration with the upgrade framework as well.
was:
The rationale behind this task is the fact that the rootCA certificate is only
used to sign the sub-CA certificates assigned to the SCMs, and the
rotation/initialization can only succeed if all SCMs have the sub-CA
certificate and the materials needed for them.
Later on the rootCA certificate is not used to sign anything else, and we just
need it as the trust anchor, the keypair we can simply forget, as the private
key is not needed anymore, while the public key is part of the certificate.
During the rotation of CA certificates, we are creating a new DefaultCAServer
instance, which internally creates and saves the new rootCA certificate and
keys.
Additionally SCM holds a reference to the DefaultCAServer instance with the
rootCA certificate, and during initialization it always creates it.
The DefaultCAServer class is also used with sub-CA certificates as the general
CA server within SCM, and contains logic to check on disk data content to be
sure we are able to sing certificates properly.
The proposal here is to somehow separate the two, as we need this full
functionality for the CA server with the sub-CA certificate, but for the rootCA
certificate, we need the keys only in memory and only until we sign the first 3
(HA case), or the one (non-HA case) sub-CA certificate that will sign
certificates for the rest of the services.
In the original bootstrap we also do not need the rootCA certificate's private
key after we signed the first set of sub-CA certificates.
With this change, we should implement the separation of these two approaches,
and we should clean up any unused rootCA related key material from the metadata
directories.
As the rootCA certificate is replicated via raft, and is present in the SCM's
rocksDB, we might also remove the on disk representation but that might be
useful to have it cached in a file so that we do not need to query the rocksDB
for it, this is to decide during implementation.
> Hold the rootCA's private key only in memory for the time of
> initialization/rotation, then forget it
> ----------------------------------------------------------------------------------------------------
>
> Key: HDDS-8960
> URL: https://issues.apache.org/jira/browse/HDDS-8960
> Project: Apache Ozone
> Issue Type: Sub-task
> Reporter: István Fajth
> Priority: Major
>
> The rationale behind this task is the fact that the rootCA certificate is
> only used to sign the sub-CA certificates assigned to the SCMs, and the
> rotation/initialization can only succeed if all SCMs have the sub-CA
> certificate and the materials needed for them.
> Later on the rootCA certificate is not used to sign anything else, and we
> just need it as the trust anchor, the keypair we can simply forget, as the
> private key is not needed anymore, while the public key is part of the
> certificate.
> During the rotation of CA certificates, we are creating a new DefaultCAServer
> instance, which internally creates and saves the new rootCA certificate and
> keys.
> Additionally SCM holds a reference to the DefaultCAServer instance with the
> rootCA certificate, and during initialization it always creates it.
> The DefaultCAServer class is also used with sub-CA certificates as the
> general CA server within SCM, and contains logic to check on disk data
> content to be sure we are able to sing certificates properly.
> The proposal here is to somehow separate the two, as we need this full
> functionality for the CA server with the sub-CA certificate, but for the
> rootCA certificate, we need the keys only in memory and only until we sign
> the first 3 (HA case), or the one (non-HA case) sub-CA certificate that will
> sign certificates for the rest of the services.
> In the original bootstrap we also do not need the rootCA certificate's
> private key after we signed the first set of sub-CA certificates.
> With this change, we should implement the separation of these two approaches,
> and we should clean up any unused rootCA related key material from the
> metadata directories.
> As the rootCA certificate is replicated via raft, and is present in the SCM's
> rocksDB, we might also remove the on disk representation but that might be
> useful to have it cached in a file so that we do not need to query the
> rocksDB for it, this is to decide during implementation.
> Additional complexity is upgrades, as the new code can not immediatelly
> remove the rootCA material, as the old code still would rely on it, so this
> needs integration with the upgrade framework as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
