Java Mail TLS发送失败：Tomcat环境PKIX路径构建错误排查

一、AUTH扩展参数差异的原因 #

• 核心原因是两个环境下Java Mail客户端向SMTP服务器发送的EHLO/HELO标识不同。Office 365的SMTP服务器会根据客户端提供的标识（通常是主机名）动态返回不同的认证方式列表：
  • 独立运行时，本地OpenJDK8默认使用机器真实主机名发送EHLO，Office 365识别为常规独立客户端，返回LOGIN XOAUTH2；
  • Tomcat+cPanel环境中，Tomcat通常被配置为使用cPanel的虚拟主机名或内部标识发送EHLO，Office 365将其判定为Web应用类客户端，因此返回PLAIN LOGIN。
• 另外，Tomcat的类加载机制会影响Java Mail读取系统默认配置的逻辑，导致客户端握手行为和独立运行时产生差异。

二、PKIX路径构建失败的本质原因 #

这个SSL握手异常和AUTH参数差异是同一问题的连锁反应：

• cPanel环境下Tomcat使用的JRE大概率是cPanel自带的版本，而非你本地的OpenJDK8，其信任存储（cacerts）中缺少Office 365 SMTP服务器的根证书；
• 当服务器返回PLAIN LOGIN时，Java Mail会触发STARTTLS加密流程，但Tomcat的JRE无法验证服务器的SSL证书链，最终抛出PKIX path building failed错误；
• 你本地的OpenJDK8的cacerts已经预装了Office 365所需的根证书（比如DigiCert的根证书），所以能顺利完成SSL握手和认证。

可行的解决方向 #

• 检查Tomcat使用的JRE路径，对比其cacerts与本地OpenJDK8的差异，直接复制本地信任存储文件到Tomcat的JRE目录，或手动导入缺失的根证书；
• 在代码中显式指定EHLO标识：props.put("mail.smtp.localhost", "你的合法主机名")，强制Office 365返回一致的认证方式；
• 升级Java Mail到1.6.2及以上版本，新版本对不同环境的兼容性更强，能自动处理更多SSL和认证场景。

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