AWS ACM EU Alternative 2026: TLS Private Keys, Certificate Transparency Logs, and GDPR Under the CLOUD Act

Post #729 in the sota.io EU Compliance Series

AWS Certificate Manager automates the provisioning, renewal, and deployment of TLS certificates for AWS resources. ACM eliminates the operational burden of manual certificate management: it handles domain validation, requests certificates from Amazon's certificate authority, stores the resulting private keys, and renews certificates automatically before expiry. For AWS-native architectures, ACM is operationally attractive — certificates attach to Application Load Balancers, CloudFront distributions, and API Gateway endpoints without requiring engineers to handle private key files.

The operational appeal of ACM obscures a jurisdictional reality that matters for European organizations subject to GDPR. TLS certificates serve a specific cryptographic purpose: the private key associated with a certificate allows a server to prove its identity and establish an encrypted session. The private key is the most security-sensitive artifact in the TLS ecosystem — its exposure breaks the confidentiality of all TLS-protected communications. AWS Certificate Manager stores that private key. Amazon Web Services, Inc. is a Delaware corporation headquartered in Seattle, Washington. The CLOUD Act (18 U.S.C. § 2713) compels US companies to produce data stored or processed by them anywhere in the world when ordered by US courts or government agencies. The private key for your HTTPS endpoint lives in Amazon's infrastructure.

European engineering teams sometimes reason that TLS private keys are infrastructure credentials rather than personal data — and therefore outside GDPR's direct scope. This reasoning misses GDPR Article 32's broader requirement for appropriate technical and organizational security measures. A private key in the hands of a state actor enables passive decryption of historical TLS traffic captured before the incident. For organizations that process personal data over HTTPS endpoints whose certificates are managed by ACM, the private key's security is directly tied to the confidentiality of personal data in transit. The jurisdictional exposure of ACM's key storage is a security-relevant fact under Article 32, not merely a compliance technicality.

What AWS ACM Stores That Touches GDPR

ACM's GDPR exposure spans four distinct data categories: private key custody, Certificate Transparency log submissions, DNS validation access, and Private CA configuration.

TLS Private Keys in AWS-Managed HSMs

When ACM provisions a certificate, it generates the private key internally. That private key is stored in AWS-managed hardware security modules (HSMs) and never transmitted to the customer — ACM's architecture is designed so that customers cannot export the private key material from ACM-issued certificates. This design eliminates the risk of private key exposure through customer-side mishandling.

It does not eliminate the jurisdictional risk. The private key exists in AWS HSMs, operated by Amazon. Amazon's representation that keys are stored in HSMs and that key material is protected by hardware controls addresses a specific threat model — unauthorized access by external attackers, or unauthorized access by AWS employees. It does not address the legal compulsion threat model: a US government order compelling Amazon to produce records could reach ACM's operational infrastructure, including key management records and, in the relevant threat scenarios, the keys themselves or evidence of key usage.

AWS publishes documentation about ACM's key protection. Amazon's HSMs are compliant with FIPS 140-2 Level 3. Amazon's key management practices are audited. None of these technical and organizational controls alter the fundamental legal fact: Amazon is a US corporation, and the CLOUD Act's extraterritorial reach covers data held by US companies anywhere in the world. Technical protections operate within the threat model they are designed to address; the CLOUD Act operates outside that threat model.

For European organizations whose GDPR compliance analysis requires assessing whether data subject to CLOUD Act compulsion can be effectively protected through Standard Contractual Clauses — the analysis required by Schrems II and subsequent EDPB guidance — ACM's key storage represents a specific, non-trivial exposure point. If a state actor can compel production of the private key for your HTTPS endpoints, historical TLS traffic captured by that actor becomes decryptable. GDPR Article 32 requires organizations to implement measures that are appropriate to the risk — and this risk exists.

Certificate Transparency Logs: Your Domain Names as Permanent Public Records

Since April 2018, all publicly trusted TLS certificates must be logged to public Certificate Transparency (CT) logs before browsers will accept them. When ACM issues a public certificate for your domain, it submits that certificate to multiple CT logs. This submission is permanent, public, and irreversible.

A CT log entry for a certificate reveals:

• Your domain names: The Common Name and Subject Alternative Names (SANs) on the certificate — every hostname for which the certificate is valid
• Your subdomain structure: If you request a wildcard certificate (*.example.com) or a multi-domain certificate, the CT log entry reveals your subdomain architecture
• Issuance timestamp: When the certificate was issued, providing a timeline of your service launches and renewals
• Certificate authority: Which CA issued the certificate, including Amazon's CA for ACM-issued certificates

