证书没过期，RSA公钥也有2048位，OpenSSL却报CA signature digest algorithm too weak。先别继续加长密钥：这个错误盯的是证书签名摘要，不是单看公钥位数。本文用隔离证书复现error 68，区分签名算法、证书指纹与安全等级，再给出重新签发和验收路径。
一、看到error 68，先读完整错误和depth
这条错误表示证书签名摘要强度未达到当前验证策略要求。错误文字虽然带CA，也可能出现在叶证书：叶证书的签名由签发者生成，不等于叶证书自身是CA。
保留错误前后的证书名称、depth和进程退出码。depth 0指待验证叶子，depth 1指它的直接签发者；更多层级沿验证路径向上。68是X.509验证错误号，不是Shell退出码，也不是HTTP状态码。本轮失败进程实际退出2。
别把它与CA certificate key too weak混为一谈。后者关注公钥强度；还有certificate signature failure，属于验签失败。虽然都写着"签名"或"CA"，需要修改的对象并不一样。
二、先确认版本，再看Signature Algorithm
下面假定已有leaf.pem叶证书、intermediate.pem中间CA、root.pem授权信任根，每个文件对应一张证书。命令只读取本地材料，不修改系统信任，也不访问生产站点。
bash
openssl version -a
openssl x509 -in leaf.pem -noout -text在输出中分别看Signature Algorithm与Public-Key。RSA 2048位只描述公钥，不能证明签名采用了合适摘要；算法需要连同签名方案一起识别，不能只看文件名里的sha256。
本轮命令行是OpenSSL 1.1.1k FIPS构建，这是实验环境，不是推荐版本。生产请使用受支持的发行版组件，并核对应用实际链接库、配置和密码策略。命令行openssl与Nginx、Python或Java用的实现不一定相同。
OpenSSL 3.0官方安全等级文档写明level 1禁止SHA-1和MD5签名；本机旧构建的SHA-1对照并未按这个预期失败。因此本文不拿3.0说明冒充所有1.1.1环境的实测，正式复现采用明确触发错误的MD5样本。
三、SHA-256指纹不是SHA-256签名
叶证书看完，还要查看报错层级对应的中间CA。即使叶证书已经重新签发，中间CA证书上的弱签名仍可能留在路径中。这里只读取公开证书，排障不需要把私钥上传给别人。
bash
openssl x509 -in intermediate.pem -noout -text
openssl x509 -in leaf.pem -noout -fingerprint -sha256第二行计算的是整张证书DER编码的SHA-256指纹，适合识别"是不是同一张证书"。它不会重签证书，也不会改变原有Signature Algorithm。给旧门锁拍一张高清照片，门锁并不会跟着升级。
本轮MD5签名的叶证书同样能算出SHA-256指纹。指纹值需与独立可信来源核对，不能用它证明签名摘要强度。
四、固定信任材料与认证等级
先把链验证从线上连接中拆出来。示例SAN是保留测试域名api.example.test，正式排查替换为实际服务名称；root.pem必须来自经授权核验的渠道，不能直接信任对端发来的根。
bash
openssl verify -trusted root.pem \
-untrusted intermediate.pem -auth_level 2 \
-purpose sslserver -verify_hostname api.example.test \
-show_chain leaf.pem-trusted限定信任锚，在此版本中排除默认CA列表，不与-CAfile或-CApath混用；-untrusted提供辅助构链材料，并不授信。-auth_level 2是本实验显式选择的认证强度，不代表你的应用默认等级，也不是统一生产配置建议。
这里同时检查服务端用途和主机名。签名摘要合格只是其中一关，证书过期、名称不匹配或材料不足仍会失败。不要删掉这些检查，换取一行孤零零的OK。
五、隔离实验：只换摘要，错误落在哪层
实验在临时目录生成RSA 2048位测试密钥，使用独立OpenSSL配置。强对照采用SHA-256；弱样本只把对应证书签名改为MD5，保持必要的CA约束、用途与名称。测试结束清除私钥和证书，未改系统时间、信任库或生产服务。
| 测试材料 | level 2结果 | 观察重点 |
|---|---|---|
| 叶子与中间CA均SHA-256 | 退出0，OK | 强签名对照 |
| 仅叶子采用MD5签名 | 68，depth 0 | 错误不只出现在CA证书 |
| 仅中间CA采用MD5签名 | 68，depth 1 | 只换叶子不够 |
| 直接信任MD5自签根，叶子SHA-256 | 退出0，OK | 信任锚签名检查边界 |
最后一行仅用于说明边界：verify对信任锚的签名算法强度存在例外，但其公钥仍须满足指定等级。不能据此说MD5根"安全"，更不能把有问题的中间CA直接加入信任锚来绕过检查。
另做level 0诊断对照，弱中间CA样本没有变好：本机继续报error 7和unknown message digest algorithm。降低一道门槛不保证其他验证成功，也不能修复原签名。这个对照不进入正式验收命令。
六、修复是重新签发，不是重新算指纹
若depth 0对应叶证书弱签名，应向签发方申请符合目标环境策略的新证书，并核对SAN、用途、有效期和私钥配对。不能靠转换PEM/DER、改后缀或重新生成指纹升级已有签名。
若问题在中间CA证书，需要签发方提供可用的强签名链或安排CA迁移。新中间CA若换了公钥，原有叶证书不能仅通过替换链文件就自动改由新密钥签发；应按签发方路径重新签发和验证。
部署前保留旧材料与回退方案，确认实际终止TLS的位置。离线验证成功不证明负载均衡或应用已加载新链，还需按节点、SNI和受影响客户端做真实握手与业务测试。本文没有把离线实验包装成浏览器或生产HTTPS实测。
七、把失败写进验收清单
以下Bash包装器保留完整日志，检查进程退出码。日志路径不可写也必须失败，不能因为终端没看到错误就报喜；验证名称和等级沿用已确认的实验条件。
bash
umask 077
rc=0
openssl verify -trusted root.pem \
-untrusted intermediate.pem -auth_level 2 \
-purpose sslserver -verify_hostname api.example.test \
-show_chain leaf.pem >verify.log 2>&1 || rc=$?
[ "$rc" -eq 0 ] || exit "$rc"
printf '%s\n' '离线证书验证通过；仍需实际HTTPS验收'- 记录运行库、验证策略、完整错误、depth与退出码。
- 区分签名摘要、公钥位数和整证书指纹。
- 检查叶子及中间CA，不只替换第一个PEM对象。
- 保持原有安全要求，重新签发后复验用途、名称和完整路径。
- 最后核对线上链、实际客户端及业务响应；离线通过单独记录。
error 68的修复目标是让实际证书路径满足要求，不是仅仅消除错误文字。