Caddy mTLS 实战：条件化双向认证与客户端证书校验

Caddy mTLS 实战条件化双向认证与客户端证书校验【免费下载链接】caddyFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS项目地址: https://gitcode.com/GitHub_Trending/ca/caddy一个常见的现实诉求同一个 HTTPS 入口既服务公网也服务内网服务——只有内网来源的请求需要出示客户端证书公网保持普通访问。Caddy 的条件化 mTLS 正好覆盖这个场景通过connection_policy在 TLS 握手阶段做条件匹配对命中条件的连接启用客户端证书校验其余连接照常放行。一、为什么要按条件开双向认证mTLSMutual TLS双向 TLS即客户端和服务器互验身份客户端验证服务器的证书服务器也要验证客户端的证书——可以理解为服务端也要求客户端出示身份证。全量强制 mTLS 和条件化 mTLS 各有代价维度全量强制 mTLS条件化 mTLS适用场景内网服务网格、API 间互调同一入口混合公网访问与内部服务客户端体验所有客户端都要装证书浏览器/脚本接入成本高仅命中条件的连接需要证书安全边界一刀切简单清晰按来源收紧敏感链路强校验主要代价可用性受损排障时也要先解决证书问题匹配条件本身成为安全边界需认真设计选择性双向认证的价值在于把校验强度交给条件而不是交给全部。二、一次握手里发生了什么Caddy 在 TLS 握手阶段对每个连接按顺序评估 TLS 连接策略connection policy源码见modules/caddytls/connpolicy.go命中的第一条策略决定该连接是否要求客户端证书client_auth的mode有两个常用取值request向客户端请求证书但不强制、不校验拿不到也能连上require_and_verify必须提供有效证书且能通过校验否则握手失败提供 trust_pool 时这也是默认值。三、一份能直接用的 Caddyfile 与 connection_policy 条件匹配写法先把 CA 根证书放到 Caddy 配置目录如/etc/caddy/caddy.ca.cer再使用下面这份完整配置{ # 全局可选日志等 } https://api.example.com { tls { client_auth { mode request trust_pool file { pem_file /etc/caddy/caddy.ca.cer } } } connection_policy { match { remote_ip 192.168.1.0/24 } client_auth { mode require_and_verify trust_pool file { pem_file /etc/caddy/caddy.ca.cer } } } respond ok }语义是全站默认request不挡任何人来源落在192.168.1.0/24的连接命中connection_policy升级为require_and_verify。匹配维度速查匹配器定义见modules/caddytls/matchers.go匹配项匹配对象典型用途sni域名支持左标签通配符仅对某个域名启用 mTLSsni_regexp域名的正则表达式一批子域统一命中remote_ip客户端 IP / CIDR!前缀表示排除mTLS 按 IP 认证如仅内网段强制local_ip服务器本地接口 IP区分多网卡、多监听端点注意连接策略按定义顺序匹配靠前者优先。四、验证矩阵curl 按证书 × 来源四象限验证场景来源是否带客户端证书预期1内网条件内不带握手失败要求证书而未提供2内网条件内带有效证书成功返回 ok3外部条件外不带成功仅 request 模式4外部条件外带成功证书收到但不强制场景 1、2 在内网机器上执行服务器证书若也是自签 CA 签发--cacert需同时能验证服务器证书# 场景1不带证书应失败 curl -v https://api.example.com # 场景2带客户端证书应成功 curl --cert /etc/caddy/client.crt --key /etc/caddy/client.key \ --cacert /etc/caddy/caddy.ca.cer https://api.example.com # 场景3从外部主机执行不带证书应成功 curl --cacert /etc/caddy/caddy.ca.cer https://api.example.com改动配置后先用 adapt 校验语法再生效caddy adapt --config /etc/caddy/Caddyfile --pretty输出 JSON 中的tls_connection_policies顺序应与 Caddyfile 中connection_policy的书写顺序一致可借此核对谁先匹配。五、踩坑清单CA 路径写错pem_file相对路径是相对 Caddyfile 所在目录解析的不确定就用绝对路径/etc/caddy/...。证书时效与系统时间客户端证书过期、未生效或服务器时钟偏移都会导致require_and_verify失败先核对时间。策略顺序多条connection_policy按定义顺序匹配先写的具体条件会被后写的宽泛条件吃掉时调整顺序。先 adapt 后 reloadcaddy adapt能提前暴露拼写与结构错误比 reload 后看日志更快。IP 可伪造remote_ip匹配的是 TCP 层来源 IP经过代理/隧道时可被伪装不要把它当作唯一鉴权手段mTLS 按 IP 认证只应作为纵深防御的一环。六、进阶方向PKI 自动管理证书用 Caddy 内置 PKI 模块签发并管理客户端证书与内部 CA省去手工换证让证书生命周期随配置走。握手日志与失败率监控开启 TLS 握手日志结合访问日志统计认证失败率异常飙升往往意味着证书过期或有人试探。性能与会话复用内部高频互调的服务启用会话复用减少重复握手与证书校验的开销。条件化 mTLS 把是否出示身份证的决定权交给了匹配条件接下来更值得琢磨的是你打算用哪几个维度组合这个条件——sni_regexp加remote_ip的组合能覆盖哪些单维度覆盖不了的场景【免费下载链接】caddyFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS项目地址: https://gitcode.com/GitHub_Trending/ca/caddy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考