需配置ssl_verify_client on并正确设置ssl_client_certificate，确保$ssl_client_s_dn在日志中完整记录客户端DN；配合$ssl_client_fingerprint等变量增强审计溯源能力。
要利用 $ssl_client_s_dn 在 Nginx 日志中完整审计双向 TLS 认证（mTLS）客户端身份，核心是确保该变量在日志格式中被正确引用，且上游证书链已由客户端完整提供、服务端成功验证。
确认 mTLS 已启用且证书可被解析
$ssl_client_s_dn 仅在客户端成功完成双向认证后才非空。若日志中该字段为空或显示“-”，常见原因包括：
- Nginx 未配置
ssl_verify_client on或optional（推荐用on强制认证） - 客户端未发送证书，或发送的证书不被
ssl_client_certificate指定的 CA 信任 - 证书链不完整（如缺少中间 CA），导致 Nginx 无法构建有效路径，
$ssl_client_s_dn不被填充
定义含 DN 的自定义日志格式
在 http 或 server 块中定义日志格式，显式包含 $ssl_client_s_dn：
log_format mtls_log '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'client_dn="$ssl_client_s_dn" '
'cert_subject_hash="$ssl_client_fingerprint";
注意：$ssl_client_s_dn 是标准 OpenSSL 格式字符串（如 CN=api-client,OU=Devices,O=Acme,L=San Francisco,ST=CA,C=US），无需额外解码；若需结构化字段（如单独提取 CN），需后续用日志分析工具（如 Logstash、Fluentd）解析。
确保日志写入时变量稳定可用
该变量在请求处理阶段即可访问，但需避免在错误上下文（如 access_log 指令位于未启用 SSL 的 server 块）中使用。典型安全配置示例：
server {
listen 443 ssl;
ssl_certificate /path/to/server.crt;
ssl_certificate_key /path/to/server.key;
ssl_client_certificate /path/to/ca-bundle.crt; # 信任的根+中间 CA
ssl_verify_client on; # 强制双向认证
<pre class="brush:php;toolbar:false;">access_log /var/log/nginx/mtls_access.log mtls_log;
...}
若使用 ssl_verify_client optional，需配合 if ($ssl_client_verify != SUCCESS) { return 401; } 显式拦截失败请求，否则 $ssl_client_s_dn 可能为空却仍记入日志。
补充审计维度提升溯源能力
单靠 DN 不足以应对证书复用或吊销场景，建议组合以下变量增强审计完整性：
-
$ssl_client_fingerprint：SHA-1 或 SHA-256 指纹（需 Nginx ≥ 1.7.8 + OpenSSL ≥ 1.0.2），唯一标识证书二进制内容 -
$ssl_client_escaped_cert：Base64 编码的 PEM 证书（慎用，体积大，仅调试或合规强要求时开启） -
$ssl_client_serial：证书序列号，便于对接 CRL/OCSP 查询状态 -
$ssl_client_i_dn：签发者 DN，可用于识别签发 CA 层级
不复杂但容易忽略的是：日志轮转策略需适配高流量下证书信息带来的体积增长，建议按天切分并启用压缩。
