一、错误码1930的报错特征：握手阶段为什么提示strength强度设置错误
MongoDB错误码1930对应SSLHandshakeFailed，表示TLS/SSL握手没有完成。开启TLS后，mongod或mongos在证书加载、协议协商、密钥交换过程中如果检测到证书强度、签名算法或加密套件不安全，就会在日志里记录类似SSL handshake failed, error:0A00018F:SSL routines::ee key too small的信息。这里的strength强度设置错误并非MongoDB某个独立配置项，而是底层OpenSSL（或Windows SChannel）对证书安全强度校验失败后的归类提示。
如果使用自签名的RSA 1024位证书，在较新版本的OpenSSL或强制FIPS模式的环境中，服务启动阶段可能不会直接中断，但客户端一发起连接，服务端在发送ServerHello后就会终止握手。客户端往往看到network error while attempting to run command，而服务端日志才会出现1930错误码。如果只盯着客户端看，很容易误判为网络策略或端口问题。
定位时建议先查看mongod日志中与SSL handshake failed相关的完整堆栈，再看证书文件本身。OpenSSL对弱密钥的判定阈值通常会写为ee key too small或ca md too weak，前者表示实体证书密钥过短，后者表示证书签名算法使用了MD5或SHA1这类已不再接受的摘要算法。无论哪种情况，都会被归纳为strength强度设置错误一类问题。
二、通过openssl命令快速判断证书强度是否满足要求
先确认mongod加载的证书文件路径。默认配置通常在/etc/mongod.conf中声明net.tls.certificateKeyFile，也可能配置了net.tls.certificateSelector。拿到证书路径后，优先检查证书公钥长度和签名算法。
openssl x509 -in /etc/ssl/mongodb/server.pem -text -noout | grep -E "Public-Key|Signature Algorithm"
输出中如果看到Public-Key: (1024 bit)，说明RSA密钥长度只有1024位。现代TLS安全基线一般要求RSA至少2048位，部分金融或政务环境会要求3072位或改用椭圆曲线密钥。如果签名算法显示sha1WithRSAEncryption或md5WithRSAEncryption，同样会被OpenSSL安全级别拦下。执行openssl s_client连接本地27017端口，也能观察握手失败时返回的具体错误。
openssl s_client -connect 127.0.0.1:27017 -tls1_2 -servername localhost
该命令如果输出alert handshake failure或sslv3 alert bad certificate，说明服务端在证书校验阶段主动拒绝。此时不用急着改MongoDB配置，先处理证书强度问题。还要检查证书链是否完整：如果certificateKeyFile只放了服务器证书，没有附上中间CA证书，部分客户端会因为无法构建完整信任链而失败。可以用以下命令拼接服务器证书和中间证书，确保证书链顺序正确。
cat server.crt intermediate.crt > server.pem
再有就是私钥与证书是否匹配。私钥文件如果是加密的，mongod启动时可能需要PEMKeyPassword。私钥强度不足同样会触发1930错误，例如仍然使用1024位RSA私钥。可以用openssl rsa命令检查私钥长度，不过执行前注意私钥文件的读权限和脱敏要求。
三、调整MongoDB的TLS配置项并替换高强度证书
确认证书强度不符合要求后，最简单的方式是重新生成私钥和证书。生成2048位RSA私钥的命令如下，命令中不使用弱摘要算法，证书签名使用SHA256。
openssl genrsa -out mongodb.key 2048 openssl req -new -key mongodb.key -out mongodb.csr -subj "/CN=mongodb.internal" openssl x509 -req -in mongodb.csr -signkey mongodb.key -out mongodb.crt -days 365 -sha256 cat mongodb.crt mongodb.key > /etc/ssl/mongodb/server.pem chmod 600 /etc/ssl/mongodb/server.pem
在mongod.conf中，启用TLS并指向新证书。配置文件示例如下：
net:
port: 27017
bindIp: 0.0.0.0
tls:
mode: requireTLS
certificateKeyFile: /etc/ssl/mongodb/server.pem
CAFile: /etc/ssl/mongodb/ca.crt
allowConnectionsWithoutCertificates: false
如果希望进一步排除弱密码套件，可以配置tlsCipherConfig。这个参数接受OpenSSL密码字符串，例如只允许TLS1.2和TLS1.3中安全性较高的套件。要注意不同OpenSSL版本对cipher string的支持略有差异，过旧的套件名可能在新版本中已经被移除，导致mongod无法启动。建议先在测试环境验证完整配置。
net:
tls:
mode: requireTLS
certificateKeyFile: /etc/ssl/mongodb/server.pem
tlsCipherConfig: HIGH:!aNULL:!MD5:!3DES
启用配置后重启mongod。如果使用包管理器安装，Windows下注意mongod.cfg路径，例如C:\Program Files\MongoDB\Server\7.0\bin\mongod.exe --config C:\Program Files\MongoDB\Server\7.0\bin\mongod.cfg。启动后可以再用mongosh连接验证：
mongosh "mongodb://127.0.0.1:27017/?tls=true&tlsCAFile=/etc/ssl/mongodb/ca.crt"
如果连接成功，并且服务端日志不再出现1930，说明证书强度问题已经解决。如果仍然失败，需要检查系统OpenSSL库和MongoDB版本是否一致，旧版Windows SChannel可能对证书安全级别的行为不同。
四、FIPS模式与严格安全策略下的强度要求差异
一些政企环境会开启FIPS模式，或通过系统安全策略强制要求更高的密钥强度和有限密码套件。MongoDB企业版提供net.tls.FIPSMode参数，开启后底层使用经过FIPS认证的加密模块，对证书密钥长度和签名算法会执行更严格校验。RSA 1024位、SHA1签名、MD5套件在FIPS模式下基本都会被拒绝，并可能表现成1930错误。
这种情况下需要使用符合FIPS要求的密钥和证书，例如RSA 2048位以上、签名算法SHA256或以上，或者使用P-256以上的椭圆曲线证书。生成椭圆曲线私钥可以参考：
openssl ecparam -genkey -name prime256v1 -noout -out mongodb-ec.key openssl req -new -key mongodb-ec.key -out mongodb-ec.csr -subj "/CN=mongodb.internal" openssl x509 -req -in mongodb-ec.csr -signkey mongodb-ec.key -out mongodb-ec.crt -days 365 -sha256
椭圆曲线密钥在相同安全强度下长度更短，计算开销也更小，适合资源受限或高并发TLS握手场景。证书替换后，检查mongod启动日志中是否还有strength相关报错。也可以使用openssl ec -in mongodb-ec.key -text -noout确认密钥曲线参数。
如果仍出现1930，需要考虑客户端证书或CA证书强度。使用双向TLS时，客户端证书同样要满足强度要求，不能只替换服务端证书。CA证书如果使用1024位RSA或MD5签名，也会在证书链校验时被标记为弱强度。保持CA根证书和中间证书同步升级，才能从整条信任链上避免strength强度设置错误。
