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