Amazon CloudFront now supports mTLS authentication to origins

Starting today, Amazon CloudFront extends its mutual TLS (mTLS) capabilities to customer origins, which enables true end-to-end authentication throughout the entire connection path—from the viewers to the customer origins. CloudFront has supported viewer mTLS between viewers and CloudFront, so that customers can strongly authenticate clients before traffic ever enters their perimeter. With this launch, that same traffic can now continue over mTLS from CloudFront to the origin, preserving cryptographic identity and trust across every hop. The result is a fully authenticated request path that removes implicit trust, enables a zero-trust, defense-in-depth architecture without sacrificing performance at the edge.

Why mTLS between CloudFront and origin is important

Extending mTLS from the edge to the origin shifts trust from being perimeter-based to identity-based across the entire request lifecycle. Customers can enable viewer mTLS and origin mTLS on CloudFront to remove implicit trust between tiers and enforce least-privilege access at the origin. This is important for regulated and high-risk workloads, where origin access must be explicitly authenticated and auditable rather than assumed. Many industry-specific benefits introduced with viewer mTLS now apply end to end. These include strong client identity for APIs, device authentication, and regulatory compliance, enabled by mutual authentication from the end user through CloudFront to the origin. For a deeper exploration of those use cases by industry, refer to our previous post on viewer mTLS, which remains foundational to understanding how end-to-end mTLS extends zero-trust principles beyond the edge.

How mTLS works

In standard TLS, certificate management is largely unidirectional. The server presents a certificate that is validated by the client against a trusted Certificate Authority (CA), while the client remains unauthenticated at the transport layer. Operationally, this keeps certificate management direct: teams provision, rotate, and monitor certificates only for servers, often using automated tooling and publicly trusted CAs. Client identity, if needed, is pushed up the stack into application-layer mechanisms, such as API keys, OAuth tokens, or headers.

mTLS fundamentally changes this model by introducing bidirectional authentication. Both the client and the server must present valid certificates and verify them against trusted CAs. Therefore, certificate management expands from managing a small, well-defined set of server certificates to managing potentially large fleets of client certificates. This introduces new operational considerations: certificate issuance and revocation, lifecycle automation, CA trust distribution, and blast-radius control when certificates are compromised or need rotation.

When mTLS is terminated at the CloudFront edge, it absorbs much of this operational complexity by acting as the certificate enforcement point for client authentication. Customers manage trust anchors and client policies, while CloudFront handles validation at scale. With mTLS extended to the origin, certificate management remains aligned with this model: CloudFront presents its own client certificate to the origin and validates the origin’s certificate in return. This preserves mutual authentication without requiring origins to manage or trust certificates for every end user directly.

Prerequisites

The following prerequisites are necessary to enable this feature:

• Prepare an X.509v3 client certificate (PEM format), which has an extended key usage (clientAuth)
• Origin servers configured to require mTLS authentication and validate client certificates
• Choose the US East (us-east-1) AWS Region on AWS Certificate Manager (ACM).

Walkthrough

Implementing mTLS authentication between CloudFront and your origins involves three key steps: obtaining a client certificate through ACM, configuring your origin servers, and enabling mTLS on your CloudFront distribution.

Step 1: Client certificate configuration
CloudFront supports client certificates from two sources, each suited for different operational needs: AWS Private Certificate Authority and third-party CAs.

AWS Private Certificate Authority (recommended)

AWS Private Certificate Authority provides fully managed certificate lifecycle with automatic renewals and seamless ACM integration. This approach eliminates manual certificate management overhead.

To request a certificate:

1. Open the ACM console so that you’re in the US East (N. Virginia) Region.
2. Choose Request a certificate > Request a private certificate.
3. Select your CA and enter your domain name.
4. Choose your preferred key algorithm and acknowledge renewal permissions.
5. Choose Request.

Figure 1: Initiating a new SSL/TLS certificate request in AWS Certificate Manager to securely enable HTTPS for application endpoints.

Import existing certificates from your private CA infrastructure to maintain current certificate management processes while gaining CloudFront mTLS capabilities, as shown in Figure 2 (below).

To import a certificate:

1. In the ACM console, choose Import a certificate.
2. Provide the certificate body, private key, and certificate chain (all in PEM format).
3. Choose Import certificate.

Client certificates must include extended key usage (clientAuth) for mTLS authentication.

Figure 2: Upload an existing client certificate and private key into AWS Certificate Manager to securely manage certificates used for mTLS authentication with AWS.

Step 2: Enable mTLS on origins
Configure mTLS authentication for each origin that requires certificate-based validation, as shown in Figure 3 (below):

1. In the CloudFront console, navigate to your distribution’s Origins tab.
2. Select the origin you want to configure and choose Edit.
3. In the origin settings, toggle mTLS to On.
4. Select your client certificate from the dropdown menu.
5. Save your changes.

Figure 3: CloudFront settings that enable mTLS authentication for origin requests, allowing CloudFront to enforce certificate-based authentication on the origin.

Per-origin flexibility

mTLS is configured at the origin level, thus you can assign different certificates to different origins within the same distribution. This enables tailored security policies. For example, use high-security certificates for API endpoints while applying standard authentication for static content delivery origins, as shown in Figure 4 (below).

Figure 4: CloudFront establishes mutual TLS with the origin, ensuring requests are authenticated and encrypted from the edge to backend services.

Balancing security and performance with end-to-end mTLS on CloudFront

Enabling end-to-end mTLS—from the end user to CloudFront, and from CloudFront to the origin—introduces some overhead during connection establishment. This is because each segment requires certificate validation and cryptographic operations to authenticate both parties. However, this overhead is largely limited to the handshake phase and doesn’t affect the steady-state transfer of application data. Connection reuse mechanisms—such as connection pooling and using long-lived keep-alive connections on CloudFront—reduce this cost across many end-user requests. This minimizes the impact on both latency and throughput for most workloads. CloudFront caches a significant portion of traffic at the edge, thus the majority of requests never reach the origin, which further reduces the relative performance impact. With TLS 1.3 and proper certificate management, the trade-off between slightly higher connection setup cost and strong end-to-end authentication is favorable. We recommend implementing mTLS as a best-practice control to secure application traffic delivered through CloudFront.

For certificate management, AWS Private CA streamlines the process with fully automated lifecycle handling and renewal notifications at 45, 30, 15, 7, and 1-day intervals. If you’re using third-party certificates, then put a process in place for timely manual renewals to avoid any disruptions in mTLS connectivity.

Conclusion

mTLS between Amazon CloudFront and the origin closes one of the most commonly overlooked trust gaps in modern edge architectures. Although Part 1 established strong identity and authentication between the end user and CloudFront, extending mTLS to the origin ensures that every hop in the request path is authenticated, encrypted, and authorized. This shifts security from an IP- and network-based model to a cryptographic trust model, where the origin only serves traffic that can prove it came from CloudFront. As applications increasingly rely on distributed edges, private APIs, and zero-trust principles, CloudFront-to-origin mTLS becomes a foundational control rather than an optional hardening step. When combined, end-user mTLS and origin mTLS provide true end-to-end identity assurance reducing attack surface, streamlining compliance, and creating a resilient application perimeter.