This is an automated email from the ASF dual-hosted git repository.
vishesh92 pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/cloudstack-documentation.git
The following commit(s) were added to refs/heads/main by this push:
new 97a79024 Add documentation for custom ROOT CA (#641)
97a79024 is described below
commit 97a79024eb0fcc08a0c7f266b1765693f6dfa193
Author: Vishesh <[email protected]>
AuthorDate: Thu May 21 13:19:21 2026 +0530
Add documentation for custom ROOT CA (#641)
---
source/adminguide/hosts.rst | 86 +++++++++++++++++++++++++++++++++++++++++----
1 file changed, 79 insertions(+), 7 deletions(-)
diff --git a/source/adminguide/hosts.rst b/source/adminguide/hosts.rst
index 87d5d945..b7c6b8df 100644
--- a/source/adminguide/hosts.rst
+++ b/source/adminguide/hosts.rst
@@ -770,9 +770,9 @@ Following are some global settings that control various
aspects of this feature.
.. cssclass:: table-striped table-bordered table-hover
-=======================================
====================================================================
+=======================================
====================================================================================================
Global setting Description
-=======================================
====================================================================
+=======================================
====================================================================================================
ca.framework.provider.plugin The configured CA provider plugin
ca.framework.cert.keysize The key size used for certificate
generation
ca.framework.cert.signature.algorithm The certificate signature algorithm
@@ -780,13 +780,15 @@ ca.framework.cert.validity.period Certificate
validity in days
ca.framework.cert.automatic.renewal Whether to auto-renew expiring
certificate on hosts
ca.framework.background.task.delay The delay between each CA background
task round in seconds
ca.framework.cert.expiry.alert.period The number of days to check and
alert expiring certificates
-ca.plugin.root.private.key (hidden/encrypted in database)
Auto-generated CA private key
-ca.plugin.root.public.key (hidden/encrypted in database) CA
public key
-ca.plugin.root.ca.certificate (hidden/encrypted in database) CA
certificate
-ca.plugin.root.issuer.dn The CA issue distinguished name used
by the root CA provider
+ca.plugin.root.private.key (hidden) CA private key.
Auto-generated if empty. PKCS#8 format required
+ca.plugin.root.public.key (hidden) CA public key.
Auto-generated if empty. X.509/SPKI format required
+ca.plugin.root.ca.certificate (hidden) CA certificate chain.
Auto-generated if empty. Supports intermediate CA chains
+ca.plugin.root.issuer.dn The CA issuer distinguished name
used by the root CA provider
ca.plugin.root.auth.strictness Setting to enforce two-way SSL
authentication and trust validation
ca.plugin.root.allow.expired.cert Setting to allow clients with
expired certificates
-=======================================
====================================================================
+ca.framework.inject.default.truststore Injects CA certificate into JVM
default truststore on startup for outgoing HTTPS trust
+ (default: ``true``). Restart
management server(s) when changed
+=======================================
====================================================================================================
A change in ``ca.framework.background.task.delay`` settings requires
restarting of
management server(s) as the thread pool and a background tasks are configured
@@ -806,6 +808,76 @@ enforce authentication and validation strictness by setting
``ca.plugin.root.auth.strictness`` to ``true`` and restarting the management
server(s).
+Custom CA Support
+~~~~~~~~~~~~~~~~~~
+
+The built-in ``root`` CA provider supports user-provided CA
+material. When the ``ca.plugin.root.private.key``,
+``ca.plugin.root.public.key``, and ``ca.plugin.root.ca.certificate``
+configuration keys are pre-populated, CloudStack uses the provided CA instead
+of auto-generating one. All internal certificate provisioning (agents,
+SystemVMs, management server keystores) automatically use the configured CA.
+
+Starting 4.23, this support was enhanced to include:
+
+- **Intermediate CA chains**: The ``ca.plugin.root.ca.certificate`` key can now
+ contain a PEM-concatenated chain of certificates.
+- **Outgoing HTTPS trust**: The configured CA is injected into the management
+ server's default truststore (controlled by
``ca.framework.inject.default.truststore``)
+ and the SystemVM's truststore, allowing outgoing HTTPS connections to trust
+ servers using this CA. This enables SystemVMs to download templates and ISOs
+ from HTTPS servers whose certificates are signed by the configured CA.
+- **Validation**: User-provided keys are validated on startup to prevent silent
+ overwriting of malformed keys.
+
+All three keys must be set together. If any key is missing or malformed, the CA
+provider will log a warning, overwrite them with auto-generated keys, and
+the user will need to update the global settings again with valid values.
+The private key must be in PKCS#8 format and the public key must be explicitly
+extracted. Use the following commands to prepare the CA material:
+
+.. code:: bash
+
+ # Convert private key to PKCS#8 format (required)
+ openssl pkcs8 -topk8 -nocrypt -in ca.key -out ca-pkcs8.key
+
+ # Extract the public key
+ openssl rsa -in ca.key -pubout -out ca.pub
+
+ # For intermediate CAs, concatenate into a single PEM chain
+ cat intermediate.crt root.crt > ca-chain.crt
+
+.. note::
+ When migrating from one CA to another on an existing environment, agents
+ holding certificates signed by the old CA will fail to connect after the
+ management server restarts with the new CA. Ensure
+ ``ca.plugin.root.auth.strictness`` is set to ``false`` to allow agents to
+ reconnect, then use ``provisionCertificate`` to re-provision each host and
+ SystemVM with certificates signed by the new CA. Alternatively, use forced
+ provisionin (see below) for hosts that cannot reconnect.
+
+Forced Certificate Provisioning
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The ``provisionCertificate`` API accepts a ``forced`` parameter (default:
+``false``). When set to ``true``, the management server provisions certificates
+directly via SSH instead of the agent communication channel. This is required
+when agents cannot connect to the management server — for example, after a CA
+change when the agent's keystore trusts the old CA.
+
+For KVM hosts, forced provisioning connects via SSH using stored host
+credentials, provisions the certificate, and restarts the ``cloudstack-agent``
+and ``libvirtd`` services. For SystemVMs, it routes commands through the
+SystemVM's SSH access.
+
+.. code:: bash
+
+ # Force re-provision a disconnected KVM host
+ cmk provision certificate hostid=<HOST_UUID> reconnect=true forced=true
+
+ # Force re-provision a disconnected SystemVM
+ cmk provision certificate hostid=<SYSTEMVM_HOST_UUID> reconnect=true
forced=true
+
Server Address Usage
--------------------