- Coverage by target cloud
- How the targets compare
- On Google Cloud
- On Azure, OCI, and Private Kubernetes
- On OCI
Coverage by target cloud
How the targets compare
Each row compares a capability of ACM Private CA with its adaptation on each target. A dash means this row is not stated for that target.Infrastructure-only adaptation
On Google Cloud
How it works
Tensor9 provisions a private certificate authority (CA) hierarchy on Google Certificate Authority Service. A CA pool groups the root and subordinate CAs; application certificates chain through the issuing CA to that private root. The deployment uses infrastructure as code. Runtime ACM Private CA API calls are outside this mapping.
The ACM Private CA hierarchy is re-expressed as a GCP Certificate Authority Service CA pool with its own private root, so your PKI keeps issuing certificates that chain to a private root you control.
Architecture
Google operates the CA service and protects the CA keys. Thegoogle_privateca_ca_pool holds issuance policy; CA resources define the root and subordinates, and google_privateca_certificate represents an issued certificate. Client trust stores determine which private roots the application trusts.
A CA pool holds a self-signed root CA and subordinate CAs; the subordinate issues leaf certificates that chain to the private root, with the pool’s issuance policy governing what may be issued.
The CA hierarchy
ASELF_SIGNED root signs subordinate CAs, which issue application certificates. The mapped hierarchy uses a new root and key. Previously issued AWS certificates continue to chain to the old root until they expire or are reissued. Distribute the new root to clients before switching issuance.
ACM Private CA’s ROOT and SUBORDINATE types map onto a SELF_SIGNED root CA and SUBORDINATE CAs inside the CA pool.
Issuing certificates
ACM Private CA separates signing a certificate-signing request (CSR) from installing the resulting CA certificate. For the mapped Google hierarchy, infrastructure configuration handles parent signing, activation, and the enabled state. Native root CAs start staged; subordinate CAs require activation and then become staged. A pool needs an enabled CA before it can issue certificates. Application certificates specify their subject, subject alternative names (SANs), key usages, and validity; the pool issuance policy constrains what may be issued.
The mapped infrastructure handles CA signing, activation, and enablement before the pool issues leaf certificates.
Issuance scoping
The AWSacm-pca:TemplateArn IAM condition restricts which templates a principal can request. Google IAM permissions control access to CA resources, while the pool’s issuance_policy constrains certificate identities and key usages. Review both controls when translating a policy that varies by principal and template.
ACM Private CA’s acm-pca:TemplateArn IAM condition maps to the CA pool’s issuance policy, not a one-to-one template-ARN condition.
Revocation and CRLs
A certificate revocation list (CRL) identifies certificates that should no longer be trusted. CA Service publishes CRLs to Cloud Storage, using either a Google-managed or customer-managed bucket. Configure publication, bucket permissions, and the distribution point clients use. Automation that reads or copies the old S3 CRL must use the new location and permissions.
CA Service publishes CRLs to a Google-managed or customer-managed Cloud Storage bucket.
Limitations
The new root does not inherit the AWS private key or issued-certificate history. AWS template conditions and S3 bucket policies need target-specific configuration. These differences affect trust distribution and issuance permissions even when the certificate hierarchy is unchanged.Other considerations
Distribute the new root before issuing replacement certificates, and retain trust in the old root while existing certificates remain in use. Set CA and certificate validity periods and arrange renewal before expiry. Confirm key algorithms and protection settings at CA creation, then test issuance and client revocation checks from the customer environment.On Azure, OCI, and Private Kubernetes
Via cert-manager Issuer
How it works
A cert-manager CAIssuer or ClusterIssuer signs application certificates using a CA certificate and key stored in a Kubernetes Secret. The customer platform team operates this CA, including on AKS. Provisioning uses infrastructure as code; runtime ACM Private CA API calls are outside this mapping.
The ACM Private CA hierarchy is re-expressed as a cert-manager CA Issuer backed by a CA in a Kubernetes Secret, chaining to a private root the cluster holds; your platform team operates it.
Architecture
The cert-manager controller watchesCertificate resources, signs them through the referenced CA Issuer, and writes each certificate and private key to the application’s Secret. An Issuer is namespace-scoped; a ClusterIssuer is available across namespaces. Protect the CA Secret with access control, encryption, and backups.
A ClusterIssuer references a CA certificate and key in a Kubernetes Secret and issues Certificate resources; each issued key pair lands in its own Secret, chaining to the private root.
The CA hierarchy
A root CA Issuer can sign an intermediate Certificate. A second Issuer uses that intermediate CA to issue application certificates. Each additional tier needs its own Issuer and CA certificate configuration, including validity and rotation procedures.
A root CA Issuer plus an intermediate Certificate that becomes a second Issuer models a subordinate; deep multi-tier hierarchies are assembled by hand, not a managed ROOT / SUBORDINATE type.
Issuing certificates
A Certificate specifies its subject, subject alternative names (SANs), key usages, and duration. cert-manager renews leaf certificates before expiry. The CA certificate supplied in the Issuer’s Secret has a separate lifecycle: the operator must rotate it and distribute any changed trust chain to clients.
ACM Private CA’s CSR-sign-then-activate pair is implicit in the cert-manager CA Issuer; Certificate resources are signed by the issuer and renewed automatically.
Issuance scoping
Kubernetes RBAC controls access to Certificate and Issuer resources, together with their namespace scope. It does not reproduce the AWSacm-pca:TemplateArn IAM condition. Review which callers can request certificates and which issuer references they can use when translating issuance restrictions.
cert-manager scopes issuance with Kubernetes RBAC on Certificate and Issuer objects; there is no acm-pca:TemplateArn analog.
Revocation and CRLs
cert-manager does not generate or publish certificate revocation lists (CRLs) or Online Certificate Status Protocol (OCSP) responses. The CA operator must supply these services if clients require revocation checking. Short certificate lifetimes reduce the remaining validity of a compromised certificate; they do not revoke it before expiry.
The CA operator must provide CRL generation and publication; cert-manager does not manage them.
Limitations
The platform team operates cert-manager and protects the CA key. This configuration uses a new private root; AWS private keys and issued-certificate history do not migrate. CA rotation, revocation services, and additional hierarchy tiers require operator configuration.Other considerations
Distribute the new root to client trust stores before switching certificates, while retaining old trust for the transition. Monitor cert-manager and renewal failures, back up the CA Secret, and rehearse CA rotation. If the CA key requires hardware protection, choose and configure a suitable external signer or HSM-backed issuer rather than storing that key directly in a Kubernetes Secret.On OCI
Via OCI Certificate Authority
How it works
Tensor9 provisions root and subordinate certificate authorities (CAs) in OCI Certificates. They issue application certificates that chain to a private root controlled by the customer. The deployment uses infrastructure as code; runtime ACM Private CA API calls are outside this mapping.
The ACM Private CA hierarchy is re-expressed as an OCI Certificates CA in a compartment with its own private root, so your PKI keeps issuing certificates that chain to a private root you control.
Architecture
OCI Certificates manages the CA hierarchy in a compartment. Oracle operates the service; OCI IAM controls who may manage a CA or request certificates. Managed leaf certificate renewal follows configured rules. CA renewal is initiated by the customer; rotate the CA vault key before creating the renewed CA version. Client trust stores determine which private roots the application trusts.
A compartment holds a root CA and subordinate CAs; a subordinate issues leaf certificates that chain to the private root, with OCI IAM compartment policy governing issuance.
The CA hierarchy
A root CA signs subordinate CAs, which issue application certificates. Additional subordinates require their own CA configuration. The mapped hierarchy uses a new root and key; existing AWS certificates continue to use the old root until they expire or are reissued.
ACM Private CA’s ROOT and SUBORDINATE types map onto a root CA and subordinate CAs inside the OCI compartment.
Issuing certificates
ACM Private CA separates signing a certificate-signing request (CSR) from installing the resulting CA certificate. For the mapped OCI hierarchy, CA creation includes signing. Application certificates specify the subject, subject alternative names (SANs), key usages, and validity. Configure rotation for certificates managed by OCI.
ACM Private CA’s CSR-sign-then-activate resource pair is implicit in OCI CA creation; leaves issue from the CA and rotate natively.
Issuance scoping
The AWSacm-pca:TemplateArn IAM condition restricts which templates a principal can request. OCI combines IAM permissions on the CA with its issuance configuration. Translate both the permitted callers and the permitted certificate content; compartment access alone does not express an AWS template condition.
ACM Private CA’s acm-pca:TemplateArn IAM condition maps to OCI IAM compartment policy on the CA, not a one-to-one template-ARN condition.
Revocation and CRLs
OCI Certificates publishes certificate revocation lists (CRLs) to a configured Object Storage bucket. Configure the bucket, object naming, write permissions for the CA, and distribution-point URL clients use. The service produces the CRL, while the customer controls the storage configuration. Replace automation that reads or copies the old S3 bucket with the corresponding OCI configuration.
OCI Certificates publishes CRLs to a configured Object Storage bucket.