我正在运行Java进程（微服务）和JVM参数中配置的trustStore。如果微服务需要连接需要将证书导入truststore的外部URL。
Example:
example.co.uk -> examplecouk as alias in trustStore
example.com -> examplecom as alias in trustStore
example.in -> examplein as alias in trustStore
当我不通过/提及JVM参数中的别名时，Java如何知道要从trustStore中为特定端点选择哪些证书和别名？它是随机选择的吗？
答案 0 :(得分：2)
user207421几乎正确。更确切地说：
当您作为客户端打开与服务器的SSL / TLS连接时，作为握手的一部分，服务器会发送其证书“链”，其中包含自己的证书，以及通常以一个或多个结尾的链接的CA（证书颁发机构）证书应该被信任的“根”CA。请参阅相邻的堆栈https://security.stackexchange.com/questions/20803/how-does-ssl-work/，以获取完整的解释。公共服务器通常使用由公共CA（例如Digicert，GoDaddy，LetsEncrypt / ISRG）颁发并签名的证书，这些证书已经在标准默认信任库中（对于Java，文件JRE/lib/security/cacerts中已存在），因此无需采取任何措施。如果服务器使用来自非品牌或私有CA的证书，或者使用自签名证书（完全没有CA），则必须在链中添加（对于Java） some 证书客户信任库，或以其他方式被覆盖；如果服务器证书是自签名的（仅是一个链且没有相关的CA证书），则仅需将其作为 server 证书。
Java / JSSE通过SSLContext来实现此目的，该TrustManager包含X509ExtendedTrustManager，更具体地说是SSLContext，它是从信任库进行初始化的。您可以通过任何一组受信任的证书（甚至不需要来自文件）在代码中显式创建一个HttpsURLConnection，或者使用默认上下文，该上下文使用默认的信任库文件，默认情况下为上述文件名除非被系统属性覆盖。
收到服务器证书链后，将其传递到上下文的TrustManager进行验证；在（许多！）其他检查中，在正常链的每个级别或自签名证书的单个级别中，JSSE TrustManager都将查找具有相同Subject和（Subject）PublicKey的锚证书，如果使用，则使用它来验证证书链。请注意，如果改为使用普通主题（CA颁发）的叶子证书，则可以使用主题备用名称代替主题-请参阅rfc5280和rfc2818-但是自签名证书不能，因为它具有主题=发行者，并且发行者必须不是为空。尽管单个实体可以具有带有相同密钥或不同密钥的多个证书，并且可能对应于多个服务器名称和/或地址，但是通常期望用于不同实体（例如，不同服务器）的证书具有不同的密钥。
如果通常确定该证书有效，那么对于某些 TLS应用程序，尤其是HTTPS，验证器还将检查它是否适用于正确的服务器，特别是CommonName属性（在“主题”字段中）或“主题备用名称”扩展名中的条目（如果存在）（对于公共CA至少十年），它与URL中的主机DNS名称或IP地址匹配。在较旧的Java版本（通过6 IIRC）中，这不是在JSSE中完成的，而是在调用应用程序或库中完成的，例如HostnameVerifier，作为遗留项，仍然可以选择使用自己的{{ 1}}。
可以通过使用自定义TrustManager代替标准的HttpClient来更改所有这些内容，而Apache TrustManager之类的某些方法确实可以这样做，但是您会在此处找到（太多）答案，并且其他一些Stacks则建议您使用绝密的5000ms“解决” TLS错误，该绝密的spring.cloud.stream.rabbit.bindings.<channelName>.consumer会接受任何证书，而不论其是否实际有效和正确，从而可以愉快地连接敏感数据并向其中发送敏感数据或从中接受更改任何设法拦截IP流量的攻击者，如今这通常很容易。
答案 1 :(得分：0)
别名是一种直接访问证书的方法，但是您的密钥库也包含有关证书的其他信息。 X.509证书具有一个称为SAN（主题备用名称）的字段，其中包含证书的DNS信息。当您尝试连接到特定的URL时，将在SAN中的密钥库中查找相应的DNS名称，并获取正确的证书。
我希望它可以澄清您对Java是否不要求别名的疑问。请放心，在此过程中不会出现随机情况。