

# Origin mutual TLS with CloudFront
<a name="origin-mtls-authentication"></a>

Mutual TLS Authentication (Mutual Transport Layer Security Authentication — mTLS) is a security protocol that extends standard TLS authentication by requiring bidirectional certificate-based authentication, where both client and server must prove their identity before establishing a secure connection.

## Viewer mTLS vs Origin mTLS
<a name="viewer-mtls-vs-origin-mtls"></a>

Mutual authentication (mTLS) can be enabled between viewers and your CloudFront distribution (viewer mTLS) and/or also between your CloudFront distribution and the origin (origin mTLS). This documentation pertains to origin mTLS configuration. For viewer mTLS configuration refer to: [Mutual TLS authentication with CloudFront (Viewer mTLS)Origin mutual TLS with CloudFront](mtls-authentication.md).

Origin mTLS enables CloudFront to authenticate itself to your origin servers using client certificates. With origin mTLS, you can ensure that only your authorized CloudFront distributions can establish connections with your application servers, helping protect against unauthorized access attempts.

**Note**  
In origin mTLS connections, CloudFront acts as the client and presents its client certificate to your origin server during the TLS handshake. CloudFront does not perform validation of the client certificate's validity or revocation status—this is the responsibility of your origin server. Your origin infrastructure must be configured to validate the client certificate against its trust store, check certificate expiration, and perform revocation checks (such as CRL or OCSP validation) according to your security requirements. CloudFront's role is limited to presenting the certificate; all certificate validation logic and security policies are enforced by your origin servers.

## How it works
<a name="how-origin-mtls-works"></a>

In a standard TLS handshake between CloudFront and an origin, only the origin server presents a certificate to prove its identity to CloudFront. With origin mTLS, the authentication process becomes bidirectional. When CloudFront attempts to connect to your origin server, CloudFront presents a client certificate during the TLS handshake. Your origin server validates this certificate against its trust store before establishing the secure connection.

## Use cases
<a name="origin-mtls-use-cases"></a>

Origin mTLS addresses several critical security scenarios where traditional authentication methods create operational overhead:
+ **Hybrid and multi-cloud security** - You can secure connections between CloudFront and origins hosted outside AWS or public origins on AWS. This eliminates the need to manage IP allowlists or custom header solutions, providing consistent certificate-based authentication across AWS, on-premises data centers, and third-party providers. Media companies, retailers, and enterprises operating distributed infrastructure benefit from standardized security controls across their entire infrastructure.
+ **B2B API and backend security** - You can protect your backend APIs and microservices from direct access attempts while maintaining CloudFront's performance benefits. SaaS platforms, payment processing systems, and enterprise applications with strict authentication requirements can verify that API requests originate only from authorized CloudFront distributions, preventing man-in-the-middle attacks and unauthorized access attempts.

## Important: Origin Server Requirements
<a name="important-origin-server-requirements"></a>

Origin mTLS requires your origin servers to be configured to support mutual TLS authentication. Your origin infrastructure must be capable of:
+ Requesting and validating client certificates during TLS handshakes
+ Maintaining a trust store with the Certificate Authority certificates that issued CloudFront's client certificates
+ Logging and monitoring mutual TLS connection events
+ Managing certificate validation policies and handling authentication failures

CloudFront handles the client-side certificate presentation, but your origin servers are responsible for validating these certificates and managing the mutual TLS connection. Ensure your origin infrastructure is properly configured before enabling origin mTLS in CloudFront.

## Getting started
<a name="how-origin-mtls-getting-started"></a>

To implement origin mTLS with CloudFront, you'll need to import the client certificate in AWS Certificate Manager, configure your origin server to require mutual TLS, and enable origin mTLS on your CloudFront distribution. The following sections provide step-by-step instructions for each configuration task.

