Skip to main content
On this page

​
Coverage by target cloud

​
How the backends compare

Each row compares a capability of ACM Private CA with its adaptation on each backend. A dash means this row is not stated for that backend.

​
Infrastructure-only adaptation

​
On Google Cloud

​
How it works

Your PKI keeps issuing X.509 certificates from a managed private certificate authority (CA). Tensor9 deploys the CA hierarchy on Google Certificate Authority Service: a CA pool that holds a root CA and subordinate CAs. Application certificates chain through a subordinate CA to that private root. The CAs are created from your infrastructure code when the deployment is applied. Calls to the ACM Private CA API at run time are not part of this mapping. The root is new and has its own key, so clients must trust it before they receive certificates issued from it.
On AWS, your PKI issues certificates from ACM Private CA. On Google Cloud, it issues them from a Certificate Authority Service CA pool that holds its own private root.On AWS, your PKI issues certificates from ACM Private CA. On Google Cloud, it issues them from a Certificate Authority Service CA pool that holds its own private root.

Your certificates still chain to a private root you control, but it is a new root held by CA Service.

​
Architecture

Google runs Certificate Authority Service and protects the CA keys. In Terraform, the google_privateca_ca_pool holds the issuance policy, google_privateca_certificate_authority resources define the root and subordinate CAs, and each google_privateca_certificate is one issued certificate. The trust stores on your clients still decide which private roots your application trusts.
One CA pool holds a self-signed root CA and subordinate CAs. A subordinate CA issues your certificates, which chain to the root. The pool's issuance policy limits what may be issued.One CA pool holds a self-signed root CA and subordinate CAs. A subordinate CA issues your certificates, which chain to the root. The pool's issuance policy limits what may be issued.

The root signs subordinate CAs, which issue your certificates; the pool’s issuance policy limits what they issue.

​
The CA hierarchy

The SELF_SIGNED root signs subordinate CAs, and the subordinates issue application certificates. A two-tier hierarchy maps directly; a deeper tree adds more subordinate CAs. The root is new and has a new key. Certificates already issued on AWS keep chaining to the AWS root until they expire or are reissued, so distribute the new root to clients before you switch issuance.
An ACM Private CA of type ROOT becomes a SELF_SIGNED root CA in the pool, and a SUBORDINATE CA becomes a SUBORDINATE CA.An ACM Private CA of type ROOT becomes a SELF_SIGNED root CA in the pool, and a SUBORDINATE CA becomes a SUBORDINATE CA.

A ROOT CA becomes a SELF_SIGNED CA in the pool; a SUBORDINATE CA stays SUBORDINATE.

​
Issuing certificates

ACM Private CA splits signing a CA’s certificate-signing request (CSR) from installing the signed CA certificate, as two Terraform resources. On Google Cloud the deployment does both: the parent CA signs each subordinate, the subordinate is activated, and each CA is enabled. A newly created Google CA cannot issue until it is enabled, a subordinate CA must be activated first, and a pool issues only from an enabled CA. Each application certificate sets its subject, subject alternative names (SANs), key usages and validity. The pool’s issuance policy limits what can be issued.
ACM Private CA uses two Terraform resources to sign and install a CA certificate. On Google Cloud, the deployment signs, activates and enables each CA, and the pool then issues your certificates.ACM Private CA uses two Terraform resources to sign and install a CA certificate. On Google Cloud, the deployment signs, activates and enables each CA, and the pool then issues your certificates.

The deployment signs, activates and enables each CA before the pool issues certificates.

​
Issuance scoping

On AWS, the acm-pca:TemplateArn IAM condition limits which certificate templates a principal can request. Google splits this in two: Google IAM permissions decide who can use the CA resources, and the pool’s issuance_policy limits certificate identities and key usages. Review both when you translate a policy that varies by principal and template.
The acm-pca:TemplateArn IAM condition on AWS is covered by the CA pool's issuance policy together with Google IAM. Neither is a one-to-one template condition.The acm-pca:TemplateArn IAM condition on AWS is covered by the CA pool's issuance policy together with Google IAM. Neither is a one-to-one template condition.

The pool’s issuance policy and Google IAM together replace the template condition; neither matches it one to one.

​
Revocation and CRLs

A certificate revocation list (CRL) names certificates that clients should no longer trust. CA Service publishes CRLs itself, to a Cloud Storage bucket that either Google or you manage. The S3 bucket, its bucket policy and any custom CRL CNAME from ACM Private CA have no counterpart. You configure publication, bucket permissions and the distribution point clients use, and point any automation that reads or copies the old S3 CRL at the new location.
CA Service publishes CRLs to a Google-managed or customer-managed Cloud Storage bucket.CA Service publishes CRLs to a Google-managed or customer-managed Cloud Storage bucket.

CA Service publishes CRLs to a Google-managed or customer-managed Cloud Storage bucket.

