A Private CA Where Revoke Means Something to a Client
A CCM private CA, root or subordinate. CRL publication is off by default, and without it you can press revoke while every client keeps trusting the certificate until it expires - so the module refuses that unless it is accepted. Deleting a CA starts a 7 to 30 day clock rather than deleting, and the product exists in two regions only.
Verification
Static-verifiedPassed: validated and lint-clean (provider-schema-validated for AWS/Azure/GCP; Terraform-language lint elsewhere).
Conformance
- Static validation (fmt · validate · tflint)
- No applicable security policies for this provider
- Plan tests (mocked: validation rules · outputs)
Provenance
- SHA-256 checksum
- Signature (pending)
Functional
- Live test pending (no cloud run yet)
Last verified 2026-09-15 · how we verify
Use it from the registry
terraform · opentofumodule "private_ca" {
source = "www.iac-bazaar.com/iac-bazaar/huawei-private-ca/huaweicloud"
version = "1.0.0"
}Needs a registry token from /account/tokens. The module itself is free; the account is what identifies you. Full setup: registry docs.
Inputs & outputs
Create a free account to read this module's contract
The declared contract - every input name, type, default and description, plus every output - is shown to signed-in accounts, not to anonymous visitors.
A free account sees the contract of every module in the catalogue. There is no subscription and nothing to buy - the modules are free to download, and they run under Vizier.
Documentation
huawei-private-ca
A private certificate authority on Huawei Cloud CCM. Works with Terraform and OpenTofu
(>= 1.6), huaweicloud provider >= 1.60, < 2.0.
Without a CRL you cannot revoke. Publication is off by default, and a CA with no distribution point still issues certificates and still lets you press revoke - while every client keeps trusting the revoked certificate until it expires on its own. can_revoke is an output and the module refuses a CA without one unless you say so.
Changing the CRL bucket in place does not work. Huawei documents that obs_bucket_name and valid_days only change together with enabled, so moving it means disable, apply, re-enable - with a window where nothing is published.
Deleting a CA starts a clock, it does not delete. pending_days is 7 to 30 and required; the CA and its billing both survive the window. That is a feature for a root of trust.
This product exists in two regions, cn-north-4 and ap-southeast-3, and a CA is the longest-lived thing in an estate.
A subordinate needs an issuer, a root must not have one, a subordinate must expire before its parent, and key_usages is customisable only on a subordinate. Each is checked here rather than at the API.
prePaid takes only YEAR or MONTH for the validity type - the combination is refused by the API, not the plan, so the module checks it.
Verification
Static validation runs tofu fmt, init, validate, tflint and checkov.
This module has not yet had a live test, so it is published as statically
validated with its live test pending and does not carry the live-tested mark.
Usage code & full reference need an account
The complete copy-paste usage, the full input/output reference, and operational notes are free with an account - shown here and bundled in the download. Sign in and this section fills in.
- Usage
Related modules
huawei-csms-secret
A secret in Huawei Cloud Secrets Manager whose value is a sensitive variable supplied at apply time and never output, encrypted with a KMS key of yours rather than the account's default CSMS key (the default by name), with an expiry after which CSMS flags it (none by name) and event subscriptions that notice version changes and expiry.
huawei-kms-key
rotation_enabled defaults to false, so today's key material encrypts everything for the life of the account; and a key scheduled for deletion is gone after its pending window with everything encrypted under it, on a service with no flag to refuse the schedule. Rotation on at your interval, a 30-day window, and an output that says no deletion-protection flag exists.
gcp-certificate-authority
The DevOps tier does not persist the certificates it issues: no record, no CRL, no revocation - a year-long certificate from it can only answer a key compromise by the CA being distrusted whole. ENTERPRISE tier with the CRL published, a 90-day ceiling on every certificate, RSA below 2048 refused, and deletion protection on because deleting a CA invalidates everything it signed.
vault-pki-certificate-authority
Issuing from the root puts every leaf one signature from the root's compromise; a PKI role's defaults issue nothing until somebody reaches for allow_any_name, which issues for every hostname; and without AIA and CRL URLs a leaf is valid and unverifiable. A root that signs one intermediate, roles bound to allowed_domains, 30-day leaves under a 90-day ceiling, URLs on both mounts.
oci-certificate-authority
The CRL bucket is optional: a CA created without one can mark a certificate revoked and never tell anyone, and every client keeps trusting it until it expires. Required here unless no CRL is accepted by name. Issued certificates renew by rule; one without a renewal rule is a countdown and is listed. Leaf validity is capped at 90 days; the signing key is an HSM key in your vault.
aws-private-ca
A root or subordinate CA with revocation configured, its certificate installed in the same apply, and ACM permitted to issue from it. Documents the two traps: a CA bills through its deletion window, and one without CRL or OCSP can issue certificates it can never revoke.