mTLS 与双向认证

mTLS 在 TLS 连接中认证双方。常见证书模式下，客户端验证服务端，服务端也请求并验证客户端证书及私钥持有证明。它把连接关联到经过核验的主体，但不自动决定主体能读取哪个租户、调用哪个 API。

假设订单服务调用支付服务：mTLS 可以确认调用方是受信任的订单工作负载；是否允许它执行扣款、退款，仍由支付服务的授权策略决定。来自同一 CA 的测试服务，也不应因此获得生产支付权限。

握手：证书、签名与密钥确认相互补充

在 TLS 1.3 的证书认证完整握手中，服务端发送 CertificateRequest，客户端有合适证书时发送 Certificate、CertificateVerify、Finished。证书表达签发者认可的身份，CertificateVerify 将私钥持有证明绑定本次握手，Finished 确认握手密钥与历史。

客户端找不到合适证书时，返回空 certificate_list，不发送 CertificateVerify；服务端可以依策略继续匿名，或以 certificate_required 中止。要求 mTLS 的入口必须确保匿名路径被拒绝，不能只看有没有发 CertificateRequest。

certificate_authorities 是证书选择提示，省略它不意味着信任任意 CA。TLS 1.3 该扩展出现时列表本身有非空长度要求；扩展缺席与编码一个空列表不是一回事。signature_algorithms、oid_filters 等也各有定义，并不存在通用的“certificate_extensions 中填写 SPIFFE OID”流程。RFC 9846：客户端认证

TLS 1.3 另有协商支持后的 post-handshake authentication；其实现和上层协议支持需要确认，不能假设访问某个 HTTP 路径时都能临时补一次认证。实践中应先明确入口是否整条连接要求客户端身份，再设计路由和授权。

验证通过后，怎样得到可授权的身份

链验证负责确认签发关系、时间和用途等条件；身份映射负责按约定字段得到 principal。服务器身份常用 DNS SAN，客户端可能采用 URI SAN、专门注册的证书映射或其他应用约定。不要随意取第一个 CN 字符串当全系统唯一身份。

以 spiffe://prod.example/ns/orders/sa/api 为例，可以将其作为明确允许的主体，再决定它能否执行 charge。同样的路径出现在 spiffe://staging.example/... 下是不同身份；字符串里含 orders 或以 prod.example 为前缀都不够。

认证和授权的失败应分别记录：未知签发者、证书用途不合适、身份无法映射属于不同问题；已认证主体没有退款权限则是授权拒绝。这样才能解释“TLS 成功但 HTTP 403”，而不是一律重新签证书。

教学策略：默认拒绝，逐个动作授权

以下函数的输入必须由真实验证层产生；它不读取客户端自报的 HTTP 头，也不实现 X.509 或完整 SPIFFE 解析。它只展示认证结果如何参与后续策略。

from dataclasses import dataclass

@dataclass(frozen=True)
class Peer:
    authenticated: bool
    identity: str | None

RULES = {
    'spiffe://prod.example/ns/orders/sa/api': {'charge'},
    'spiffe://prod.example/ns/finance/sa/worker': {'refund'},
}

def allow(peer, action, tenant, permitted_tenants):
    return (peer.authenticated
            and peer.identity in RULES
            and action in RULES[peer.identity]
            and tenant in permitted_tenants.get(peer.identity, set()))

orders = 'spiffe://prod.example/ns/orders/sa/api'
tenants = {orders: {'tenant-a'}}
assert allow(Peer(True, orders), 'charge', 'tenant-a', tenants)
assert not allow(Peer(True, orders), 'refund', 'tenant-a', tenants)
assert not allow(Peer(True, orders), 'charge', 'tenant-b', tenants)
assert not allow(Peer(False, orders), 'charge', 'tenant-a', tenants)
assert not allow(Peer(True, orders.replace('prod.', 'staging.')), 'charge', 'tenant-a', tenants)
assert not allow(Peer(True, orders + '/extra'), 'charge', 'tenant-a', tenants)
assert not allow(Peer(True, None), 'charge', 'tenant-a', tenants)
print('主体、动作、租户与未认证拒绝分支通过')

工作负载身份与用户身份也应分开。订单服务替用户发起操作时，mTLS 证明的是订单服务；用户、租户和委托范围需要可靠的请求上下文或令牌，并检查服务是否有权代表该用户执行该动作。

信任从哪里来：私有 CA 常见，但并非唯一方式

自建或托管私有 CA 便于控制服务身份命名、签发条件和信任范围。客户端认证信任库应限定用途，不能为图方便直接接受整个公共浏览器根库下的任意合格客户端证书。

mTLS 并不要求组织亲自运维离线根 CA。比如 OAuth 的 mTLS 客户端认证既定义 PKI 方法，也定义基于注册材料的 self_signed_tls_client_auth。后者信任预先绑定的客户端公钥材料，不是“看到任何自签证书都接受”。RFC 8705：客户端认证

