Ubuntu服务器前端邮件连接触发SSL证书验证错误（返回码21）

看起来你碰到了一个典型的SSL证书链不完整问题，导致前端应用没法正常建立邮件连接，抛出了Verify return code: 21 unable to verify the first certificate的错误。结合你提供的openssl s_client输出，我们来分析下原因和解决办法：

问题根源分析 #

从你贴的命令输出里能看到，服务器返回的证书链只有1层（仅服务器自身证书），缺少了颁发这个证书的中间CA证书（也就是Sectigo RSA Domain Validation Secure Server CA的证书）。当你的Ubuntu服务器尝试验证证书时，找不到中间证书来衔接服务器证书和系统信任的根CA，就会触发这个“无法验证第一证书”的错误。而另一台服务器能正常运行，大概率是它的系统信任存储里已经预装了对应的中间证书，或者目标服务器在和它握手时返回了完整的证书链。

解决办法 #

根据你的场景，有几种可行的修复路径：

1. 修复目标服务器的证书配置（如果你有权限管理它）

这是最彻底的解决方案：

• 确认目标服务器（stage-accountservice.easyfastnow.com）的服务配置（比如Nginx、Postfix等）是否指定了完整的证书链。你需要将服务器证书和对应的中间证书合并成一个文件（注意顺序：先放服务器证书，再放中间证书），然后在服务配置中引用这个合并后的文件。
• 举个Nginx的例子：配置ssl_certificate时，不要只填服务器证书文件，要用包含完整链的文件。

2. 在出问题的Ubuntu服务器上手动安装中间证书

如果没法修改目标服务器配置，就给当前服务器添加信任该中间证书：

• 下载Sectigo RSA Domain Validation Secure Server CA的证书文件（确保是对应版本的中间证书）
• 将证书文件（比如命名为sectigo-intermediate.crt）放到系统证书目录：/usr/local/share/ca-certificates/
• 运行命令更新系统信任存储：

  sudo update-ca-certificates
  

• 之后重新运行openssl s_client -connect stage-accountservice.easyfastnow.com:443 -tls1_2验证错误是否消失。

3. 给前端应用单独配置证书链（如果应用有独立的证书管理）

如果你的前端应用（比如Node.js、Python应用）有自己的SSL配置，可以直接在应用里指定完整的证书链：

• 比如Node.js中，使用https模块发起请求时，通过ca选项传入中间证书的内容，让应用信任这个证书链。

验证方法 #

你可以运行以下命令查看完整的证书链返回情况：

openssl s_client -connect stage-accountservice.easyfastnow.com:443 -tls1_2 -showcerts

如果输出里只有1个证书块，说明目标服务器确实没有返回完整链，优先修复服务器端配置更稳妥。

备注：内容来源于stack exchange，提问作者Swapneswar Mohapatra