- Coverage by target cloud
- How the targets compare
- On Google Cloud
- On Azure, OCI, and Private Kubernetes
- On Azure
- On OCI
Coverage by target cloud
How the targets compare
Each row compares a capability of ACM (certificates) 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
ACM issues and renews TLS certificates, which your infrastructure references by ARN from a load balancer, CDN, or API gateway. That service handles TLS for the application. By default, ACM does not expose the private key. The operation names shown on this page describe infrastructure equivalents configured during installation. This mapping does not serve runtime AWS ACM API requests. Certificate issuance, retrieval, renewal, and deletion use the target service and its access controls. Tensor9 provisions a Google-managed certificate during installation and attaches it to the HTTPS load balancer or proxy serving your application. Google handles certificate issuance and renewal. The adapter does not process application requests.
Tensor9 provisions and attaches a Google-managed certificate during installation.
The two certificate modes
google_certificate_manager_certificate supports two mutually exclusive modes. In managed mode, you provide domains and dns_authorizations. Google issues a publicly trusted certificate and renews it, corresponding to ACM RequestCertificate.
In self_managed mode, you provide pem_certificate, including its chain, and pem_private_key. Google serves this imported certificate, corresponding to ImportCertificate, but you must renew it. Google chooses the key algorithm for managed certificates; use an imported certificate if you need to choose the algorithm.
One google_certificate_manager_certificate has exactly one mode: a Google-issued managed block, or a self-supplied self_managed block, the two analogs of ACM’s RequestCertificate and ImportCertificate .
The dns_authorization CNAME
For ACM DNS validation,RequestCertificate returns the certificate ARN. DescribeCertificate supplies its DNS validation CNAME while the certificate is PENDING_VALIDATION. Publishing that record proves domain control. ACM then marks the certificate ISSUED and uses the DNS authorization for subsequent renewal.
A google_certificate_manager_dns_authorization similarly returns a dns_resource_record CNAME to publish in your DNS zone. The managed certificate references it through dns_authorizations. One authorization covers a domain and its wildcard, such as example.com and *.example.com. The adapter rejects ValidationMethod=EMAIL and HTTP; DNS is the supported method.
A DNS-validated certificate issues by proving domain control with a CNAME; Google’s dns_authorization produces a dns_resource_record CNAME for Google domain validation, added to the same zone. This mapping uses DNS validation.
The certificate map
On AWS, a TLS consumer references the certificate by ARN. The load balancer listener, CloudFront distribution, or API gateway performs the TLS handshake. Google Certificate Manager supports agoogle_certificate_manager_certificate_map whose certificate_map_entry records associate hostnames with certificates. A target HTTPS proxy selects a certificate using the client’s Server Name Indication (SNI) hostname. Tensor9 rewrites the consumer reference to the certificate configuration on the target HTTPS proxy.
On AWS the certificate is an ARN on the listener; on Google it is a certificate_map of hostname→certificate entries the HTTPS proxy consults, with SNI routing modeled as its own resource rather than a listener field.
Private-key access
Default ACM public certificates are non-exportable:GetCertificate returns the certificate and chain without the key. Since 2025, ACM has also offered opt-in exportable public certificates.
Google does not expose managed-certificate private keys. An imported certificate’s pem_private_key is accepted as input but never returned on read. This preserves non-exportability for the generated managed certificate. It does not reproduce ACM’s opt-in managed-key export feature.
Google never returns managed private keys or the private keys supplied with imported certificates.
Limitations
Validation methods. This mapping uses DNS authorization. It does not reproduce ACM email approval or CloudFront HTTP validation. Certificate attachment. A certificate map connects hostnames to certificates on the HTTPS proxy. Check each hostname and consumer attachment when replacing the AWS certificate ARN. Certificate transparency. Public certificates are logged. ACM has deprecated its transparency-logging opt-out; the adapter does not map that former option. Key algorithm and export. Google chooses managed-certificate keys and does not export them. Import a self-managed certificate when you need a particular algorithm; you must then supply renewed certificates. ACM hosted-ACME configuration is outside this mapping. Private issuance. Certificates that name an ACM Private CA through certificate_authority_arn use the separate private-CA mapping. Google private issuance can use CA Service through issuance_config.Other considerations
Prepare DNS and trust. Create the DNS authorization records and keep them available for renewal. New Google-managed certificates are issued during installation; existing ACM certificates and keys are not transferred. Operate the TLS consumer. The customer controls the Google project, DNS zone, and load balancer. Google issues and renews managed certificates. Verify that the proxy serves the right certificate for every hostname. Import deliberately. For an imported certificate, supply the PEM certificate, chain, and private key. Protect that input and arrange replacement before expiry; Google does not renew imported certificates.On Azure, OCI, and Private Kubernetes
Via cert-manager Certificate
How it works
ACM issues and renews TLS certificates, which your infrastructure references by ARN from a load balancer, CDN, or API gateway. That service handles TLS for the application. By default, ACM does not expose the private key. The operation names shown on this page describe infrastructure equivalents configured during installation. This mapping does not serve runtime AWS ACM API requests. Certificate issuance, retrieval, renewal, and deletion use the target service and its access controls. Tensor9 creates a cert-managerCertificate during installation and updates the Ingress to reference its TLS Secret. cert-manager obtains the certificate through an ACME ClusterIssuer and stores the certificate and key in that Secret. The Ingress handles application TLS traffic.
cert-manager stores the certificate in a TLS Secret that the Ingress uses for TLS.
The Certificate and its ACME ClusterIssuer
TheCertificate resource (cert-manager.io/v1) declares secretName, commonName, dnsNames, duration, renewBefore, and privateKey settings. These describe the output Secret, domain names, validity and renewal periods, and key algorithm, size, and rotation policy. Duration defaults to 90 days. issuerRef selects the Let’s Encrypt ACME ClusterIssuer.
The issuer’s spec.acme names the public CA, a contact email, and a solvers list. A dns01 solver proves domain control with a DNS record. ACM’s hosted ACME service, introduced in 2026, uses the same protocol.
The adapter emits two resources: a Certificate that names the tls Secret to write, and, bound to it by issuerRef , an ACME ClusterIssuer whose dns01 solver proves domain control.
How the certificate is issued
cert-manager opens an ACMEOrder and publishes an _acme-challenge DNS record. The CA checks that record and signs the certificate. cert-manager writes the certificate and private key to the TLS Secret, then sets the Certificate’s Ready condition to true.
The Ready condition replaces ACM’s separate validation-wait resource. This adapter supports dns01; requests for EMAIL or HTTP validation return errors.
The dns01 solver publishes a DNS record, the ACME authority reads it to confirm you control the domain, and the signed certificate and key land in the tls Secret as the Certificate turns Ready .
Certificate renewal
cert-manager renews the certificate before expiry using therenewBefore window. By default it begins renewal roughly two-thirds of the way through the certificate’s duration, repeating the ACME validation and issuance process.
Renewal updates the certificate and key under the same secretName, so the Ingress reference remains valid. Imported certificates supplied as TLS Secrets are not automatically renewed.
Renewal changes the contents of the tls Secret, not its name, so the Ingress reference is stable, the same way an ACM certificate keeps its ARN across a renewal.
Where the private key lives
The Secret containstls.crt and tls.key. Any principal permitted to read it can retrieve the private key. Default ACM public certificates do not expose that key.
Restrict Secret reads with Kubernetes role-based access control (RBAC), using Role and RoleBinding permissions for the relevant ServiceAccount. ACM’s opt-in exportable public certificates, available since 2025, also permit key retrieval; the difference described here is relative to default non-exportable certificates.
Read access to the TLS Secret includes access to the private key in tls.key .
The air-gapped fallback
Public ACME issuance requires the cluster to reach the public CA and publish DNS challenge records. The resulting certificate is trusted by clients that trust the CA. For a cluster without public-CA access, configure aselfSigned or ca issuer. This produces a privately trusted certificate; distribute the private root to every intended client. It does not provide public trust.
Public trust depends on the cluster reaching a public ACME authority; a cluster without public-CA access needs a selfSigned or ca issuer, which is privately trusted, not public.
Limitations
Private-key access. The TLS Secret contains both the certificate and private key. Restrict reads to the identities that require them. Default ACM public certificates do not expose their private keys. Public-CA connectivity. Public issuance needs access to the ACME CA and DNS challenge publication. Without that access, a private CA or self-signed issuer requires explicit client trust configuration. Validation methods. This mapping uses ACME DNS-01. It does not translate ACM email approval or CloudFront HTTP validation into ACME HTTP-01 challenges. Other ACM options. The adapter does not reproduce ACM hosted-ACME endpoint configuration or ManagedBy=CLOUDFRONT. Public certificates are logged; ACM has deprecated the transparency-logging opt-out. Private issuance. Certificates naming certificate_authority_arn use the separate ACM Private CA mapping. cert-manager CA and Vault issuers have their own trust and operating requirements.Other considerations
Operate cert-manager. The platform team installs, monitors, and updates cert-manager and its ClusterIssuer. Grant the DNS solver access to the required zone and monitor failed Orders and Certificate readiness. Check renewal at the consumer. Renewal writes a new certificate to the same Secret. Verify that the Ingress reloads it and serves the renewed certificate. Secret identity remains stable; imported TLS Secrets require separately supplied replacements. Cut over. Wait for the new Certificate to become Ready before switching traffic. Existing ACM certificates are not transferred automatically. Import a certificate and key you already hold as a kubernetes.io/tls Secret if they must be retained.On Azure
Via Key Vault
How it works
ACM issues and renews TLS certificates, which your infrastructure references by ARN from a load balancer, CDN, or API gateway. That service handles TLS for the application. By default, ACM does not expose the private key. The operation names shown on this page describe infrastructure equivalents configured during installation. This mapping does not serve runtime AWS ACM API requests. Certificate issuance, retrieval, renewal, and deletion use the target service and its access controls. Tensor9 provisions anazurerm_key_vault_certificate in the customer deployment’s shared Azure Key Vault and updates the service that handles TLS to reference it. This happens during installation. The generated certificate is self-signed, so clients must trust it explicitly; it does not provide ACM public-certificate trust.
During installation, Tensor9 provisions a Key Vault certificate and updates its TLS consumer.
The Key Vault certificate and its policy
Thecertificate_policy defines the certificate. domain_name becomes x509_certificate_properties.subject; subject_alternative_names becomes subject_alternative_names.dns_names, including wildcards. key_algorithm sets key_properties.key_type and key_size. A lifetime_action with AutoRenew enables renewal. An existing certificate and key can instead be imported using certificate.contents and its passphrase.
The generated policy sets issuer_parameters.name = Self. Key Vault generates the key and self-signs from the policy. Wait for its certificate operation to complete; no separate DNS approval is required.
The request compiles onto one azurerm_key_vault_certificate ; its certificate_policy holds the subject, the alternative names, the key, and the renewal rule; its issuer parameter is Self .
The self-signed certificate, and the public-trust gap
A self-signed certificate has noPENDING_VALIDATION stage or CNAME challenge. Issuance completes directly from the certificate policy.
Clients must explicitly trust the self-signed certificate before accepting it. For a publicly trusted certificate, configure a supported partner certificate authority (CA), such as DigiCert or GlobalSign, as the issuer. App Service Managed Certificates provide another option for eligible App Service hostnames.
Key Vault issues the self-signed certificate without a DNS challenge. Clients must be configured to trust it.
The App Service Managed Certificate
Anazurerm_app_service_managed_certificate uses an existing custom_hostname_binding to validate the hostname. Azure and DigiCert issue the publicly trusted certificate; Microsoft manages renewal without a certificate charge.
App Service Managed Certificates cover one exact hostname, do not support wildcards, and require an internet-reachable App Service for validation. They cannot be attached to an arbitrary load balancer. Use a configured partner CA when these restrictions do not fit your deployment.
App Service Managed Certificates are publicly trusted and renew automatically. They cover one reachable App Service hostname and no wildcards.
The exportable key
GetCertificate returns an ACM certificate and chain without the key. Default public certificates are non-exportable; ACM has also offered opt-in exportable public certificates since 2025.
Tensor9 currently sets key_properties.exportable = true. Anyone allowed to read the backing Key Vault secret can therefore retrieve the private key. To prevent export, configure exportable = false or use a non-exportable RSA-HSM or EC-HSM key. This is a configuration change from the generated default.
The generated Key Vault certificate is exportable: permission to read its backing secret permits reading the private key.
Auto-renew on the certificate’s lifetime action
The certificate’slifetime_action sets action_type = AutoRenew and a trigger expressed as days_before_expiry or lifetime_percentage. Renewal creates a new certificate and secret version. Consumers must use a versionless secret reference, or update their versioned reference, to receive the renewed certificate.
Self-signed certificates (issuer = Self) and certificates from integrated partner CAs support automatic renewal. Imported or manually managed certificates (issuer = Unknown) require you to obtain and import a replacement before expiry.
Automatic renewal creates a new version. A versionless secret reference lets a compatible consumer follow renewed versions.
Limitations
Public trust. The generated Key Vault policy uses issuer Self. Clients must explicitly trust that certificate. Public trust requires an integrated partner CA or an eligible App Service Managed Certificate; the latter covers one exact App Service hostname and no wildcard. Validation. This mapping does not reproduce ACM DNS, email, or CloudFront HTTP validation. Key Vault issuance follows its certificate policy and configured issuer. Private-key access. The generated key is exportable through the backing secret. Set exportable=false or choose an appropriate non-exportable HSM key when export is prohibited, and restrict secret reads. Private issuance. A certificate that names certificate_authority_arn uses the separate ACM Private CA mapping. It is not automatically recreated by this self-signed Key Vault policy.Other considerations
Assign permissions. The provisioning identity needs certificate-management permissions. The gateway or App Service needs access to the backing secret under its own Azure identity. Grant only the required vault or object scope. Configure renewal. Self-signed and integrated partner-CA certificates can renew through lifetime_action. Use a versionless secret reference where the TLS consumer supports it, or update the consumer to the new version. Imported certificates require you to supply replacements. Cut over and recover. Import an existing certificate, chain, and key when you must preserve them; otherwise installation creates a new certificate. Verify client trust and consumer access before switching traffic. Key Vault soft-delete retention affects recovery and name reuse.On OCI
Via OCI Certificate
How it works
ACM issues and renews TLS certificates, which your infrastructure references by ARN from a load balancer, CDN, or API gateway. That service handles TLS for the application. By default, ACM does not expose the private key. The operation names shown on this page describe infrastructure equivalents configured during installation. This mapping does not serve runtime AWS ACM API requests. Certificate issuance, retrieval, renewal, and deletion use the target service and its access controls. Tensor9 provisions an OCI Certificates resource during installation and updates the OCI load balancer to reference it. OCI issues new certificates from a private CA. Clients must trust that CA explicitly; publicly trusted certificates must be obtained separately and imported.
During installation, Tensor9 provisions an OCI certificate and updates the load balancer reference.
The certificate’s config type
Thecertificate_config.config_type on oci_certificates_management_certificate selects issuance. Tensor9 uses ISSUED_BY_INTERNAL_CA for a new certificate, or IMPORTED with certificate_pem, private_key_pem, and cert_chain_pem for an existing one. OCI also supports MANAGED_EXTERNALLY_ISSUED_BY_INTERNAL_CA for external certificate-signing requests (CSRs), but that mode is outside this adapter’s coverage.
For internal issuance, DomainName becomes subject.common_name. Subject alternative names become subject_alternative_names entries with DNS or IP types and values. The resource also sets certificate_profile_type, such as TLS_SERVER, and key_algorithm, such as RSA2048 or ECDSA_P256.
The adapter creates an internally issued certificate or imports an existing certificate, according to config_type .
Internal-CA issuance and public trust
WithISSUED_BY_INTERNAL_CA, the CA named by issuer_certificate_authority_id signs the certificate. Its chain ends at your private root. Distribute that root to each client’s trust store; browsers do not trust it by default.
For public trust, import a certificate issued by a public CA that the intended clients trust. Importing alone does not make a certificate publicly trusted. The adapter rejects ACM public DNS-validated issuance requests because OCI Certificates does not provide that issuance flow.
An internally issued certificate requires private-root distribution. For public trust, import a certificate from a CA your clients already trust.
Auto-renewal with certificate_rules
ACERTIFICATE_RENEWAL_RULE in certificate_rules sets an advance_renewal_period, such as P30D, and a renewal_interval. Before not_after, OCI issues a new version under the same certificate OCID. The load balancer keeps that reference.
Automatic renewal covers internally issued certificates. For IMPORTED certificates, obtain and import a replacement before expiry; OCI cannot renew a certificate issued by another CA.
A certificate_rules renewal rule renews an internally-issued certificate one advance_renewal_period before not_after , in place, keeping the same OCID, so the load balancer reference never has to change.
Attaching to the OCI load balancer
The load balancer references the certificate by OCID and handles TLS for the application. Certificate provisioning happens during installation; no Tensor9 certificate adapter handles application traffic. Tensor9 rewrites the AWS certificate ARN reference to the provisioned OCI certificate’s OCID. This applies to both internally issued and imported certificates.
On OCI a certificate is used by reference (a certificate OCID on the load balancer’s listener), the same shape as an ACM ARN on a TLS terminator; the load balancer handles client TLS.