​
Limitations

Limitations
  • Moving the AWS private key and certificate history is not supported. CA Service issues from a new root with its own key. Certificates already issued on AWS keep chaining to the AWS root until they expire or are replaced.
  • Issuance scoping behaves differently: there is no template condition. An acm-pca:TemplateArn condition becomes the pool’s issuance_policy plus Google IAM. Translate both who may request certificates and what they may contain.
  • CRLs in your S3 bucket are not supported. CA Service publishes CRLs to Cloud Storage. The S3 bucket, its bucket policy, its expiration setting and any custom CNAME are not kept; you set up the bucket and distribution point.
  • An OCSP responder is not supported. If the AWS CA runs OCSP, CA Service offers no matching endpoint. Clients check revocation with CRLs or rely on short certificate lifetimes, and the deployment reports a warning.
  • An organizational unit or country in the CA subject is not supported. Only the common name and organization are kept; the deployment warns about any other part it drops. Set the full distinguished name on the CA yourself if your certificate chain depends on it.
  • AWS-only CA settings are not supported. A usage_mode other than GENERAL_PURPOSE, an aws_acmpca_permission grant to ACM, and permanent_deletion_time_in_days have no Google equivalent. The deployment warns, and Google’s own settings apply.
  • Runtime ACM Private CA API calls are not supported. CAs are created from your infrastructure code when the deployment is applied, not by calls to the ACM Private CA API.

​
Other considerations

  • Before switching issuance. Distribute the new root to clients before you issue replacement certificates, and keep trusting the old root while certificates it issued are still in use.
  • CA settings. Confirm key algorithms and key protection when the CA is created. Set CA and certificate validity periods, and plan renewal before they expire.
  • Before going live. Test issuance and client revocation checks from the customer environment.

​
On Azure, OCI, and Private Kubernetes

​
Via cert-manager Issuer

​
How it works

Your PKI keeps issuing X.509 certificates that chain to a private root. On the target cluster, a cert-manager CA Issuer or ClusterIssuer signs them with a CA certificate and key stored in a Kubernetes Secret. This is the mapping on Kubernetes and on Azure, which has no managed private CA. No cloud provider runs this CA: your platform team operates cert-manager and protects the CA key, including on AKS. The CA is created from your infrastructure code when the deployment is applied. Calls to the ACM Private CA API at run time are not part of this mapping.
On AWS, your PKI issues certificates from ACM Private CA, which AWS runs. On the target cluster, it issues them from a cert-manager CA issuer that your platform team runs.On AWS, your PKI issues certificates from ACM Private CA, which AWS runs. On the target cluster, it issues them from a cert-manager CA issuer that your platform team runs.

Certificates chain to a new private root kept in a Kubernetes Secret, and your platform team runs the CA.

​
Architecture

The cert-manager controller watches Certificate resources, has the referenced CA issuer sign each one, and writes the certificate and its private key to the application’s Secret. An Issuer works within one namespace; a ClusterIssuer works across namespaces. You protect the CA Secret with access control, encryption and backups.
A CA issuer reads the CA certificate and key from a Kubernetes Secret and signs Certificate resources. Each issued certificate and key is written to its own Secret and chains to the private root.A CA issuer reads the CA certificate and key from a Kubernetes Secret and signs Certificate resources. Each issued certificate and key is written to its own Secret and chains to the private root.

The issuer signs with the key in the CA Secret, and each certificate lands in its own Secret.

​
The CA hierarchy

A root CA issuer can sign an intermediate CA certificate, and a second issuer then uses that intermediate CA to issue application certificates. A two-tier hierarchy maps directly. Each further tier needs its own issuer and CA certificate, with its own validity and rotation procedure, set up by hand.
An ACM Private CA root becomes a CA issuer backed by the CA Secret. A subordinate becomes an intermediate certificate that backs a second issuer. Deeper hierarchies are built by hand.An ACM Private CA root becomes a CA issuer backed by the CA Secret. A subordinate becomes an intermediate certificate that backs a second issuer. Deeper hierarchies are built by hand.

A subordinate CA becomes an intermediate certificate behind a second issuer; there is no managed ROOT or SUBORDINATE type.

​
Issuing certificates

Each Certificate sets its subject, subject alternative names (SANs), key usages and duration, and cert-manager renews it before it expires. The CA certificate in the issuer’s Secret is not renewed this way. Your operator must rotate it and distribute any changed trust chain to clients.
ACM Private CA uses two Terraform resources to sign and install a CA certificate. In cert-manager, the issuer already holds the CA, so there is no signing resource. It signs Certificate resources and cert-manager renews them automatically.ACM Private CA uses two Terraform resources to sign and install a CA certificate. In cert-manager, the issuer already holds the CA, so there is no signing resource. It signs Certificate resources and cert-manager renews them automatically.

