问如何在TrustStore中处理别名

EN

user207421几乎是正确的。更确切地说：

当您作为客户端打开到服务器的SSL/TLS连接时，作为握手的一部分，服务器发送其包含自己证书的证书“链”，以及通常以“根”CA结尾的一个或多个链接CA (证书颁发机构)证书，该证书应该是可信的。有关完整的解释，请参见相邻的Stack https://security.stackexchange.com/questions/20803/how-does-ssl-work/。公共服务器通常使用由诸如Digicert、GoDaddy、LetsEncrypt/ISRG等公共CA颁发和签名的证书，这些证书已经在标准默认信任库(JRE/lib/security/cacerts文件中的Java )中，因此不需要任何操作。如果服务器使用来自非自有品牌或私有CA的证书，或者使用自签名证书(根本不使用CA )，那么(对于Java)必须将链中的某些证书添加到客户端信任库中，或者以其他方式重写；如果服务器证书是自签名的(服务器证书本身是一个链，没有相关的CA证书)，则只要求服务器证书是服务器证书。

Java/JSSE通过一个SSLContext实现这一点，其中包括一个TrustManager，更具体地说是一个从信任库初始化的X509ExtendedTrustManager。您可以从任何一组受信任的证书(甚至不需要来自文件)中显式地在代码中创建SSLContext，也可以使用默认上下文使用默认信任存储文件，除非被系统属性覆盖，否则默认为上面的文件名。

当接收到服务器证书链时，它将传递给上下文的TrustManager进行验证；(许多！)在普通链的每个级别或自签名证书的单个级别上，JSSE TrustManager都会查找具有相同主题和( Subject )PublicKey的锚证书，如果是这样，则使用它来验证证书链。请注意，如果使用Subject替代名称(请参见rfc5280和rfc2818 )，正常(CA发行)叶证书可以使用Subject空，但自签名证书不能使用，因为它具有Subject = Issuer和Issuer不能为空。不同实体(例如，不同服务器)的证书通常预期有不同的密钥，尽管单个实体可以具有相同密钥或不同密钥的多个证书，并且可能对应多个服务器名称和/或地址。

如果证书在一般情况下是有效的，那么对于某些TLS应用程序，特别是HTTPS，验证器还会检查它是否是正确的服务器，特别是Subject字段中的CommonName属性，或者如果存在的话，在Subject Alternative name扩展中的一个条目--对于公共CA，它至少在十年内与该URL中的主机DNS名称或IP加载项匹配。在较早版本的Java (通过6 IIRC)中，这不是在JSSE中完成的，而是在调用应用程序或库(如HttpsURLConnection )中完成的，后者作为遗留版本仍然可以选择使用自己的HostnameVerifier。

所有这一切都可以通过使用自定义TrustManager代替标准HttpClient来改变，而且像Apache HttpClient这样的一些东西可以有效地做到这一点，但是您可以在这里找到(太多的)答案和其他一些堆栈，它们建议您使用一个只接受任何证书的中性TrustManager来“解决”TLS错误，而不管它是否实际有效和正确，因此可以愉快地连接和发送敏感数据，或者接受来自任何设法拦截IP通信的攻击者的更改，而这在当今来说通常非常容易。

别名是直接访问证书的一种方式，但您的密钥库也有关于证书的其他信息。X.509证书有一个名为SAN (Subject Alternative name)的字段，该字段包含证书的DNS信息。当您试图连接到特定URL时，将在SAN中查找相应的DNS名称，并获取正确的证书。

我希望它能澄清您对于java不需要别名的疑虑。请放心，在这个过程中没有什么是随机的。