Listen to this Post
Introduction:
Mutual TLS (mTLS) has become a non-negotiable standard for securing high-value APIs and services, ensuring both client and server are rigorously authenticated. With AWS’s recent announcement of CloudFront support for mTLS, many organizations faced a daunting $800 monthly fee for the mandatory pair of AWS Private CAs. This article deconstructs an innovative, open-source approach to implementing production-grade mTLS on CloudFront using a serverless, custom Certificate Authority, slashing costs to near zero while maintaining robust security.
Learning Objectives:
- Understand the architecture and security benefits of mutual TLS (mTLS) for CloudFront distributions.
- Learn how to set up a secure, open-source, serverless Certificate Authority using AWS Lambda and AWS Secrets Manager.
- Implement a complete workflow to issue client certificates, configure CloudFront for mTLS, and validate the end-to-end setup.
You Should Know:
1. The mTLS Prerequisites and Architecture Blueprint
Before diving into commands, you must understand the components. mTLS requires a trusted CA certificate to be associated with your CloudFront distribution. CloudFront will use this CA to validate any client certificate presented during the TLS handshake. Our architecture replaces AWS Private CA with:
A Lambda function acting as the CA server (using a tool like `smallstep` or a custom Python/OpenSSL implementation).
AWS Secrets Manager to securely store the private CA key and root certificate.
An API Gateway endpoint fronting the Lambda for certificate signing requests (CSRs).
CloudFront behaviors configured to require mTLS.
Step-by-step guide:
First, generate your own Root CA keypair on a secure, offline machine if possible.
Linux/macOS (OpenSSL Commands) Generate a private key for your Root CA openssl genrsa -aes256 -out rootCA.key 4096 Create and self-sign the Root CA certificate openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem -subj "/C=US/ST=State/L=City/O=Organization/CN=MyRootCA"
This `rootCA.pem` is the certificate you will later upload to CloudFront. The `rootCA.key` must be stored with extreme security—in our case, it will be encrypted in AWS Secrets Manager.
2. Deploying the Serverless Certificate Authority
The core is a Lambda function that can issue client certificates. We’ll use a Python Lambda with the `cryptography` library.
Step-by-step guide:
Create a Lambda function with the following Python snippet to sign CSRs:
import json
import boto3
from cryptography import x509
from cryptography.x509.oid import NameOID
from cryptography.hazmat.primitives import serialization, hashes
from cryptography.hazmat.primitives.asymmetric import padding
from botocore.exceptions import ClientError
import os
secrets_client = boto3.client('secretsmanager')
def lambda_handler(event, context):
1. Fetch CA private key and cert from Secrets Manager
try:
ca_key_secret = secrets_client.get_secret_value(SecretId='mtls-ca-private-key')
ca_cert_secret = secrets_client.get_secret_value(SecretId='mtls-ca-certificate')
except ClientError as e:
raise e
<ol>
<li>Load the CA private key and cert
ca_key = serialization.load_pem_private_key(ca_key_secret['SecretBinary'], password=None)
ca_cert = x509.load_pem_x509_certificate(ca_cert_secret['SecretBinary'])</p></li>
<li><p>Parse the CSR from the HTTP POST body
csr_pem = event['body']
csr = x509.load_pem_x509_csr(csr_pem.encode())</p></li>
<li><p>Create and sign the client certificate
from datetime import datetime, timedelta
client_cert = x509.CertificateBuilder().subject_name(
csr.subject
).issuer_name(
ca_cert.subject
).public_key(
csr.public_key()
).serial_number(
x509.random_serial_number()
).not_valid_before(
datetime.utcnow()
).not_valid_after(
datetime.utcnow() + timedelta(days=365)
).add_extension(
x509.BasicConstraints(ca=False, path_length=None), critical=True,
).sign(ca_key, hashes.SHA256())</p></li>
<li><p>Return the signed client certificate
return {
'statusCode': 200,
'body': client_cert.public_bytes(serialization.Encoding.PEM).decode()
}
Deploy this Lambda behind an API Gateway HTTP API, securing the endpoint with IAM authentication or a custom authorizer.
3. Configuring CloudFront to Demand mTLS
With your Root CA ready, you now bind it to CloudFront.
Step-by-step guide:
- Upload your `rootCA.pem` to AWS Certificate Manager (ACM) in the us-east-1 region (CloudFront requirement).
Using AWS CLI aws acm import-certificate --certificate fileb://rootCA.pem --region us-east-1
2. Note the returned ACM certificate ARN.
- Create a new CloudFront distribution or update an existing one. In the Origin settings, for the origin you want to protect, set “Viewer protocol policy” to “HTTPS only”.
- In the Distribution settings, find the “Mutual TLS authentication” section. Enable it and select the imported Root CA certificate from ACM.
- Update the “Trusted client certificates” setting to require clients to present a certificate signed by your CA.
4. Generating and Enrolling Client Certificates
Your clients now need certificates. This process involves generating a client key, a CSR, and calling your CA Lambda.
Step-by-step guide:
On the client system 1. Generate a client private key openssl genrsa -out client.key 2048 2. Create a Certificate Signing Request (CSR) openssl req -new -key client.key -out client.csr -subj "/C=US/ST=State/L=City/O=ClientOrg/CN=unique-client-id" 3. Send the CSR to your CA Lambda endpoint (using curl and IAM auth) Assuming your API Gateway URL is https://api-id.execute-api.region.amazonaws.com/sign aws sigv4-sign --region us-east-1 --service execute-api --method POST --body file://client.csr --uri https://api-id.execute-api.region.amazonaws.com/sign > signed_request.txt 4. Extract the signed certificate from the response and save as client.crt
The client now has `client.key` and `client.crt` to use for authenticated requests.
5. Making Authenticated Calls to Your CloudFront Distribution
Test the entire flow by using `curl` to make an mTLS request.
Step-by-step guide:
Linux/macOS curl command curl -v https://yourcloudfrontdomain.net/protected-path \ --key client.key \ --cert client.crt \ --cacert rootCA.pem
A successful `200 OK` response confirms your mTLS setup is working. Without the correct client certificate, CloudFront will reject the request with a `403 Forbidden` error.
6. Automating Rotation and Revocation
A robust PKI requires lifecycle management. Implement automated rotation for your client certificates.
Step-by-step guide:
- Rotation: Modify your CA Lambda to accept a renewal parameter. Clients can call this endpoint before certificate expiry with their existing valid certificate for authentication to receive a new one.
- Revocation: Maintain a DynamoDB table of revoked certificate serial numbers. Create a second Lambda function to add serials to this table upon revocation. Configure a CloudFront Lambda@Edge (viewer request trigger) to check this table for every request. If the presented certificate’s serial is revoked, deny the request.
Simplified Lambda@Edge revocation check snippet import json import boto3 from cryptography import x509 dynamodb = boto3.resource('dynamodb') revoked_table = dynamodb.Table('RevokedCerts') def lambda_handler(event, context): client_cert_pem = event['Records'][bash]['cf']['request']['clientCert']['clientCertPem'] cert = x509.load_pem_x509_certificate(client_cert_pem.encode()) serial = str(cert.serial_number) response = revoked_table.get_item(Key={'SerialNumber': serial}) if 'Item' in response: return {'status': '403', 'body': 'Certificate Revoked'} ... pass request to origin
7. Hardening and Security Best Practices
Deploying your own CA carries operational responsibility.
Step-by-step guide:
- Secret Storage: Ensure your Secrets Manager secret for the CA key has a tight KMS key policy and rotation enabled for the secret itself.
- Least Privilege Lambda: The CA Lambda’s IAM role should only have `secretsmanager:GetSecretValue` for its specific secrets and minimal logging permissions.
- API Gateway Protection: Do not leave your CA endpoint publicly open. Use IAM authentication, a custom Lambda authorizer, or IP allow-listing.
- Monitoring: CloudWatch alarms on Lambda errors and API Gateway 4xx/5xx errors are essential. Log all certificate issuance events (client CN, serial, timestamp) to CloudWatch Logs for audit trails.
What Undercode Say:
- Cost-Cutting Unleashes Innovation: The primary takeaway isn’t just saving $9,600 annually; it’s that bypassing proprietary service fees often forces teams to build more adaptable, transparent, and secure systems they fully control.
- The Shared Responsibility Shift: AWS provides the mechanism (CloudFront mTLS), but you own the CA’s integrity. This moves a critical piece of the security chain—certificate issuance, revocation, and logging—into your court, requiring mature internal PKI processes.
This open-source approach demonstrates that core security primitives like mTLS are increasingly commoditizable. While AWS Private CA offers convenience and integration, its high cost creates a market gap for modular, serverless security solutions. The architectural pattern—Lambda for logic, Secrets Manager for vaulting, API Gateway for fronting—is reusable for countless other custom security controls, from API key management to secure credential brokering.
Prediction:
The validation of this model will accelerate the “unbundling” of premium cloud security services. We predict a rise in open-source, cloud-agnostic projects offering enterprise-grade PKI, Secrets Management, and DDoS protection that can be deployed as serverless functions across AWS, Azure, and GCP. This will pressure hyperscalers to either significantly reduce prices for managed services or deepen integration to justify the premium, leading to a more competitive and innovative cloud security ecosystem in the next 18-24 months. The savvy security engineer’s value will shift from console configuration to architecting and securing these critical, custom control-plane applications.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Paulschwarzen Amazon – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
