Linux与Windows环境下邮件服务器返回不同证书链问题排查

问题背景 #

相同的Java邮件发送代码与依赖包，在不同环境下出现差异：Linux环境发送成功，Windows环境因证书验证失败抛出异常，且两边获取的服务器证书主体不同。

核心依赖 #

<dependency>
    <groupId>javax.mail</groupId>
    <artifactId>mail</artifactId>
    <version>1.4.7</version>
</dependency>
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-email</artifactId>
    <version>1.3.3</version>
</dependency>

邮件发送核心代码 #

HtmlEmail htmlEmail = new HtmlEmail();
htmlEmail.setHostName(HOST); // e.g. mail.corp_name.com
htmlEmail.setSocketTimeout(60000);
htmlEmail.setSocketConnectionTimeout(60000);
htmlEmail.setAuthentication(userName, password);
htmlEmail.setPopBeforeSmtp(true, HOST, userName, password);
htmlEmail.setCharset("UTF-8");
htmlEmail.setSSLOnConnect(true);
htmlEmail.setFrom(this.userName, sendMaster);
htmlEmail.setSubject(sendSubject);
htmlEmail.setHtmlMsg(msg);
htmlEmail.send();

问题现象 #

• Linux环境（Java 1.8.0_131）：邮件发送成功，调试显示获取的证书链主体为CN=mail.corp_name.com
• Windows环境（Java 1.8.0_202）：发送失败，抛出异常：

PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

• 调试发现Windows环境获取的证书链主体为CN=*.corp_name.com

问题根源 #

1. JDK版本的SNI支持差异 #

Java 8u131及更早版本默认未启用SNI（Server Name Indication），而Java 8u202默认启用了SNI。SNI是TLS握手阶段的扩展，客户端会向服务器告知目标域名，服务器根据该信息返回对应匹配的证书：

• Linux环境用的8u131不发送SNI信息，服务器返回默认配置的mail.corp_name.com证书
• Windows环境用的8u202发送SNI信息，服务器匹配到泛域名*.corp_name.com证书并返回

2. 服务器多证书配置逻辑 #

邮件服务器同时配置了两种证书：

• 针对具体域名mail.corp_name.com的独立证书
• 针对泛域名*.corp_name.com的通配证书
  服务器会根据客户端是否发送SNI信息，返回不同的证书。

3. 信任库验证差异 #

Windows环境的JVM信任库中未导入*.corp_name.com证书对应的CA根证书，导致该泛域名证书无法通过PKIX路径验证；而Linux环境的信任库中已包含该CA根证书，或默认信任此证书颁发机构。

解决建议 #

• 导入泛域名证书到Windows JVM信任库：使用keytool命令将*.corp_name.com的证书导入Windows环境JDK的cacerts信任库中，命令示例：

  keytool -import -alias wildcard-corp -file /path/to/wildcard_cert.crt -keystore $JAVA_HOME/jre/lib/security/cacerts
  

• 临时关闭SNI：在Windows环境的JVM启动参数中添加-Djsse.enableSNIExtension=false，让客户端不发送SNI信息，服务器将返回与Linux环境一致的具体域名证书
• 升级依赖版本：考虑升级javax.mail和commons-email到更高版本，新版本对SNI的处理更完善，可避免此类兼容性问题

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