如何手动验证X.509证书中的主机名匹配（CN/SAN）

在Ja va生态中，标准的`HostnameVerifier`接口确实好用——但它的`verify`方法强制要求传入`SSLSession`，这也就意味着，如果你只是想离线检查一份证书（比如做证书预检、审计，或者自定义信任链验证），这条路就走不通了。这时候，手头只有一个`X509Certificate`对象和待验证的主机名（比方说`"api.example.com"`），就得自己动手解析证书里的Subject Alternative Name（SAN）扩展和Common Name（CN）字段，并且按照RFC 6125的规则来做匹配。 下面就把这个实现过程拆开来讲，附带完整的示例代码。 ✅ **步骤一：把目标主机名整理好** 首先，确保主机名格式规整——统一转小写（DNS不区分大小写），去掉端口号和协议前缀： ```ja va String host = "api.example.com".toLowerCase(); ``` ✅ **步骤二：从证书里提取Subject Alternative Names（SAN）** SAN已经是现代证书的标配，也是验证主机名时的首选字段。它支持DNS名称、IP地址等多种类型，对应的OID是2.5.29.17。解析方式如下： ```ja va Collection> sanEntries = x509.getSubjectAlternativeNames(); if (sanEntries != null) { for (List entry : sanEntries) { if (entry.size() >= 2 && Integer.valueOf(entry.get(0).toString()) == 2) { // 2 = dNSName String dnsName = (String) entry.get(1); if (matches(dnsName, host)) { return true; // 匹配成功 } } } } ``` ✅ **步骤三：如果SAN不存在，再回退到Common Name（CN）** 这里有个关键点：RFC 2818已经明确不推荐直接依赖CN了。只有在证书没有SAN的情况下，CN才可以作为备用项。而且提取CN时不能用简单的字符串查找或正则，那样很容易被恶意DN中的`CN=`子串绕过。正确做法是用`X500Principal.RFC2253`来解析： ```ja va String cn = extractCN(x509.getSubjectX500Principal()); if (cn != null && matches(cn, host)) { return true; } ``` `extractCN`方法的实现如下（基于标准ASN.1解析，安全可靠）： ```ja va private static String extractCN(X500Principal principal) { try { String name = principal.getName(X500Principal.RFC2253); for (String pair : name.split(", ")) { if (pair.startsWith("CN=")) { return pair.substring(3).trim(); } } } catch (Exception ignored) {} return null; } ``` ✅ **步骤四：实现通配符匹配（RFC 6125 §6.4.3）** 通配符只允许单级匹配，比如`*.example.com`可以匹配`api.example.com`，但不能匹配`sub.api.example.com`，而且星号必须位于最左侧。匹配逻辑如下： ```ja va private static boolean matches(String pattern, String host) { if (pattern == null || host == null) return false; if (pattern.equalsIgnoreCase(host)) return true; // 支持通配符 *.example.com if (pattern.startsWith("*.") && pattern.indexOf('*', 1) == -1) { String suffix = pattern.substring(1); // ".example.com" return host.length() > suffix.length() && host.endsWith(suffix) && host.charAt(host.length() - suffix.length() - 1) == '.'; } return false; } ``` ⚠️ **几个需要留意的坑** - **别把CN当主力**：现在公共CA签发的证书基本都带SAN。如果SAN存在但没覆盖目标主机名，就算CN匹配上了也不能过。 - **避免正则注入风险**：有些老代码用`replace()`配合正则提取CN，这在生产环境里是个隐患——恶意构造的DN可能让你误判。务必用`X500Principal.RFC2253`这类标准解析。 - **别忘了IPv4/IPv6**：SAN里也可能出现`iPAddress`类型（比如`192.168.1.1`或`2001:db8::1`），如果需要支持IP地址匹配，得单独处理这一分支。本文主要聚焦DNS名称匹配。 - **国际化域名（IDN）**：实际场景中，最好先把主机名转成Punycode（ASCII形式），再和证书里存的值比对，避免因为编码不一致导致匹配失败。 照着这个思路，你就可以在离线的任意上下文中，完全不依赖网络连接和`SSLSession`，完成一套符合规范、足够健壮的证书主机名验证逻辑了。