CT logs are intentionally public — they serve as an auditable record that helps detect certificate misbehavior. But for European organizations managing internal or sensitive domain names, CT log submissions create a permanent, globally accessible record of domain names that may not be intended for public enumeration.

This is not a GDPR violation in most cases — domain names are not typically personal data in the Article 4(1) sense. But CT log disclosures have operational security implications. Security researchers and attackers routinely monitor CT logs to discover new subdomains, identify organizational structure, and find targets for attack. An ACM-issued certificate for an internal API endpoint — even one accessible only from the corporate network — creates a CT log entry that reveals the endpoint's existence. AWS's submission to CT logs is mandatory for publicly trusted certificates; there is no opt-out.

For ACM Private CA certificates (see below), CT log submission is not automatic — private CA certificates are not submitted to public CT logs unless explicitly configured. This distinction matters for organizations that need to avoid CT log disclosure for internal service endpoints.

ACM Private CA: Root CA Hierarchy Under US Jurisdiction

ACM Private Certificate Authority provides a managed private PKI service — an internal certificate authority that issues certificates for internal services, microservices, IoT devices, or other endpoints that do not require publicly trusted certificates. ACM Private CA manages the CA hierarchy: root CA, subordinate CAs, and the certificate issuance process.

The Private CA service stores several categories of data in AWS infrastructure:

• CA private keys: The root CA and subordinate CA private keys, stored in AWS-managed HSMs. These keys sign every certificate your Private CA issues. If the CA private key were exposed, every certificate in your PKI would need to be revoked and reissued.
• CA hierarchy configuration: The subject distinguished name for your CA (including organization name and country), the CA chain structure, validity periods, and certificate policy configuration
• Certificate records: Metadata for every certificate issued by your Private CA — subject names, SANs, validity period, serial number, and revocation status
• Revocation infrastructure: ACM Private CA manages OCSP (Online Certificate Status Protocol) responders and Certificate Revocation Lists (CRLs) for certificates it issues. The revocation database records which certificates have been revoked and why.

For European organizations, the CA private key stored in ACM Private CA is the most sensitive element. A CA private key is the cryptographic root of trust for an entire PKI hierarchy. Its security determines whether certificates issued under that CA can be trusted. Storing the CA root key in US-jurisdiction infrastructure means that the foundation of your internal certificate trust is subject to CLOUD Act compulsion.

Organizations that deploy internal mTLS — mutual TLS authentication between microservices — frequently use ACM Private CA for certificate management. Each microservice certificate is signed by the private CA. If the CA key is accessible under legal compulsion, the entire mTLS trust model is subject to that jurisdictional exposure.

DNS Validation: AWS Access to Your DNS Records

ACM validates domain ownership before issuing certificates. The primary validation method is DNS validation: ACM provides a CNAME record that you add to your DNS zone. ACM's systems continuously query your DNS zone for that CNAME record to confirm domain control.

For ACM certificates with automatic renewal, the DNS validation CNAME remains in your DNS zone indefinitely — ACM checks it each time the certificate approaches expiry to confirm ongoing domain control before renewing. This means AWS's certificate validation infrastructure maintains ongoing access to query your DNS zones, including the timing and pattern of those queries.

More significantly, the DNS validation CNAME records added to your zones are themselves visible to anyone querying your DNS. For publicly hosted zones, the ACM validation CNAME (_acme-challenge style records, or ACM-specific CNAME prefixes) reveals that ACM is managing certificates for that domain. This subdomain enumeration can disclose your use of ACM to observers monitoring DNS zones.

For organizations using Amazon Route 53 for DNS hosting, the combination of Route 53 and ACM creates a complete picture of domain management within AWS systems: your DNS records are stored in Route 53 (US jurisdiction), your certificates are issued through ACM (US jurisdiction), and your private keys are held in ACM's HSMs (US jurisdiction).

CloudWatch Certificate Events and Monitoring

ACM publishes certificate lifecycle events to AWS services including AWS CloudTrail (for API calls) and Amazon EventBridge. Certificate issuance, renewal, and expiry notifications generate events in AWS's logging infrastructure. For organizations that route EventBridge events to operational monitoring tools or configure CloudWatch alarms for certificate expiry, those events and the logs they generate are stored in AWS's US-jurisdiction infrastructure.

Certificate expiry approaching, failed renewal events, and certificate status changes are operational data. For organizations with compliance obligations around certificate lifecycle management — for example, PCI DSS requirements for tracking certificate validity — those compliance records are held in AWS systems.

EU Alternatives to AWS ACM

European organizations requiring TLS certificate management without US-jurisdiction custody have several options ranging from fully managed EU-operated CAs to self-hosted open source PKI solutions.

Certbot with Let's Encrypt

