必须启用ssl_verify_client on并配齐CA证书、CRL/OCSP、证书链校验及后端二次鉴权，金融场景中合作银行、风控平台等调用方须持有效客户端证书，否则拒绝访问。
要让访客必须提供并验证合法客户端证书，核心是启用 ssl_verify_client on 并配齐信任链与校验逻辑。这在金融系统中不是可选项，而是准入硬门槛——比如合作银行接口、内部风控平台调用、监管报送通道，都必须确保调用方身份真实、证书未被吊销、且归属可信CA。
一、前提：构建可信的证书体系
不能用自签名证书应付，否则等于形同虚设：
- 使用私有 CA（如 OpenSSL 或 HashiCorp Vault）签发根证书（
ca.crt），所有客户端证书必须由该 CA 签发 - 服务端证书（
server.crt+server.key）需含 SAN，匹配实际访问域名或 IP - 客户端证书应包含唯一标识字段（如
CN或扩展字段authorityKeyIdentifier），便于后端做二次鉴权 - 部署 CRL 吊销列表（
crl.pem）或启用 OCSP Stapling（需后端配合），增强实时吊销检查能力
二、Nginx 关键配置项详解
仅写 ssl_verify_client on 不够，必须配套以下指令才能真正生效：
-
ssl_client_certificate /etc/nginx/ssl/ca.crt;—— 指定用于验证客户端证书的根 CA 文件 -
ssl_crl /etc/nginx/ssl/crl.pem;—— 启用 CRL 检查（推荐，尤其在金融场景中） -
ssl_verify_depth 2;—— 设置证书链校验深度，一般为 2（根 CA → 中间 CA → 客户端证书） -
ssl_prefer_server_ciphers on;—— 强制服务端选择更安全的加密套件（如ECDHE-ECDSA-AES128-GCM-SHA256） - 若需将证书信息透传给后端，加：
proxy_set_header X-Client-DN $ssl_client_s_dn;或 Base64 编码后的完整证书：proxy_set_header X-Client-Cert $ssl_client_cert;
三、强制校验的典型 server 块示例
以下配置实现“无证书即拒绝”，返回 400 错误，不进入业务逻辑：
server {
listen 443 ssl http2;
server_name api.bank-core.internal;
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
ssl_client_certificate /etc/nginx/ssl/ca.crt;
ssl_verify_client on;
ssl_crl /etc/nginx/ssl/crl.pem;
ssl_verify_depth 2;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
location / {
proxy_pass http://backend;
proxy_set_header X-Client-DN $ssl_client_s_dn;
proxy_set_header X-Client-Verify $ssl_client_verify;
}
}
四、常见失败原因与验证方法
启用后出现 400 或连接重置，先排查这些点：
- 客户端未发送证书：浏览器或 curl 需显式指定
--cert client.crt --key client.key；Java 客户端需配置KeyStore和TrustStore - CA 根证书路径错误或权限不足（Nginx worker 进程需可读）
- CRL 文件过期或格式非法（可用
openssl crl -in crl.pem -text -noout验证） - 客户端证书已过期、被吊销，或其 CN/OU 字段不符合后端策略（例如只接受
OU=Partner-Bank） - 日志中出现
SSL_do_handshake() failed：检查error_log /var/log/nginx/error.log debug;获取详细握手失败原因
