ssl单向认证仅服务端提供证书供客户端验证，适用于官网等公众场景；双向认证则要求客户端和服务端互验证书，用于银行后台等高安全场景，二者需按需独立配置，不可动态切换。
单向认证和双向认证不是“切换”关系，而是两种独立的认证模式，需根据安全需求提前设计并分别配置，不能运行时动态切换。所谓“策略”，本质是依据业务场景决定用哪一种，而不是在同一个端口上反复启停某项功能。
单向认证适用场景与配置要点
适用于面向公众的服务，比如官网、电商前台、内容平台等。用户只需确认服务器可信，无需身份核验。
- 服务端只需部署一张由可信CA签发（或自签名但已导入客户端信任库）的服务器证书，包含公钥和域名信息
- Web服务器（如Nginx/Tomcat）开启443端口HTTPS监听，配置
ssl_certificate和ssl_certificate_key即可 - 客户端（浏览器）自动校验证书有效性：是否过期、域名匹配、签发机构是否受信，通过即建立连接
- 无需在服务端配置客户端证书信任链，也不要求客户端安装任何个人证书
双向认证启用条件与关键步骤
适用于高敏感内部系统，如银行后台接口、政务审批系统、医疗数据交换平台等，必须双向确认身份。
- 服务端除自身证书外，还需加载一份“客户端根证书”（CA.crt），用于验证所有接入客户端证书的签发合法性
- Nginx中需设置
ssl_client_certificate指向该CA证书，并启用ssl_verify_client on；Tomcat需在Connector中添加clientAuth="true"及truststoreFile - 每个合法客户端必须持有由同一CA签发的有效证书（含私钥），且证书中通常嵌入唯一标识（如email、subject DN或扩展字段）用于服务端鉴权
- 客户端请求时需主动提供证书，若缺失或验证失败，服务端直接拒绝连接（HTTP 400或TLS握手中断）
共存策略：分端口或分域名隔离
若同一系统需同时支持两类访问，不能混在同一HTTPS端口下，必须物理或逻辑隔离：
- 不同端口：例如443走单向（面向用户），8443走双向（面向合作方API），各自独立配置SSL参数
- 不同域名：如
public.example.com配单向证书，api.example.com配双向证书，通过DNS或反向代理分流 - 不建议用URL路径区分（如
/api/v1/secure强制双向），因TLS握手发生在HTTP层之前，路径无法参与认证决策
运维与灰度注意事项
从单向升级为双向是重大变更，需协同推进：
- 客户端证书发放必须可控：使用统一CA签发，避免自签名泛滥；建议集成PKI体系或对接企业AD/LDAP自动分发
- 服务端日志需记录证书DN信息，便于审计和故障定位；可配合OAuth2或JWT做二次鉴权，但TLS层身份已是可信前提
- 上线前务必测试证书吊销（CRL/OCSP）机制是否生效，防止失效证书继续通行
- 移动端或IoT设备接入时，注意证书格式兼容性（如PKCS#12 vs PEM）、密钥长度限制（部分旧设备不支持ECDSA或4096位RSA）