Let's Encrypt (operated by the Internet Security Research Group, a US non-profit) is the dominant free CA for public TLS certificates. Let's Encrypt issues DV (Domain Validation) certificates at no cost and supports automated renewal via the ACME protocol. Certbot is the most widely used ACME client for interacting with Let's Encrypt.

A significant difference from ACM: when using Certbot with Let's Encrypt, the private key is generated on your own infrastructure and never transmitted to Let's Encrypt. Let's Encrypt's CA systems sign the certificate, but the private key remains under your control in your infrastructure. This is a fundamental architectural difference — ACM's design holds your private key; ACME-based certificate issuance leaves the private key with you.

Let's Encrypt's CA operations are US-based (Internet Security Research Group, California). Let's Encrypt receives your domain name and the public key during certificate issuance, and stores certificate records in its logs. It does not store your private key. For organizations whose primary concern is private key custody rather than CA jurisdiction, Let's Encrypt with Certbot running on EU-based infrastructure achieves the critical security property — private key under EU-jurisdiction control.

For organizations that require the CA itself to be EU-operated, Let's Encrypt's US incorporation is a disqualifying factor regardless of the private key architecture.

cert-manager on Kubernetes

cert-manager is an open source Kubernetes controller that automates certificate management within Kubernetes clusters. It supports multiple issuers including Let's Encrypt, custom ACME endpoints, HashiCorp Vault, and self-signed CAs. cert-manager generates private keys within the Kubernetes cluster (stored as Kubernetes Secrets) and uses the ACME protocol or other issuer protocols to obtain signed certificates.

For organizations running Kubernetes on EU-jurisdiction infrastructure — Hetzner, Scaleway, OVHcloud, or on-premises clusters — cert-manager provides ACME-based certificate management entirely within EU-controlled infrastructure. The private keys never leave the cluster. cert-manager is cloud-agnostic and does not require any AWS service.

cert-manager's EU-sovereignty story depends on the Kubernetes cluster's infrastructure jurisdiction. A cert-manager deployment on Hetzner Cloud (German GmbH) with Let's Encrypt as the issuer keeps private keys in Hetzner-hosted Kubernetes Secrets and submits only the public key and domain name to Let's Encrypt for signing. The private key remains in EU jurisdiction.

Smallstep CA (step-ca)

Smallstep's open source step-ca is a self-hosted certificate authority that supports ACME, JWK, OAuth/OIDC, and several other issuer protocols. step-ca allows organizations to run their own internal CA — including root CA and intermediate CAs — entirely within their own infrastructure, with complete control over private keys.

For organizations that need ACM Private CA equivalent functionality — an internal CA for issuing certificates to internal services, microservices, or IoT devices — step-ca provides a self-hosted alternative. The root CA and intermediate CA private keys are generated on and stored in customer-controlled infrastructure. There is no managed service provider holding the CA keys.

step-ca can be deployed on EU-jurisdiction infrastructure (Hetzner, Scaleway, on-premises), making the entire PKI hierarchy EU-controlled. step-ca also supports hardware security module integration via PKCS #11, allowing organizations to protect CA keys in on-premises HSMs or cloud-jurisdiction HSMs (for example, Thales or Entrust HSMs deployed in EU data centers).

D-Trust (Bundesdruckerei Group)

D-Trust GmbH is a German certificate authority, a subsidiary of Bundesdruckerei GmbH, which is 100% owned by the Federal Republic of Germany. D-Trust operates a German-law CA that issues publicly trusted TLS certificates, S/MIME certificates, and qualified electronic signatures under eIDAS.

D-Trust's TLS certificate issuance follows the same model as other commercial CAs: domain validation occurs through DNS or HTTP challenge, and D-Trust's CA systems issue the certificate and sign it with D-Trust's CA key. Private keys are generated by the customer and submitted as CSRs (Certificate Signing Requests) — D-Trust does not hold customer private keys.

D-Trust's CA infrastructure operates under German law (specifically under BSI oversight and eIDAS framework). D-Trust is a German GmbH without a US parent entity. The CLOUD Act's extraterritorial reach does not apply to D-Trust. For European organizations that require both a publicly trusted CA and a CA operating entirely under EU jurisdiction, D-Trust is one of the few options combining both properties.

D-Trust's TLS certificates are trusted in major browser root stores. Certificate pricing is commercial (per-certificate fees), unlike Let's Encrypt's free model. D-Trust's geographic focus is European organizations, particularly those in the DACH region.

SwissSign

SwissSign AG is a Swiss certificate authority, owned by Swiss Post (Schweizerische Post AG), the Swiss federal postal service. SwissSign operates from Rümlang, Switzerland, and issues publicly trusted TLS, S/MIME, and document signing certificates.

