惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

有赞技术团队
有赞技术团队
B
Blog
IT之家
IT之家
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Last Week in AI
Last Week in AI
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
人人都是产品经理
人人都是产品经理
博客园 - 聂微东
量子位
博客园 - 叶小钗
T
Tailwind CSS Blog
小众软件
小众软件
WordPress大学
WordPress大学
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - Franky
雷峰网
雷峰网
博客园 - 三生石上(FineUI控件)
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Blog — PlanetScale
Blog — PlanetScale
V
V2EX
博客园_首页
I
InfoQ
B
Blog RSS Feed
Microsoft Azure Blog
Microsoft Azure Blog

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Hands-On with the New Amazon CloudFront Viewer mTLS Passt...
Irfan Satrio · 2026-05-15 · via DEV Community

On May 14, 2026, Amazon Web Services introduced passthrough mode for Amazon CloudFront Viewer Mutual TLS (mTLS). The new capability allows CloudFront to forward client certificates directly to origins for validation without requiring certificate verification at CloudFront edge locations.

Previously, CloudFront Viewer mTLS supported required mode and optional mode, where certificate authentication is handled by CloudFront using trust stores. Passthrough mode introduces a different approach by allowing existing mTLS validation systems at origins to remain unchanged while CloudFront forwards certificate information.

Mutual TLS (mTLS) extends standard TLS authentication by requiring both the client and server to present certificates before establishing a secure connection. This enables stronger identity verification compared to traditional TLS, where only the server proves its identity.

In this post, I explored the new passthrough capability by enabling Viewer mTLS on an existing CloudFront distribution in front of an EC2 instance running NGINX.

Setup

To test the new feature, I enabled Viewer Mutual TLS (mTLS) and selected Passthrough mode.

The configuration confirms that Viewer mTLS is enabled in passthrough mode.

CloudFront Viewer mTLS currently supports three modes:

  • Required mode
    CloudFront validates client certificates against a configured trust store. Requests without valid certificates are rejected.

  • Optional mode
    CloudFront validates certificates if provided but still allows requests without certificates. Certificate information can be forwarded for authorization decisions.

  • Passthrough mode
    CloudFront does not validate certificates against a trust store. Instead, CloudFront verifies that the client possesses the corresponding private key, then forwards the client certificate chain to the origin for validation.

For passthrough mode:

  • No trust store configuration is required
  • Client certificates are forwarded to origins as HTTP headers
  • Caching is automatically disabled
  • Requires an Origin Request Policy that includes Client-Cert and Client-Cert-Chain headers (e.g., AllViewer)
  • Connection Functions remain supported
  • HTTP/3 is not supported
  • Origin Shield is not supported
  • Lambda@Edge is not supported

According to AWS documentation, disabling caching ensures every request reaches the origin and undergoes end-to-end authentication.

Verification

To verify passthrough functionality, I sent requests using curl with a self-signed client certificate and private key.

curl -v --cert client.crt --key client.key https://dxxxxxxxxxxxxx.cloudfront.net

Enter fullscreen mode Exit fullscreen mode

TLS Handshake Verification

Output:

The Request CERT (13) message confirms that CloudFront requested a client certificate during the TLS handshake, indicating Viewer mTLS is active.

In passthrough mode, CloudFront requests the certificate but does not validate it against a trust store. Certificate validation remains at the origin.

HTTP Response Verification

I then verified whether requests successfully reached the origin.

Output:

The HTTP/2 200 confirms the request successfully reached the NGINX origin. The x-cache: Miss from cloudfront is expected behavior in passthrough mode because caching is disabled to ensure every request is validated directly by the origin, which aligns with AWS documentation.

Analysis

From testing, CloudFront requested client certificates during the TLS handshake, forwarded certificate information to the origin, and bypassed caching as expected in passthrough mode. This approach allows existing applications using origin-side mTLS validation to keep their current authentication workflows without configuring trust stores in CloudFront.

Passthrough mode is well-suited for for workloads such as:

  • Existing enterprise PKI environments
  • API-to-API authentication
  • Internal systems with custom certificate validation
  • Device authentication workloads already relying on origin-side mTLS

Because certificate validation occurs at the origin, every request reaches the backend directly instead of being served from cache.

Conclusion

Based on this hands-on test, Viewer mTLS passthrough mode allows CloudFront to request client certificates while leaving certificate validation entirely to the origin. The TLS handshake, successful HTTP response, and disabled caching behavior observed during testing match the expected implementation documented by AWS.

For environments already using mTLS at origins, passthrough mode provides a way to introduce CloudFront without moving certificate validation to edge locations or configuring trust stores.

CloudFront Viewer mTLS passthrough mode is available at no additional cost across AWS Regions.