Java应用调用IP地址HTTPS接口报SSLHandshakeException证书SAN不匹配错误

你之前所有排查操作都只解决了「Java客户端无法信任服务端证书」的信任链问题，但当前报错属于TLS端点识别（Endpoint Identification）环节的主机名不匹配问题，和证书信任无关：

• 服务端持有的*.myappdomain.au泛域名证书，其主题备用名称（SAN）列表中根本没有包含10.20.30.40这个IP条目
• Java 8u151及以上的所有长期支持版本，严格遵循RFC 6125规范做主机名校验：当请求目标为IP地址时，只会匹配证书SAN中存储的同类型IP条目，不会拿IP去匹配CN或SAN里的泛域名规则——泛域名匹配逻辑仅对域名类请求生效。
• 你验证过的hosts映射方案本质，就是把请求目标从IP替换为证书支持的合法域名，绕开了IP和证书不匹配的校验逻辑，因此可以正常连通。

• 调整服务端证书配置（最合规的长期方案）
  联系API服务的运维人员，将10.20.30.40这个IP补充到现有泛域名证书的SAN列表中，重新签发并部署证书。这种方案不需要修改客户端任何代码，也不依赖操作系统层面的配置，从根源上让IP请求的校验逻辑通过，不存在任何安全降级风险。
• 客户端侧自定义主机名校验规则（无服务端权限时的适配方案）
  如果你无法修改服务端证书，可以在现有自定义SSLContext的逻辑基础上，配套替换默认的主机名验证器，做范围受控的适配。不要全局关闭主机名校验，只针对目标IP的请求做规则调整：

  // 在原有createSSLSocketFactory逻辑的基础上，配套设置自定义HostnameVerifier
  SSLContext sslContext = SSLContext.getInstance("TLS");
  sslContext.init(null, trustManagerFactory.getTrustManagers(), null);
  // 仅针对目标IP做适配，匹配证书中的泛域名规则
  HttpsURLConnection.setDefaultHostnameVerifier((hostname, session) -> {
      // 限定作用范围，仅对10.20.30.40的请求做规则匹配，不影响其他请求的校验逻辑
      if ("10.20.30.40".equals(hostname)) {
          try {
              // 复用默认校验逻辑，把请求目标替换为证书合法域名做匹配
              return HttpsURLConnection.getDefaultHostnameVerifier()
                  .verify("api.myappdomain.au", session);
          } catch (Exception e) {
              return false;
          }
      }
      // 其他请求全部走默认校验规则
      return HttpsURLConnection.getDefaultHostnameVerifier().verify(hostname, session);
  });
  

  注意：这种方式属于受控范围的安全适配，仅建议在内部受控网络环境、无法修改服务端证书的场景下使用，禁止全局放行所有主机名校验，避免引入中间人攻击风险。
• JVM层面配置主机名映射（无业务代码改动方案）
  如果你不方便修改业务代码，可以通过JVM启动参数配置进程内的主机名映射规则，效果和操作系统hosts配置一致，但不会影响服务器上其他服务：

  -Djdk.httpclient.hostnameMapping.10.20.30.40=myappdomain.au
  

  配置后JVM会在做主机名校验时，自动把IP10.20.30.40映射为证书支持的myappdomain.au做匹配，不需要修改业务请求的IP地址。

• 你现有自定义的SSLSocketFactory逻辑仅实现了证书信任加载的功能，完全没有涉及主机名验证的处理逻辑，无论怎么调整证书加载的代码，只要证书本身没有IP的SAN条目，这个报错就不会消失。
• 泛域名证书的匹配规则仅覆盖同层级的子域名访问场景，本身不支持IP直接访问，不存在调整JVM参数就能让泛域名证书自动支持IP访问的默认配置项。
• 现代Java版本的TLS校验逻辑已经不再校验证书CN字段的匹配关系，只识别SAN列表里的条目，哪怕你把IP写到CN里也不会生效。
• 不要为了快速解决问题把TrustManager实现为信任所有证书的模式，会彻底丧失TLS的加密和防篡改能力。

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