HttpClient5中HTTPS证书公钥一致时连接是否可信？（TLS1.2场景）

核心结论 #

你当前的方案本质是**公钥钉扎（Public Key Pinning）**的简化实现，在TLS 1.2协议下，攻击者在不持有对应私钥的前提下，几乎不可能欺骗通过该校验的HTTPS客户端，但你的代码实现存在明显缺陷，同时还有几个边界风险需要注意。

• 首先解释自验签名报错的原因：X.509证书的签名是由签发它的CA私钥生成的，验签必须使用对应CA的公钥，用证书自己的公钥验证自身签名当然会返回签名不匹配，这是符合PKI设计的正常逻辑。
• 关于校验逻辑的安全性：
  非对称加密的特性决定了，公钥公开的前提下，攻击者无法推导得到对应的私钥。TLS 1.2握手流程本身要求服务端必须证明自己持有证书公钥对应的私钥：如果是RSA密钥交换，服务端需要用私钥解密客户端发送的预主密钥；如果是ECDHE等前向安全的密钥交换，服务端需要用私钥对协商参数签名。攻击者就算能伪造一个公钥和你预置公钥完全一致的证书，也无法完成后续的TLS握手，自然无法欺骗客户端。
• 你当前代码的严重缺陷：
  Java中字节数组的equals()方法是继承自Object的引用比较，而非内容比较。也就是说如果currentCertificatePublicKey是你提前存储的字节数组，和getEncoded()返回的新字节数组就算内容完全一致，也会返回false。正确的写法应该是用java.util.Arrays的数组内容比较方法：

  Arrays.equals(x509Certificate.getPublicKey().getEncoded(), expectedPublicKeyEncoded)
  

• 额外风险提示：
  1. 你跳过了完整的证书校验逻辑，建议补充校验证书的有效期、密钥用法等字段，避免异常场景下的潜在风险。
  2. 公钥钉扎的运维成本很高：一旦服务端证书更新更换了密钥对，所有未更新预置公钥的客户端都会直接无法建立连接，一般建议同时预置至少2个备用公钥，方便证书轮转。
  3. 这种方案很少被使用的核心原因是运维成本过高，之前HTTP标准中的HPKP（公钥钉扎规范）也因为容易引发大面积站点不可用的问题被废弃，绝大多数场景下优先选择信任系统根证书+域名校验的标准逻辑，或者对安全性要求高的场景使用证书钉扎的成熟实现，而非自己手写校验逻辑。

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