A Private CA Whose Templates Cannot Issue for Any Name
A root CA, an intermediate it signs and certificate templates in IBM Cloud Secrets Manager. IBM's examples let a template issue for any name; here templates name their domains, both CAs carry name constraints, and CRLs are built and published. Lifetimes are checked to nest, and the module says plainly that Terraform cannot revoke a CA.
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-16 · how we verify
Use it from the registry
terraform · opentofumodule "private_ca" {
source = "www.iac-bazaar.com/iac-bazaar/ibm-private-ca/ibmcloud"
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
ibm-private-ca
A private CA hierarchy on IBM Cloud Secrets Manager. Works with Terraform and OpenTofu
(>= 1.6), ibm provider >= 1.60, < 3.0.
A template is the real policy, and IBM's examples allow any name. Here allow_any_name, localhost and glob patterns are always off, hostnames are enforced, and every template names its allowed domains.
Name constraints keep a leaked intermediate small. Both CAs carry permitted_dns_domains; empty is refused unless accept_unconstrained_ca is set.
Revocation only works if clients can find the CRL. CRL building and CRL distribution points are both on. Terraform cannot revoke a CA or rotate its CRL - IBM lists both as unsupported - so revoking is a console, API or CLI action; can_revoke_with_terraform says false.
Lifetimes nest. The intermediate must expire before the root and every template before the intermediate; the module checks at plan.
Deletion runs bottom-up or not at all. IBM refuses to delete a CA with children or a template with issued certificates, so destroying the module fails while certificates from it exist.
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
ibm-public-certificate
A publicly-trusted certificate issued into Secrets Manager, validated over DNS through Cloud Internet Services, with both configurations created here rather than left to a console. Staging issues a certificate no browser trusts while looking like success, so it is refused by name; auto-rotation and key rotation are on, because a ninety-day certificate nothing renews is a dated outage.
ibm-key-protect-key
The rotation policy is a separate resource nobody creates, so a key made today encrypts everything for the life of the account; dual_auth_delete, the control that makes deletion a two-person act, is off by default; and force_delete would remove a key buckets still use. Rotation on at your interval, dual authorization on (off by name), force delete never, the instance created when none is given.
ibm-secrets-manager
A secret group and an arbitrary secret in an IBM Cloud Secrets Manager instance you already have, over the private endpoint. The instance is a paid resource created once per account and is an input, so an apply never creates a second bill; the group is the unit IAM grants are made on; the value is a sensitive variable never output; an expiry is expected, none by name.
huawei-private-ca
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.
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.