OpenSSL多层级自签名CA架构搭建及证书验证问题咨询

当然可以用OpenSSL实现你这套三级CA架构！咱们先搞定你遇到的验证失败问题，再把整个架构的正确操作逻辑理清楚。

首先，你的验证命令报错的核心原因是信任链不完整：你用APP_1的证书直接验证Company_1的中间证书，但OpenSSL需要从根CA开始的完整信任链路才能确认证书的合法性。具体来说，Company_1的证书是APP_1签发的，但APP_1本身是根CA签发的——当你只给OpenSSL提供APP_1的证书时，它能确认Company_1的 issuer 是APP_1，但无法验证APP_1本身是否可信（因为找不到根CA的证书），所以就抛出了unable to get issuer certificate的错误。

正确验证Company_1证书的两种方法 #

方法1：合并信任链文件

把根CA证书和APP_1证书合并成一个完整的信任链文件，然后用这个文件作为验证的CA源：

# 合并根CA和APP_1证书到同一个文件
cat /CA/root/certs/root.cert.pem /CA/app_1/certs/app_1.cert.pem > /CA/full_trust_chain.pem
# 用合并后的信任链验证Company_1证书
openssl verify -CAfile /CA/full_trust_chain.pem /CA/app_1/company_1/certs/company_1.cert.pem

方法2：指定根CA为信任源，附加中间证书

直接用根CA作为信任锚，同时通过-untrusted参数指定APP_1这个中间证书（因为它本身需要被根CA验证）：

openssl verify -CAfile /CA/root/certs/root.cert.pem -untrusted /CA/app_1/certs/app_1.cert.pem /CA/app_1/company_1/certs/company_1.cert.pem

关于你的CA架构的额外注意事项 #

为了确保整个层级能正常工作，还有几个关键配置要检查：

• Basic Constraints设置：
  • 根CA和所有中间CA（APP_1、Company_1）的证书必须设置basicConstraints = CA:TRUE
  • 给APP_1的证书要设置pathlen:1（这样它签发的Company_1还能继续签发终端用户证书；如果设为0，Company_1就不能再签下级证书了）
  • 终端用户证书必须设置basicConstraints = CA:FALSE
• 签发流程正确性：
  每个下级CA的证书请求（CSR）必须由上级CA用对应的私钥签发，确保签名算法一致，且subject信息符合上级CA的配置要求
• 证书存储安全：
  根CA的私钥一定要离线存储，不要放在联网服务器上；中间CA的私钥也要严格限制访问权限

按照以上方法调整后，你应该就能成功验证Company_1的证书了，整个三级CA架构也能正常运转。

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