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. The `google_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 A `SELF_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 AWS `acm-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 | Operation | Area | Support | Depth | Notes | | ------------------------------------------------------------------------------- | -------------- | -------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Issuance scoping (acm-pca:TemplateArn IAM condition) | Access control | Partial | Most usage | Kubernetes RBAC on the Certificate and Issuer objects plus the namespace-scoped Issuer vs cluster-wide ClusterIssuer choice, not an acm-pca:TemplateArn condition | | CSR-signing activation split (aws\_acmpca\_certificate\_authority\_certificate) | CA activation | Adapter-served | Most usage | the CSR-sign-then-install resource pair is implicit in the CA Issuer, which holds the CA certificate and key; there is no separate signing resource | | ACM Private CA control plane (CreateCertificateAuthority / issuance API / …) | Control plane | Out of scope | Full surface | CA provisioning happens through your infrastructure-as-code at apply, not runtime ACM Private CA API calls | | CA hierarchy (ROOT / SUBORDINATE types) | Hierarchy | Partial | Most usage | a root CA Issuer plus an intermediate Certificate that becomes a second Issuer models a subordinate; a two-tier hierarchy maps directly, but deep multi-tier hierarchies are assembled by hand, not a managed ROOT / SUBORDINATE type | | Certificate issuance (aws\_acmpca\_certificate / IssueCertificate) | Issuance | Supported | Common | cert-manager Certificate resources are signed by the CA Issuer and renewed automatically before they expire, with the subject / SANs / key usage / duration | | Private CA provisioning (aws\_acmpca\_certificate\_authority) | Provisioning | Supported | Common | a cert-manager CA Issuer / ClusterIssuer backed by a CA certificate and key in a Kubernetes Secret: a private CA the cluster holds, issuing certificates that chain to its private root | | CRL distribution (customer-owned S3 bucket) | Revocation | Out of scope | Full surface | cert-manager does not generate or publish CRLs; the CA operator must provide revocation services | #### How it works A cert-manager CA `Issuer` 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 watches `Certificate` 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 AWS `acm-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 | Operation | Area | Support | Depth | Notes | | ------------------------------------------------------------------------------- | -------------- | -------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Issuance scoping (acm-pca:TemplateArn IAM condition) | Access control | Partial | Most usage | OCI IAM compartment policy on the CA plus the CA's issuance configuration, not a one-to-one template-ARN principal condition | | CSR-signing activation split (aws\_acmpca\_certificate\_authority\_certificate) | CA activation | Adapter-served | Most usage | the CSR-sign-then-install resource pair is implicit in OCI CA creation; there is no separate signing resource to reference | | ACM Private CA control plane (CreateCertificateAuthority / issuance API / …) | Control plane | Out of scope | Full surface | CA provisioning happens through your infrastructure-as-code at apply, not runtime ACM Private CA API calls | | CA hierarchy (ROOT / SUBORDINATE types) | Hierarchy | Supported | Most usage | a root CA plus subordinate CAs mirror ACM Private CA's ROOT / SUBORDINATE types; a two-tier hierarchy maps directly, deeper trees add more subordinate CAs to the compartment | | Certificate issuance (aws\_acmpca\_certificate / IssueCertificate) | Issuance | Supported | Common | leaf certificates are issued from the CA and chain to the private root, with the subject / SANs / key usage / validity; OCI Certificates rotates managed certificates natively | | Private CA provisioning (aws\_acmpca\_certificate\_authority) | Provisioning | Supported | Common | an oci\_certificates\_management\_certificate\_authority root or subordinate CA in a compartment: a managed private CA that chains issued certificates to its own private root | | CRL distribution (customer-owned S3 bucket) | Revocation | Partial | Full surface | OCI Certificates publishes CRLs to a configured Object Storage bucket; translate bucket permissions and the distribution point | #### 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 AWS `acm-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.
#### 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. Previously issued certificates remain dependent on the old root and its revocation information until they expire or are replaced. #### Other considerations Distribute the new root before issuing replacement certificates and retain the old trust root for the transition. Confirm key protection and certificate validity settings, configure managed leaf renewal, schedule CA renewal and key rotation, and test CRL publication and client retrieval. Keep the CRL bucket and its access policy available for as long as clients rely on certificates issued by that CA. [Service Catalog](/service-adapters/catalog).