Nginx 的 $ssl_client_s_dn 变量可获取客户端证书 DN，需启用 mTLS 并满足 ssl_verify_client、CA 证书配置及有效客户端证书等条件；可用于日志记录、透传 X-Client-DN 请求头给后端、或基于 DN 的访问控制。
Nginx 可以通过 $ssl_client_s_dn 变量获取客户端证书的可分辨名称（Subject Distinguished Name），前提是已启用双向 TLS（mTLS）并成功完成客户端证书验证。这个变量在日志记录、请求头透传、访问控制等场景中非常实用。
确保 mTLS 正确配置
要让 $ssl_client_s_dn 有值，必须满足以下条件：
- 在 server 块中启用
ssl_verify_client on或ssl_verify_client optional - 配置有效的
ssl_client_certificate（CA 证书文件）或ssl_trusted_certificate - 客户端实际提供了符合 CA 签发的合法证书，且未过期、未吊销
若验证失败或未提供证书，该变量为空字符串；ssl_verify_client optional_no_ca 不推荐使用，此时变量可能不可靠。
在 access_log 中记录客户端身份
将证书主题信息写入访问日志，便于审计和排查：
log_format cert_log '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'client_dn="$ssl_client_s_dn"';然后在 server 或 location 中引用：
access_log /var/log/nginx/client-cert.log cert_log;
日志中会看到类似：
192.168.1.100 - - [10/Jan/2024:14:22:33 +0000] "GET /api/v1/user HTTP/1.1" 200 123 "-" "curl/7.68.0" client_dn="CN=alice.example.com,OU=Engineering,O=Example Inc.,C=US"
将 DN 作为请求头透传给后端服务
后端应用（如 API 服务）常需识别调用方身份，可通过 proxy_set_header 传递：
location /api/ {
proxy_pass https://backend;
proxy_set_header X-Client-DN $ssl_client_s_dn;
proxy_set_header X-Client-Verify $ssl_client_verify;
}这样后端可通过 X-Client-DN 头解析 CN、OU、O 等字段，实现细粒度权限控制。注意：若客户端未认证，$ssl_client_s_dn 为空，建议同时检查 $ssl_client_verify 是否为 SUCCESS。
基于 DN 的简单访问控制
可在 location 或 if 块中做基础匹配（适用于规则较少的场景）：
if ($ssl_client_s_dn !~ "CN=alice\.example\.com") {
return 403;
}
# 或只允许特定部门
if ($ssl_client_s_dn !~ "OU=Engineering") {
return 403;
}更健壮的做法是结合 map 指令预定义白名单，避免重复正则匹配：
map $ssl_client_s_dn $allowed {
default 0;
"~CN=alice\.example\.com.*" 1;
"~CN=bob\.example\.com.*OU=Admin" 1;
}
server {
...
if ($allowed = 0) { return 403; }
} 