The issuer already holds the CA, so there is no separate signing step; cert-manager renews certificates automatically.

​
Issuance scoping

Kubernetes RBAC controls who can create Certificate resources and use each issuer, along with the namespace an Issuer lives in. It does not reproduce the AWS acm-pca:TemplateArn IAM condition. When you translate issuance restrictions, review which callers can request certificates and which issuers they can reference.
On AWS, the acm-pca:TemplateArn IAM condition limits issuance. cert-manager limits it with Kubernetes RBAC on Certificate and Issuer objects, and has no template condition.On AWS, the acm-pca:TemplateArn IAM condition limits issuance. cert-manager limits it with Kubernetes RBAC on Certificate and Issuer objects, and has no template condition.

Kubernetes RBAC decides who may request certificates; nothing matches the acm-pca:TemplateArn condition.

​
Revocation and CRLs

cert-manager does not generate or publish certificate revocation lists (CRLs) or Online Certificate Status Protocol (OCSP) responses. If your clients check revocation, the CA operator must provide these services. Short certificate lifetimes limit how long a compromised certificate stays valid, but they do not revoke it before it expires.
ACM Private CA publishes CRLs to your S3 bucket. cert-manager has no built-in CRL, so the CA operator must provide revocation separately.ACM Private CA publishes CRLs to your S3 bucket. cert-manager has no built-in CRL, so the CA operator must provide revocation separately.

The CA operator must provide CRL generation and publication; cert-manager does not manage them.

​
Limitations

Limitations
  • You must operate the CA. No cloud provider runs it. Your platform team runs cert-manager, protects the CA key in its Kubernetes Secret, and rotates the CA certificate.
  • Moving the AWS private key and certificate history is not supported: cert-manager issues from a new private root with its own key. Certificates already issued on AWS keep chaining to the AWS root until they expire or are replaced.
  • CRLs and OCSP are not supported: cert-manager publishes neither. ACM Private CA’s S3 CRL bucket has no counterpart; if clients check revocation, the CA operator must provide it.
  • Issuance scoping behaves differently: there is no template condition. An acm-pca:TemplateArn condition becomes Kubernetes RBAC on Certificate and issuer objects, plus the choice of Issuer or ClusterIssuer.
  • Hierarchies deeper than two tiers behave differently: you build them by hand. There is no managed ROOT or SUBORDINATE type. Each extra tier needs its own issuer and CA certificate.
  • An organizational unit or country in the CA subject is not supported. Only the common name and organization are copied to the CA certificate. Set the full distinguished name yourself if your certificate chain depends on it.
  • AWS-only CA settings are not supported. A usage_mode other than GENERAL_PURPOSE, an aws_acmpca_permission grant to ACM, and permanent_deletion_time_in_days have no cert-manager equivalent; the deployment warns.

​
Other considerations

  • Before switching certificates. Distribute the new root to client trust stores, and keep trusting the old root during the transition.
  • What to monitor. Watch cert-manager and certificate renewal failures. Back up the CA Secret and rehearse CA rotation.
  • Hardware key protection. If the CA key must be in hardware, choose and configure an external signer or HSM-backed issuer instead of storing the key in a Kubernetes Secret.

​
On OCI

​
Via OCI Certificate Authority

​
How it works

Your PKI keeps issuing X.509 certificates from a managed private certificate authority (CA). Tensor9 deploys root and subordinate CAs in OCI Certificates, in a compartment. They issue application certificates that chain to a private root you control. The CAs are created from your infrastructure code when the deployment is applied. Calls to the ACM Private CA API at run time are not part of this mapping. The root is new and has its own key, so clients must trust it before they receive certificates issued from it.
On AWS, your PKI issues certificates from ACM Private CA. On OCI, it issues them from an OCI Certificates CA in a compartment, which holds its own private root.On AWS, your PKI issues certificates from ACM Private CA. On OCI, it issues them from an OCI Certificates CA in a compartment, which holds its own private root.

Your certificates still chain to a private root you control, but it is a new root held by OCI Certificates.

​
Architecture

Oracle runs OCI Certificates, and the CA hierarchy lives in a compartment. OCI IAM decides who may manage a CA or request certificates. Managed leaf certificate renewal follows configured rules: certificates that OCI manages renew automatically, by the renewal rules you set. CA renewal is initiated by the customer: you start it, and you rotate the CA vault key before creating the renewed CA version. The trust stores on your clients still decide which private roots your application trusts.
One compartment holds a root CA and subordinate CAs. A subordinate CA issues your certificates, which chain to the root. OCI IAM policy on the compartment controls who may issue.One compartment holds a root CA and subordinate CAs. A subordinate CA issues your certificates, which chain to the root. OCI IAM policy on the compartment controls who may issue.

The root signs subordinate CAs, which issue your certificates; IAM policy on the compartment controls who may issue.

