[
https://issues.apache.org/jira/browse/HDDS-8960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
István Fajth updated HDDS-8960:
-------------------------------
Priority: Blocker (was: Major)
> 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
> Assignee: Szabolcs Gál
> Priority: Blocker
>
> 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]
