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 a `google_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 | Operation | Area | Support | Depth | Notes | | ------------------------- | --------- | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DescribeCertificate | Describe | Supported | Common | returns the certificate's identity, realized at install time as the name of its TLS Secret | | ListCertificates | Describe | Supported | Most usage | lists the installed certificates, known at install time | | ImportCertificate | Issue | Supported | Most usage | a third-party certificate is brought in as a TLS Secret (or through a certificate-authority issuer), bringing its chain and key | | RequestCertificate | Issue | Supported | Common | realized when the install is built as a cert-manager Certificate bound to a Let's Encrypt ACME cluster issuer with a DNS-01 solver: publicly trusted, DNS-validated, and auto-renewed; the closest analog to a DNS-validated public certificate | | DeleteCertificate | Lifecycle | Supported | Most usage | realized at install time: the Certificate is removed, its readiness resource is folded away, and the consumer's reference is rewritten | | UpdateCertificateOptions | Lifecycle | Out of scope | Full surface | certificate-option updates are outside this mapping; ACM has deprecated transparency-logging opt-out for public certificates | | RenewCertificate | Renew | Supported | Most usage | cert-manager renews ahead of expiry through its renew-before window and the ACME issuer | | ExportCertificate | Retrieve | Supported | Most usage | the export reads the private key from the Kubernetes Secret cert-manager writes, readable in-cluster to anything with access, wider than the certificate's default key-access policy | | GetCertificate | Retrieve | Supported | Common | returns the certificate and its chain, never the private key | | AddTagsToCertificate | Tags | Supported | Full surface | tags become metadata labels and annotations | | RemoveTagsFromCertificate | Tags | Supported | Full surface | removes labels and annotations | | DNS validation | Validate | Supported | Common | an ACME DNS-01 solver proves domain control by publishing a DNS record, domain validation through DNS | | Email / HTTP validation | Validate | Out of scope | Most usage | there is no email or HTTP domain-approval flow that matches the origin's; a request for either validation method is rejected | #### 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-manager `Certificate` 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 The `Certificate` 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 ACME `Order` 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 the `renewBefore` 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 contains `tls.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 a `selfSigned` 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 | Operation | Area | Support | Depth | Notes | | ------------------------- | --------- | ------------ | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DescribeCertificate | Describe | Supported | Common | returns the certificate's identity, realized at install time as a vault certificate reference | | ListCertificates | Describe | Supported | Most usage | lists the installed certificates, known at install time | | ImportCertificate | Issue | Supported | Common | a third-party certificate imports as vault certificate contents (with its chain and passphrase) when you hold the key | | RequestCertificate | Issue | Partial | Common | realized when the install is built as a self-signed generate-policy vault certificate holding the subject and its alternative names; but a self-signed vault certificate is not publicly trusted; public, DNS-validated issuance needs a configured partner CA or the App Service Managed Certificate alternative | | DeleteCertificate | Lifecycle | Supported | Most usage | realized at install time: the vault certificate is removed and its consumer's reference is rewritten; the vault's own soft-delete retention holds it before it is purged | | UpdateCertificateOptions | Lifecycle | Out of scope | Full surface | certificate-option updates are outside this mapping; ACM has deprecated transparency-logging opt-out for public certificates | | RenewCertificate | Renew | Supported | Most usage | the certificate's lifetime action auto-renews a self-signed or partner-CA-integrated certificate; a manual (issuer-unknown) certificate does not auto-renew | | ExportCertificate | Retrieve | Supported | Most usage | the export reads the private key from the backing vault secret; the generated certificate is exportable, so the key is retrievable, wider than the certificate's default key-access policy, whose key is never returned | | GetCertificate | Retrieve | Supported | Common | returns the certificate and its chain, never the private key | | AddTagsToCertificate | Tags | Supported | Full surface | tags become vault-resource tags | | RemoveTagsFromCertificate | Tags | Supported | Full surface | removes tags | | DNS validation | Validate | Out of scope | Common | Key Vault has no DNS-CNAME domain-validation flow; issuance is governed by the certificate policy instead, so DNS validation is rejected | | Email / HTTP validation | Validate | Out of scope | Most usage | there is no email or HTTP domain-approval flow; a request for either validation method is rejected | #### 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 `azurerm_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 The `certificate_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 no `PENDING_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 An `azurerm_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's `lifetime_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 | Operation | Area | Support | Depth | Notes | | ------------------------- | --------- | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DescribeCertificate | Describe | Supported | Common | returns the certificate's identity, realized at install time as a certificate OCID | | ListCertificates | Describe | Supported | Most usage | lists the installed certificates, known at install time | | ImportCertificate | Issue | Supported | Common | a third-party certificate imports in the imported configuration, bringing its chain and key; import is the alternative for a certificate that must be publicly trusted | | RequestCertificate | Issue | Partial | Common | issuance is provisioned from an internal / private CA holding the subject and its alternative names, but OCI Certificates has no public, DNS-validated, browser-trusted issuance path; clients must explicitly trust the private root; this does not provide public trust | | DeleteCertificate | Lifecycle | Supported | Most usage | realized at install time: the certificate is scheduled for deletion and its consumer's reference is rewritten | | UpdateCertificateOptions | Lifecycle | Out of scope | Full surface | certificate-option updates are outside this mapping; ACM has deprecated transparency-logging opt-out for public certificates | | RenewCertificate | Renew | Supported | Most usage | a certificate renewal rule auto-renews an internally-issued certificate on a set interval with an advance renewal period | | ExportCertificate | Retrieve | Supported | Most usage | the certificate bundle can return the private key even for an internally-issued certificate, wider than the certificate's default key-access policy | | GetCertificate | Retrieve | Supported | Common | returns the certificate and its chain, never the private key | | AddTagsToCertificate | Tags | Supported | Full surface | tags become freeform tags (defined tags additionally take a tag namespace) | | RemoveTagsFromCertificate | Tags | Supported | Full surface | removes tags | | DNS validation | Validate | Out of scope | Common | there is no public, DNS-validated issuance (the internal CA signs directly), so DNS domain validation is rejected | | Email / HTTP validation | Validate | Out of scope | Most usage | there is no email or HTTP domain-approval flow; a request for either validation method is rejected | #### 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 The `certificate_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 With `ISSUED_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 A `CERTIFICATE_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.
#### Limitations **Public trust.** Internally issued certificates require clients to trust the private CA. For public trust, obtain and import a certificate from a CA the intended clients already trust. Importing a certificate does not itself establish trust. **Validation methods.** OCI internal issuance does not reproduce ACM public DNS, email, or CloudFront HTTP validation. The configured internal CA signs the certificate. **Private-key access.** CERTIFICATE\_CONTENT\_WITH\_PRIVATE\_KEY returns the key in the certificate bundle. Restrict that permission; default non-exportable ACM public certificates do not permit equivalent key retrieval. **Private issuance.** Certificates that name an AWS certificate\_authority\_arn use the separate ACM Private CA mapping. The certificate mapping does not transfer the AWS CA or its history. #### Other considerations **Assign permissions.** Use compartment IAM policies to control certificate management and bundle access. Grant the load balancer its required access, and restrict permission to retrieve bundles containing private keys. **Plan trust and renewal.** Oracle operates the CA service. The customer configures the CA, its key, and client trust. Internally issued certificates renew under certificate\_rules; imported certificates require a replacement from their issuing CA before expiry. **Cut over.** Provision or import the new OCI certificate and update the load balancer reference. Verify client trust, hostname coverage, and renewal at the listener. Existing ACM certificates are not moved automatically. [Service Catalog](/service-adapters/catalog).