Switzerland is not an EU member state but maintains an EU adequacy decision for data protection purposes (the decision addresses transfers from EU to Switzerland, not CA jurisdiction). SwissSign operates under Swiss federal law — specifically the Federal Act on Data Protection (revDSG) and the Swiss Post's public mandate structure. SwissSign has no US parent entity and is not subject to the CLOUD Act.

For European organizations that require a non-US CA but are comfortable with Swiss jurisdiction, SwissSign provides commercially issued publicly trusted TLS certificates with Swiss-law operational control. SwissSign certificates require domain validation CSR submission — private keys remain customer-controlled.

EJBCA Community and Enterprise

EJBCA is an open source PKI and CA software originally developed by PrimeKey (now Keyfactor), a Swedish company. EJBCA Community (open source) and EJBCA Enterprise (commercial) allow organizations to deploy self-hosted PKI infrastructure on their own servers, including root CA, subordinate CAs, OCSP responders, and CMP/EST/ACME endpoint support.

For organizations requiring ACM Private CA equivalent functionality — a managed internal CA with a complete PKI hierarchy — EJBCA deployed on EU-jurisdiction infrastructure provides full CA operational control. Root and intermediate CA keys are generated by EJBCA within customer-controlled infrastructure. EJBCA supports HSM integration (SoftHSM, SafeNet, Thales) for hardware-protected key storage on customer premises or in EU-jurisdiction colocation facilities.

EJBCA Enterprise is commercially supported by Keyfactor (US headquarters, but the software remains customer-deployed). For organizations using EJBCA Community (open source), there is no US-jurisdiction managed service involved — the entire CA operation runs on customer-controlled infrastructure.

sota.io: TLS Management Within EU Jurisdiction

sota.io is a European PaaS that deploys applications on Hetzner Cloud and other EU-jurisdiction infrastructure. For applications deployed on sota.io, TLS certificate management is handled within EU-jurisdiction infrastructure — certificates are obtained and renewed using ACME protocols, with private keys generated and stored on Hetzner-operated compute infrastructure (Hetzner Online GmbH, a German company).

Applications migrated from AWS (ECS, Lambda, EC2 with ALB) to sota.io no longer require ACM for certificate management. The HTTPS endpoint for a sota.io-deployed application uses certificates managed within EU-operated infrastructure, eliminating ACM's private key custody, DNS validation access, and CloudWatch logging from the certificate management stack.

For organizations whose ACM usage exists because their applications run on AWS, migrating the application to EU-native hosting eliminates the certificate management dependency simultaneously with the application hosting dependency.

GDPR Risk Assessment for ACM

ACM's GDPR risk profile combines security risk (private key custody) with disclosure risk (CT log submissions) and operational data risk (validation access, CloudWatch events).

Private key custody under CLOUD Act jurisdiction: The private keys for ACM-issued certificates are held by Amazon, a US corporation. This is the highest-severity risk — private key exposure enables decryption of past TLS traffic. ACM's HSM-based key protection addresses the unauthorized-access threat model but not the legal-compulsion threat model. Organizations processing sensitive personal data over HTTPS endpoints whose certificates are managed by ACM should assess this risk explicitly under GDPR Article 32.

Certificate Transparency log disclosure: CT log submissions are mandatory for publicly trusted certificates and irreversible. Every ACM-issued public certificate creates a permanent record of your domain names in publicly accessible CT logs. This is operational security information rather than personal data in most cases, but organizations with sensitive subdomain structures should understand that ACM's certificate issuance makes those subdomains enumerable.

ACM Private CA: CA root key under US jurisdiction: The root CA key for ACM Private CA installations is stored in AWS-managed HSMs. This is the cryptographic root of trust for an entire internal PKI. For organizations using ACM Private CA for mTLS or internal service certificates, the CA's root of trust is under US-jurisdiction custody.

DNS validation access: Automatic certificate renewal through DNS validation requires ACM validation CNAME records to persist in customer DNS zones indefinitely. This creates ongoing DNS-based domain control confirmation within AWS's certificate validation infrastructure.

Under GDPR Article 28, AWS DPA terms cover ACM as a data processor. However, under the Schrems II analysis, organizations must assess whether Standard Contractual Clauses are effective given US surveillance law. For ACM specifically, the CLOUD Act's potential reach to private key material — the most security-sensitive artifact in TLS — makes this a qualitatively significant exposure point compared to most AWS service data categories.

sota.io provides EU-native application hosting on Hetzner and Scaleway infrastructure, with TLS certificate management handled entirely within EU-jurisdiction systems. Start your free trial or read more EU compliance guides.