先给你梳理几个大概率导致证书验证失败的点，咱们一个个排查解决：

1. checkHost配置格式错误 #

你客户端配置里的checkHost = 172.30.12.28:6390是有问题的——checkHost只需要填写主机名或IP地址，不能带端口。Stunnel在验证证书时，会把这个值和证书里的Common Name（CN）或Subject Alternative Name（SAN）字段做匹配，带端口的话完全匹配不上，直接触发验证失败。

修正后的客户端该配置项应为：

checkHost = 172.30.12.28

2. 证书标识与checkHost不匹配 #

如果你的证书是自签的，一定要确保证书里的CN或SAN字段包含服务端的IP（也就是172.30.12.28）。你可以用以下命令查看证书内容，确认这一点：

openssl x509 -in stunnel.pem -text -noout

如果证书里没有这个IP的标识，需要重新生成证书，生成时指定IP作为CN或添加SAN扩展，比如：

openssl req -x509 -newkey rsa:4096 -keyout stunnel.key -out stunnel.pem -days 365 -nodes -subj "/CN=172.30.12.28" -addext "subjectAltName=IP:172.30.12.28"

生成后把新的证书同步到服务端和客户端替换旧文件。

3. 端口不匹配导致的隐性问题 #

你客户端的connect = 172.30.12.28:6390，但服务端的accept = 6380，这两个端口完全不一致！虽然你说配置加载成功，但实际连接时可能因为端口不匹配，触发了类似证书验证的错误提示（或者这是另一个需要先解决的问题）。

把两端的端口统一，比如客户端改成：

connect = 172.30.12.28:6380

4. 证书链完整性问题 #

客户端配置的CAfile = stunnel.pem，要确保这个文件包含完整的信任链：

• 如果是自签证书：stunnel.pem应该就是服务端的证书本身（因为自签证书自己就是根CA）
• 如果是第三方CA签发的：CAfile应该填CA的根证书，而不是服务端的证书

修正后的完整配置示例 #

客户端配置 #

[redis-stunnel]
client = yes
cert = stunnel.pem
accept = 127.0.0.1:6379
connect = 172.30.12.28:6380
verifyChain = yes
CAfile = stunnel.pem
checkHost = 172.30.12.28
OCSPaia = yes

服务端配置 #

[redis-stunnel-server]
accept = 6380
connect = 6379
cert = stunnel.pem

排查完这些点后，重启Stunnel服务端和客户端，应该就能解决证书验证失败的问题了。

内容的提问来源于stack exchange，提问作者Rahul Roshan