<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>MTLS on siteTitle</title><link>https://blog.yuime.moe/tags/mtls/</link><description>Recent content in MTLS on siteTitle</description><generator>Hugo</generator><language>zh-cn</language><lastBuildDate>Mon, 01 Jun 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://blog.yuime.moe/tags/mtls/index.xml" rel="self" type="application/rss+xml"/><item><title>基于私有证书链和 mTLS 的私人信任体系</title><link>https://blog.yuime.moe/posts/private-ca-mtls/</link><pubDate>Mon, 01 Jun 2026 00:00:00 +0800</pubDate><guid>https://blog.yuime.moe/posts/private-ca-mtls/</guid><description>&lt;p&gt;传输层安全（Transport Layer Security, TLS）基本是现代互联网的基石了，像 HTTPS 的全称就是 HTTP over TLS。TLS 中的信任体系基于 x509 证书链，通常情况下，仅服务端发送证书，并由客户端进行验证。而 mTLS (Mutual TLS) 则是客户端和服务器端都发送证书，并进行双向验证，基于 mTLS 可以实现对客户端的身份认证，并实现现代密码学级的安全性。&lt;/p&gt;
&lt;p&gt;然而大部分公开服务都没有使用 mTLS，而是使用传统的用户名 + MFA，在这一模型中，用户名用于身份识别，而 MFA 用于验证用户的身份。mTLS 本身也可以作为 MFA 的认证手段之一，但由于其配置复杂极少用于公开服务中，同时由于应用场景少未受到广泛支持。&lt;/p&gt;
&lt;p&gt;私有服务的安全模型相对于公开服务的一大优势就是允许系统的隔离性，邮箱、短信验证码等依赖于外部服务，这会破坏系统的私有性，而 TOTP 虽然可以做到隔离，但实际应用中通常基于第三方 APP。对于私有服务乃至个人服务，我自身作为唯一用户，完全无需考虑用户的认知负担，mTLS 反而成为最合适的认证方式之一。基于私有 CA 建立的客户端证书链则是严格限制了系统的边界，更高的私有性本身也就意味着更高的安全性。&lt;/p&gt;
&lt;h2 id="证书链构建"&gt;证书链构建&lt;/h2&gt;
&lt;p&gt;&lt;em&gt;想法是好的，但到工程落地还是有一定的距离，在这套系统设计的过程中也包括了很多试错，因此大部分流程直接基于 openssl cli。&lt;/em&gt;&lt;/p&gt;




&lt;style&gt;
 :root {
 --warning-color: #de3636;
 }

 .notice {
 margin-block: 1em 1em;
 border-left-width: 0.4rem;
 border-left-style: solid;
 }

 .notice-title {
 font-weight: 700;
 margin-bottom: 0.5em;
 }

 .notice {
 padding: 1em 1.5em;
 }

 .notice-body p:first-child {
 margin-block-start: 0;
 }

 .notice-body p:last-child {
 margin-block-end: 0;
 }

 .notice-body code {
 color: var(--text-color)
 }

 .notice-icon {
 width: 1em;
 height: 1em;
 margin-right: 0.4em;
 }

 
 .notice.tip {
 border-left-color: #79cf79;
 background-color: #79cf791f;
 }

 .notice-title.tip {
 color: #79cf79;
 }

 
 .notice.note {
 border-left-color: #58acf0;
 background-color: #58acf01f;
 }

 .notice-title.note {
 color: #58acf0;
 }

 
 .notice.warning {
 border-left-color: #de3636;
 background-color: #de36361f;
 }
 
 .notice-title.warning {
 color: #de3636;
 }

 
&lt;/style&gt;

&lt;div class="notice tip"&gt;
 &lt;div class="notice-title tip"&gt;
 提示
 &lt;/div&gt;
 &lt;div class="notice-body tip"&gt;
 虽然在一些内网服务等无公共域名的场景中也需要服务端证书的构建，但本文主要讨论客户端证书的问题。
 &lt;/div&gt;
&lt;/div&gt;






&lt;div class="notice tip"&gt;
 &lt;div class="notice-title tip"&gt;
 提示
 &lt;/div&gt;
 &lt;div class="notice-body tip"&gt;
 对于一部分常用算法，openssl 给出了别名，但本文会尽量避免使用以提高通用性，有需要建议以帮助信息和文档为准。
 &lt;/div&gt;
&lt;/div&gt;


&lt;h3 id="确定签名算法"&gt;确定签名算法&lt;/h3&gt;
&lt;p&gt;这一步本身还是很重要的，但通常会被忽略，在网上找到的大部分教程也是基于 RSA 算法。不得不说 RSA 算法确实经典，但其性能和安全性已经落后了，基本上直接 pass。比较主流的方案是基于椭圆曲线算法，如 ECDSA 和 Ed25519，或是拥抱未来使用更先进的 SLH-DSA 和 MLDSA 等 PQC 算法（已受 openssl 支持）。&lt;/p&gt;</description></item></channel></rss>