签发系统同样需要初始身份依据。新实例不能仅提交“我是 payments”就获得支付身份；它需要由平台证据、工作负载登记及策略建立授权关系。证书签发自动化解决凭据交付，不会凭空解决初始可信身份问题。

SPIFFE：身份规范、凭据与交付接口

X.509-SVID 必须恰好有一个 URI SAN 来承载 SPIFFE ID；它可以有其他类型 SAN，但不能用 CN 回退，也不能在多个 URI 中任选一个。叶证书还受 CA 标志、KU 和身份路径等约束；验证 SPIFFE 身份需使用对应 trust domain 的可信材料。X.509-SVID 规范

SVID 不是“证书内容里装着私钥”：证书是公开对象，Workload API 可以把相应私钥作为另一个材料交付。短期轮换是整体设计的一部分，但不能把“默认一小时”写成 SPIFFE 永久统一规定。多个实例也可以共享服务级身份，这并不要求它们共享同一私钥。SPIFFE Concepts

代理边界：证书身份不会自动穿过 TLS 终止

若网关终止 A 的 mTLS，再向 B 建立第二条 mTLS，B 直接认证到的 TLS 对端是网关 G。若 B 需要原调用方 A 的身份，应定义网关到后端的可信传递约定，并限制后端只能从合格入口接受该约定。

以 X-Forwarded-Client-Cert 为例，它是可配置的代理头：入口要清理或覆盖外部伪造值，再根据已验证连接生成内容；后端需验证来源、传递规则和所需字段。把一段 PEM 或 Subject 文本放进头里，不会让 A 参与第二段 TLS 的 CertificateVerify。Envoy：XFCC

如果使用 TLS passthrough，后端直接完成原始握手，但网关通常不能同时读取加密后的 HTTP 路径做常规七层路由。选择终止还是透传，取决于哪一层需要看见身份与业务信息。

后端认证到的是原调用方，还是网关？

在终止模式中，即使原主体可采信，B的直接TLS对端仍是gateway。破坏任一传递条件，就不能继续把orders当作可信原主体。透传模式则由A与B直接握手；改变动作到refund仍会授权拒绝。

Service Mesh：加密覆盖范围与权限策略分开看

Mesh 可以由代理承担证书交付和互相认证，但实际覆盖范围取决于流量是否进入数据平面、工作负载是否纳管及端口策略。Sidecar 只是部署方式之一，不能把所有 mesh 都画成每个 Pod 必有 sidecar。

例如 Istio 中 PeerAuthentication 控制接收侧 mTLS 要求，AuthorizationPolicy 控制访问授权。PERMISSIVE 可以兼容明文与 mTLS，不能用“开启自动 mTLS”推断所有入口已拒绝明文；ambient 等模式还有自己的能力约束。Istio 安全概念、PeerAuthentication

代理间有加密，也不等于应用到本地代理之间必然使用 TLS。评估时应画出真实终止点、进程隔离和可绕过入口，而不是仅凭控制台显示绿色锁判断端到端身份边界。

轮换：旧证书、旧连接和恢复票据是三种状态

假设教学部署的叶证书有效两小时，每小时轮换。10:00 签发的新证书在 11:00 被替换，不意味着 10:30 建立的长连接立刻重新认证。证书到期通常也不会自行在每次应用写入时触发链验证；是否限连接寿命、主动断连或重新授权，需要明确策略。

根或中间 CA 轮换可采用重叠信任：先分发包含新旧锚点的 bundle，确认接收方已加载，再切换新签发链，最后在旧凭据退出且其他相关状态处理完成后移除旧信任。只先切换签发者，会让尚未更新的客户端立即失去互通。

会话恢复可能继承前次认证上下文而不重新发送证书。禁用某个身份时，除了新握手验证，还要考虑现有连接、恢复票据和授权缓存；短有效期只缩短部分暴露窗口。不能因系统使用 mTLS，就把 0-RTT 当作已经完成本次客户端证书认证的普通请求。

与 API Key、访问令牌如何协作

OAuth 证书绑定令牌将证书摘要关联到令牌，资源服务器检查当前 mTLS 证书与绑定是否一致，降低令牌单独泄露后的可用性。它是传输身份与请求授权协作的例子，不能以“用了 JWT 就不需要看 mTLS”替代验证。RFC 8705：绑定访问令牌

不存在脱离连接复用、签名算法、令牌验证缓存和请求规模的固定开销排名。也不能把 API Key 标为天然不兼容零信任：关键是明确身份、最小权限和持续执行策略。

继续查阅

• 证书与 PKI：名称、信任路径、签发及吊销。
• TLS 1.3 握手：认证消息、恢复与 early data。
• 反向代理与负载均衡：终止点与代理转发。