**Topics**
+ [Viewer mTLS vs Origin mTLS](#viewer-mtls-vs-origin-mtls)
+ [How it works](#how-origin-mtls-works)
+ [Use cases](#origin-mtls-use-cases)
+ [Important: Origin Server Requirements](#important-origin-server-requirements)
+ [Getting started](#how-origin-mtls-getting-started)
+ [Certificate management with AWS Certificate Manager](origin-certificate-management-certificate-manager.md)
+ [Enable origin mutual TLS for CloudFront distributions](origin-enable-mtls-distributions.md)
+ [Using CloudFront Functions with origin mutual TLS](origin-mtls-cloudfront-functions.md)

# Certificate management with AWS Certificate Manager
<a name="origin-certificate-management-certificate-manager"></a>

[AWS Certificate Manager (ACM)](https://aws.amazon.com/certificate-manager/) stores the client certificates that CloudFront presents to your origin servers during origin mutual TLS authentication.

## Certificate Authority support
<a name="origin-ca-support"></a>

CloudFront origin mTLS requires client certificates with Extended Key Usage (EKU) for TLS Client Authentication. Due to this requirement, you must issue certificates from your Certificate Authority and import them into AWS Certificate Manager. ACM's automatic certificate provisioning and renewal features are not available for origin mTLS client certificates. CloudFront origin mTLS supports client certificates from two sources:
+ **AWS Private Certificate Authority:** You can issue certificates from AWS Private CA using certificate templates that include TLS Client Authentication in the Extended Key Usage field (such as the EndEntityClientAuthCertificate template). After issuing the certificate from AWS Private CA, you must import it into ACM in the US East (N. Virginia) Region (us-east-1). This approach provides the security benefits of AWS Private CA while giving you control over certificate lifecycle management.
+ **Third-party private Certificate Authorities:** You can also issue certificates from your existing private Certificate Authority infrastructure and import them into ACM. This allows you to maintain your current certificate management processes while leveraging CloudFront's origin mTLS capabilities. Certificates must include TLS Client Authentication in the Extended Key Usage field and must be in PEM format with the certificate, private key, and certificate chain.

**Important**  
For both AWS Private CA and third-party CAs, you are responsible for monitoring certificate expiration dates and importing renewed certificates into ACM before expiration. ACM's automatic renewal feature does not apply to imported certificates used for origin mTLS.

## Certificate requirements and specifications
<a name="origin-certificate-requirements"></a>

### Client certificate requirements
<a name="origin-ca-cert-format-requirements"></a>
+ **Format:** PEM (Privacy Enhanced Mail) format
+ **Components:** Certificate, private key, and certificate chain
+ **Maximum certificate chain depth:** 3 (leaf certificate \$1 intermediate certificate \$1 root certificate)
+ **Maximum certificate chain size:** 64 KB
+ **Certificate size:** Cannot exceed 96 KB
+ **Maximum private key size:** 5 KB (ACM restriction)
+ **Maximum unique origin mTLS certificate ARNs that can be added or modified per CloudFront distribution create or update API call:** 5
+ **Region:** Certificates must be stored in ACM in the US East (N. Virginia) Region (us-east-1)

### Supported certificate specifications
<a name="origin-supported-cert-specs"></a>
+ **Certificate type:** X.509v3
+ **Public key algorithms:**
  + RSA: 2048-bit
  + ECDSA: P-256
+ **Signature algorithms:**
  + SHA256, SHA384, SHA512 with RSA
  + SHA256, SHA384, SHA512 with ECDSA
  + SHA256, SHA384, SHA512 with RSASSA-PSS with MGF1
+ **Extended Key Usage (required):** The certificate requires the Extended Key Usage (EKU) extension set to TLS Client Authentication, ensuring it is authorized for mTLS purposes

### Server certificate requirements
<a name="origin-server-certificate-requirements"></a>

Your origin servers must present certificates from publicly trusted Certificate Authorities during the mutual TLS handshake. For complete details on origin server certificate requirements, see [Requirements for using SSL/TLS certificates with CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-custom-origin.html#using-https-cloudfront-to-origin-certificate).

### Request or import a certificate
<a name="origin-request-import-certificate"></a>

Before enabling origin mTLS, you must have a client certificate available in ACM.

#### Request and import a certificate from AWS Private CA
<a name="request-certificate-aws-private-ca"></a>

Prerequisites:
+ An AWS Private Certificate Authority configured in your account
+ Permission to issue certificates from AWS Private CA
+ Permission to import certificates into ACM
+ A [certificate template](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html) ARN with `Extended key usage:TLS web client authentication` which suits your use-case
+ Install OpenSSL, AWS CLI, and jq (for parsing JSON).

##### To request a certificate from PCA and import into ACM (AWS CLI)
<a name="request-certificate-cli"></a>

1. Set your Private CA ARN in a variable for easier reuse.

   ```
   PCA_ARN="arn:aws:acm-pca:region:account:certificate-authority/12345678..."
   ```

1. Use OpenSSL to generate an ECDSA P-256 private key (prime256v1 curve) and Certificate Signing Request (CSR), ensuring the -nodes flag is used to keep the private key unencrypted as required for ACM import.

   ```
   openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \
       -keyout private.key \
       -out request.csr \
       -subj "/CN=client.example.com"
   ```

1. Submit the CSR to your AWS Private CA to issue a certificate, which returns the ARN of the newly issued certificate.

   ```
   CERT_ARN=$(aws acm-pca issue-certificate \
       --certificate-authority-arn "$PCA_ARN" \
       --csr fileb://request.csr \
       --signing-algorithm "SHA256WITHECDSA" \
       --validity Value=365,Type="DAYS" \
       --template-arn arn:aws:acm-pca:::template/EndEntityCertificate/V1 \
       --query 'CertificateArn' --output text)
   ```

1. Retrieve the certificate bundle from AWS PCA using the get-certificate command, which returns both the leaf certificate and chain, then use jq to separate them into distinct files.

   ```
   # Retrieve the full certificate bundle in JSON format
   aws acm-pca get-certificate \
       --certificate-authority-arn "$PCA_ARN" \
       --certificate-arn "$CERT_ARN" \
       --output json > full_cert.json
   
   # Split into Leaf and Chain
   jq -r '.Certificate' full_cert.json > leaf_cert.pem
   jq -r '.CertificateChain' full_cert.json > cert_chain.pem
   ```

1. Import the unencrypted private key, leaf certificate, and certificate chain into AWS ACM, using the fileb:// protocol to correctly handle binary file data in the CLI.

   ```
   aws acm import-certificate \
       --certificate fileb://leaf_cert.pem \
       --private-key fileb://private.key \
       --certificate-chain fileb://cert_chain.pem \
       --region us-east-1 \
       --query 'CertificateArn' \
       --output text
   ```

#### Import a certificate from a third-party CA
<a name="import-certificate-third-party-ca"></a>

Prerequisites:
+ A certificate, unencrypted private key, and certificate chain from your Certificate Authority in PEM format
+ The certificate must include Extended Key Usage for TLS Client Authentication
+ Permissions to import certificates into ACM

##### To import a certificate into ACM (AWS CLI)
<a name="import-certificate-cli"></a>

```
aws acm import-certificate \
  --certificate fileb://certificate.pem \
  --private-key fileb://private-key.pem \
  --certificate-chain fileb://certificate-chain.pem \
  --region us-east-1 \
  --query 'CertificateArn' \
  --output text
```

#### Next steps
<a name="certificate-next-steps"></a>

After obtaining or importing your client certificate in ACM, you can configure your origin server to require mutual TLS authentication and enable origin mTLS on your CloudFront distribution. For instructions on enabling origin mTLS in CloudFront, see the next section "Enable origin mutual TLS for CloudFront distributions."

# Enable origin mutual TLS for CloudFront distributions
<a name="origin-enable-mtls-distributions"></a>

After obtaining a client certificate through AWS Certificate Manager and configuring your origin server to require mutual TLS, you can enable origin mTLS on your CloudFront distribution.

## Prerequisites and requirements
<a name="origin-mtls-prerequisites-requirements"></a>

Before enabling origin mTLS on a CloudFront distribution, ensure you have:
+ A client certificate stored in AWS Certificate Manager in the US East (N. Virginia) Region (us-east-1)
+ Origin servers configured to require mutual TLS authentication and validate client certificates
+ Origin servers presenting certificates from publicly trusted Certificate Authorities
+ Permissions to modify CloudFront distributions
+ Origin mTLS is only available on Business, Premium plans or Pay as you go pricing plans.

**Note**  
Origin mTLS can be configured for custom origins (including origins hosted outside AWS) and AWS origins that support mutual TLS such as Application Load Balancer and API Gateway.

**Important**  
The following CloudFront features are not supported with origin mTLS:  
**gRPC traffic:** gRPC protocol is not supported for origins with origin mTLS enabled
**WebSocket connections:** WebSocket protocol is not supported for origins with origin mTLS enabled
**VPC origins:** origin mTLS cannot be used with VPC origins
**Origin request and origin response triggers with Lambda@Edge:** Lambda@Edge functions in origin request and origin response positions are not supported with origin mTLS
**Embedded POPs:** origin mTLS is not supported for embedded POPs

## Enable origin mTLS
<a name="origin-enable-mtls-per-origin"></a>

Per-origin configuration allows you to specify different client certificates for different origins within the same distribution. This approach provides maximum flexibility when your origins have different authentication requirements.

### For new distributions (Console)
<a name="origin-enable-mtls-new-distributions"></a>

1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. Choose **Create distribution**

1. Select a pricing plan: Choose either **Business** or **Premium** or **Pay As You Go** (Origin mTLS is not available on the Free plan)

1. In the Origin settings section, choose Origin Type as Other

1. In the **Origin settings** section, choose **Customize origin settings**

1. Configure your first origin (domain name, protocol, etc.)

1. In the origin configuration, find **mTLS**

1. Toggle **mTLS** to On

1. For **Client certificate**, select your certificate from AWS Certificate Manager

1. (Optional) Add additional origins with their own origin mTLS configurations

1. Complete the remaining distribution settings and choose **Create distribution**

### For existing distributions (Console)
<a name="origin-enable-mtls-existing-distributions"></a>

1. Sign in to the AWS Management Console and open the CloudFront console at [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).

1. From the distribution list, select the distribution you want to modify. (Note: Ensure your distribution is on a **Pro or Premium or Pay As You Go** pricing plan. If not, you must upgrade your pricing plan before enabling origin mTLS)

1. Choose the **Origins** tab

1. Select the origin you want to configure and choose **Edit**

1. In the origin settings, find **mTLS**

1. Toggle **mTLS** to On

1. For **Client certificate**, select your certificate from AWS Certificate Manager. (Note: Only client certificates with the EKU (Extended Key Usage) property set to "TLS Client Authentication" will be listed)

1. Choose **Save changes**

1. Repeat for additional origins as needed

## Using AWS CLI
<a name="origin-enable-mtls-cli"></a>

For per-origin configuration, specify the origin mTLS settings within each origin's configuration:

```
{
  "Origins": {
    "Quantity": 2,
    "Items": [
      {
        "Id": "origin-1",
        "DomainName": "api.example.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginMtlsConfig": {
          "ClientCertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/cert-1"
        }
      },
      {
        "Id": "origin-2",
        "DomainName": "backend.example.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginMtlsConfig": {
          "CertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/cert-2"
        }
      }
    ]
  }
}
```

**Note**  
CloudFront will not provide the client certificate if the server does not request it, allowing the connection to proceed normally.

## Next steps
<a name="origin-enable-mtls-next-steps"></a>

After enabling origin mTLS on your CloudFront distribution, you can monitor authentication events using CloudFront access logs.

# Using CloudFront Functions with origin mutual TLS
<a name="origin-mtls-cloudfront-functions"></a>

CloudFront Functions provides lightweight, serverless compute at the edge to customize content delivery. When using origin mutual TLS with CloudFront Functions, there are specific behaviors and limitations to be aware of regarding origin selection and manipulation.

## Supported CloudFront Functions operations
<a name="supported-cloudfront-functions-operations"></a>

CloudFront Functions can interact with mTLS-enabled origins in the following ways:

### updateRequestOrigin()
<a name="update-request-origin-function"></a>

The updateRequestOrigin() function supports limited modifications when working with mTLS-enabled origins:
+ **Switching between origin mTLS origins:** You can update the request to route to a different origin that uses origin mTLS, provided both origins use the **same client certificate**. This allows you to implement custom routing logic while maintaining mutual TLS authentication.
+ **Disabling origin mTLS:** You can switch from a mTLS-enabled origin to a non-mTLS origin by setting `mTLSConfig: 'off'` in the function. This provides flexibility to conditionally disable mutual TLS authentication based on request characteristics.

#### Example: Switching between origin mTLS origins with the same certificate
<a name="example-switching-mtls-origins"></a>

```
function handler(event) {
    var request = event.request;

    // Route to different origin based on request path
    if (request.uri.startsWith('/api/v2')) {
        request.origin = {
            domainName: 'api-v2.example.com',
            customHeaders: {},
            // Both origins must use the same certificate
        };
    }

    return request;
}
```

#### Example: Conditionally disabling origin mTLS
<a name="example-disabling-mtls"></a>

```
function handler(event) {
    var request = event.request;

    // Disable mTLS for specific paths
    if (request.uri.startsWith('/public')) {
        request.origin = {
            domainName: 'public-origin.example.com',
            customHeaders: {},
            mTLSConfig: 'off'
        };
    }

    return request;
}
```

## Unsupported CloudFront Functions operations
<a name="unsupported-cloudfront-functions-operations"></a>

The following CloudFront Functions operations do not support mTLS-enabled origins at general availability:

### selectRequestOriginById()
<a name="select-request-origin-by-id-function"></a>

The `selectRequestOriginById()` function cannot select an origin that has origin mTLS enabled. Attempting to select a mTLS-enabled origin using this function will result in a validation error.

If your use case requires dynamic origin selection with origin mTLS, use `updateRequestOrigin()` instead, ensuring all target origins use the same client certificate.

### createRequestOriginGroup()
<a name="create-request-origin-group-function"></a>

The `createRequestOriginGroup()` function does not support creating origin groups that include mTLS-enabled origins. Origin groups with origin mTLS origins cannot be created dynamically through CloudFront Functions.

If you need origin failover capabilities with origin mTLS, configure origin groups directly in your CloudFront distribution settings rather than creating them dynamically in functions.