​
The CA hierarchy

The root CA signs subordinate CAs, and the subordinates issue application certificates. A two-tier hierarchy maps directly; a deeper tree adds more subordinate CAs to the compartment, each with its own CA configuration. The root is new and has a new key. Certificates already issued on AWS keep chaining to the AWS root until they expire or are reissued.
An ACM Private CA of type ROOT becomes an OCI root CA, and a SUBORDINATE CA becomes an OCI subordinate CA, in the same compartment.An ACM Private CA of type ROOT becomes an OCI root CA, and a SUBORDINATE CA becomes an OCI subordinate CA, in the same compartment.

A ROOT CA becomes an OCI root CA and a SUBORDINATE CA an OCI subordinate CA.

​
Issuing certificates

ACM Private CA splits signing a CA’s certificate-signing request (CSR) from installing the signed CA certificate, as two Terraform resources. On OCI, creating the CA includes signing it, so there is no separate signing resource to reference. Each application certificate sets its subject, subject alternative names (SANs), key usages and validity. You configure renewal for the certificates OCI manages.
ACM Private CA uses two Terraform resources to sign and install a CA certificate. On OCI, creating the CA signs and activates it, and the CA then issues your certificates.ACM Private CA uses two Terraform resources to sign and install a CA certificate. On OCI, creating the CA signs and activates it, and the CA then issues your certificates.

Creating an OCI CA also signs and activates it; there is no separate signing step.

​
Issuance scoping

On AWS, the acm-pca:TemplateArn IAM condition limits which certificate templates a principal can request. OCI combines IAM permissions on the CA with the CA’s issuance settings. Translate both who may call and what the certificates may contain; access to the compartment alone does not express a template condition.
The acm-pca:TemplateArn IAM condition on AWS is covered by OCI IAM policy on the compartment together with the CA's issuance settings. Neither is a one-to-one template condition.The acm-pca:TemplateArn IAM condition on AWS is covered by OCI IAM policy on the compartment together with the CA's issuance settings. Neither is a one-to-one template condition.

OCI IAM policy and the CA’s issuance settings together replace the template condition; neither matches it one to one.

​
Revocation and CRLs

A certificate revocation list (CRL) names certificates that clients should no longer trust. OCI Certificates produces the CRL and publishes it to an Object Storage bucket you configure. You set up the bucket, object naming, the CA’s write permission and the distribution-point URL clients use. The S3 bucket, its bucket policy and any custom CRL CNAME from ACM Private CA have no counterpart, so point any automation that reads or copies the old S3 CRL at the OCI bucket.
OCI Certificates publishes CRLs to a configured Object Storage bucket.OCI Certificates publishes CRLs to a configured Object Storage bucket.

OCI Certificates publishes CRLs to a configured Object Storage bucket.

​
Limitations

Limitations
  • Moving the AWS private key and certificate history is not supported. OCI Certificates issues from a new root with its own key. Certificates already issued on AWS depend on the AWS root and its revocation information until they expire or are replaced.
  • Issuance scoping behaves differently: there is no template condition. An acm-pca:TemplateArn condition becomes OCI IAM policy on the CA plus its issuance settings. Translate both who may request certificates and what they may contain.
  • CRLs in your S3 bucket are not supported. OCI publishes CRLs to an Object Storage bucket. The S3 bucket, its bucket policy, its expiration setting and any custom CNAME are not kept; you set up the bucket and distribution point.
  • An OCSP responder is not supported. If the AWS CA runs OCSP, there is no matching endpoint on OCI. Clients check revocation with CRLs or rely on short certificate lifetimes, and the deployment reports a warning.
  • An organization, organizational unit or country in the CA subject is not supported. Only the common name is kept; the deployment warns about each part it drops. Set the full distinguished name on the CA yourself if your certificate chain depends on it.
  • You must set the CA validity period yourself. The deployed CA uses a fixed placeholder expiry, not the validity from ACM Private CA, and the deployment warns about it. Set the validity on the OCI CA and renew it well before that date.
  • AWS-only CA settings are not supported. A usage_mode other than GENERAL_PURPOSE, an aws_acmpca_permission grant to ACM, and permanent_deletion_time_in_days have no OCI equivalent. The deployment warns, and OCI’s own settings apply.
  • Runtime ACM Private CA API calls are not supported. CAs are created from your infrastructure code when the deployment is applied, not by calls to the ACM Private CA API.

​
Other considerations

  • Before switching issuance. Distribute the new root before you issue replacement certificates, and keep trusting the old root during the transition.
  • CA settings and renewal. Confirm key protection and certificate validity settings. Configure renewal for managed certificates, and schedule CA renewal and key rotation, which you start.
  • Revocation. Test CRL publication and retrieval by clients. Keep the CRL bucket and its access policy available for as long as clients rely on certificates issued by that CA.

​
Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.