CN不匹配错误本质是TLS握手阶段证书验证失败，由底层SSL/TLS库触发；连接字符串host必须与证书CN或SAN完全一致，否则身份验证失败，常见于本地开发用localhost连但证书未包含该SAN。
CN不匹配错误本质是TLS握手阶段的证书验证失败，不是MongoDB自身报的错，而是底层SSL/TLS库（如OpenSSL、BoringSSL）在验证服务器证书时触发的。
为什么连接字符串里的host必须和证书CN或SAN完全一致
当客户端启用tls: true（比如Mongoose、PyMongo或mongo shell加--tls），它会做两件事：建立加密连接 + 验证对方身份。验证身份时，默认检查证书的subject.CN（Common Name）或subjectAltName（SAN）是否与连接字符串中写的主机名完全匹配。
常见错误现象：
MongooseServerSelectionError: Hostname/IP does not match certificate's altnamesssl.SSLCertVerificationError: hostname '127.0.0.1' doesn't match either of 'mongo.example.com', 'mongodb.internal'
使用场景：本地开发用localhost或127.0.0.1连，但证书里只写了mongo-prod.example.com；或者K8s里用Service DNS名连，但证书没包含该Service名。
参数差异：
- 证书里没写
subjectAltName字段 → 只 fallback 到查CN，且现代系统（iOS 13+/macOS 10.15+/Go 1.15+）已弃用CN校验，直接失败 - 证书有
subjectAltName但漏了DNS.1 = localhost或IP.1 = 127.0.0.1→ 匹配不到
绕过CN检查的风险与适用边界
开发调试时可以临时禁用验证，但绝不能用于生产环境。
实操建议：
- Mongoose：
{ tls: true, tlsAllowInvalidHostnames: true }—— 仅跳过主机名检查，仍校验证书签名和有效期 - PyMongo：
tlsAllowInvalidHostnames=True（注意不是tlsAllowInvalidCertificates，后者连CA签发都跳过） - mongo shell：
mongosh --tls --tlsAllowInvalidHostnames --host localhost:27017
性能 / 兼容性影响：禁用后TLS连接建立更快（少一次DNS/SAN比对），但失去服务端身份真实性保障，中间人攻击可轻松伪造响应。
正确生成含SAN的证书的关键点
自签或用CFSSL/OpenSSL生成证书时，必须显式指定subjectAltName，否则现代客户端直接拒绝。
容易踩的坑：
- OpenSSL配置里漏掉
subjectAltName = DNS:mongo.example.com,IP:10.0.1.5这一行 - 用了
req_extensions = req_ext但没在[req_ext]段定义subjectAltName - 证书里写了
DNS:mongo.example.com，但客户端连的是mongo.example.com:27017带端口 —— 端口不影响匹配，但别写成mongo.example.com:27017当SAN值 - 用IP直连却没在SAN里加
IP:192.168.1.10，只写了DNS名
验证命令：openssl x509 -in server.pem -text -noout | grep -A1 "Subject Alternative Name"
客户端x.509认证（mTLS）时CN/SAN不相关，但subject DN必须唯一
注意区分：上面讲的是「客户端验证服务器证书」，而x.509客户端认证（即用客户端证书登录MongoDB）不校验CN或SAN，它只看证书的subject字段（如O=MyOrg,OU=Dev,DC=example,DC=com）是否与$external数据库中创建的用户名一致。
所以如果你启用了双向TLS（--tlsMode requireTLS + 客户端提供--tlsCertificateKeyFile），却仍报CN不匹配，说明问题出在服务器证书那一侧，不是客户端证书的问题。
真正容易被忽略的复杂点：同一个CA签发的服务器证书和客户端证书，它们的subject中O、OU、DC字段如果完全相同，MongoDB会认为这是集群内部通信证书，自动授予最高权限并记录警告 —— 这不是CN问题，但常被误判为证书配置错误。
