EKU
下面把 EKU（Extended Key Usage）/ ClientAuth 在 Nginx 与 OpenSSL client 里的真实作用给你拆清楚，避免再混在 TLS 行为里误判。
一、EKU 是什么（本质）
EKU 是证书扩展字段，用来声明：
👉 “这个证书允许被用在哪种 TLS 角色中”
常见两类：
| EKU | 含义 |
|---|---|
| TLS Web Server Authentication | 用于服务端证书 |
| TLS Web Client Authentication | 用于客户端证书（mTLS） |
二、Nginx（服务端）里 EKU 的作用
✔ 关键结论
❗Nginx 本身不会主动检查 EKU 来决定 TLS 行为
✔ EKU 的检查是 OpenSSL 在“验证客户端证书时”做的
1. 不开启 mTLS 时（默认）
ssl_verify_client off;
行为：
-
不请求客户端证书
-
不验证客户端证书
-
❌ EKU 完全不参与
👉 结论：
EKU 对 Nginx 完全无影响
2. 开启 mTLS 时
ssl_verify_client on;
ssl_client_certificate ca.crt;
发生流程：
ClientHello
ServerHello
CertificateRequest ← Nginx触发
ClientCertificate
ClientCertificateVerify
这里 EKU 的作用：
OpenSSL 会在验证 client cert 时检查：
✔ 是否包含
TLS Web Client Authentication
否则：
handshake_failure
重点：
✔ EKU 是“证书合法性检查的一部分”
❌ 不是“是否发起 mTLS 的条件”
三、OpenSSL client（客户端）里 EKU 的作用
这里才是你这个问题的关键点。
✔ OpenSSL client 在做什么？
当你执行：
openssl s_client
或 TLS SDK 时：
它会做“证书筛选”
流程：
扫描本地证书
↓
过滤 EKU
↓
选择可用于 client auth 的证书
↓
发送 Certificate
✔ EKU 的真实影响点
1. 决定“是否可用于客户端身份认证”
必须满足：
Extended Key Usage:TLS Web Client Authentication
否则：
❌ 该证书不会被用于 mTLS
2. 决定“是否参与自动证书选择”
很多 TLS 实现（Java / Windows / OpenSSL）：
-
会自动过滤 EKU
-
不符合 ClientAuth → 直接忽略
3. 影响是否发送 Client Certificate
ClientHello
↓
是否有合适证书？├─ 有 → 发送 Certificate└─ 无 → 不发送
四、你这个问题的关键误区
你之前现象：
有 ClientAuth EKU → 正常
没有 → ClientHello 后 FIN
❗真实原因不是 Nginx，而是：
👉 OpenSSL client / TLS栈 在“证书选择阶段”丢弃了证书
五、EKU 在 TLS 中的完整链路位置
CLIENT SIDE
-------------------------------
证书库↓
EKU筛选（ClientAuth）↓
选择是否发送证书↓
ClientHello↓
-------------------------------SERVER SIDE (Nginx)↓
是否请求证书（ssl_verify_client）↓
是否验证 EKU（OpenSSL verify）
六、关键总结（最重要）
✔ Nginx 侧：
| 项目 | 是否处理 EKU |
|---|---|
| 是否决定用哪个证书 | ❌ 否 |
| 是否检查 EKU | ✔ 仅在 mTLS验证阶段 |
| 是否影响 TLS 是否建立 | ❌ 否 |
✔ OpenSSL client 侧：
| 项目 | 是否处理 EKU |
|---|---|
| 是否选证书 | ✔ 是（关键） |
| 是否发送 client cert | ✔ 取决 EKU |
| 是否过滤证书 | ✔ 是 |
七、一句话总结
✔ EKU 对 Nginx 来说只是“验证属性”
✔ EKU 对 OpenSSL client 来说是“证书选择开关”
❗你遇到的问题本质是 client 侧 EKU 过滤导致的握手路径变化
如果你要继续深挖（建议）
我可以帮你进一步定位你这个“FIN问题”的真正根因，包括：
-
OpenSSL 是否在 certificate selection 阶段丢证书
-
Java/SDK 是否做 EKU filtering
-
为什么同 JA3 但行为不同（非常关键）
-
FIN 在 TLS handshake 哪一层发生（精确定位）
只要你把 FIN来源IP + 是否有 ServerHello 给我，可以直接定死是哪一层在拒绝连接。