如何处理 TrustStore 中的别名
How to handle alias in TrustStore
我是运行Java进程（微服务）和JVM参数中配置的trustStore。如果微服务需要连接外部 URL 需要在 trustStore 中导入证书。
Example:
example.co.uk -> examplecouk as alias in trustStore
example.com -> examplecom as alias in trustStore
example.in -> examplein as alias in trustStore
Java 如何知道要从 trustStore 中为特定端点选择哪些证书和别名，因为我不 pass/mention JVM 参数中的别名？是随机挑选的吗？
别名是一种直接访问证书的方法，但您的密钥库还有关于证书的其他信息。 X.509 证书有一个名为 SAN（Subject Alternative name）的字段，其中包含证书的 DNS 信息。当您尝试连接到特定 URL 时，会在密钥库中查找 SAN 中相应的 DNS 名称，并选择正确的证书。
我希望它能澄清您对 java 不要求别名的疑虑。放心，这个过程没有任何随机性。
user207421 几乎是正确的。更准确地说：
当您作为客户端打开与服务器的 SSL/TLS 连接时，作为握手的一部分，服务器会发送其证书 'chain'，其中包含自己的证书，通常还有一个或多个链接的 CA（证书Authority) 证书以 'root' CA 结尾，应该是可信的。请参阅相邻的 Stack https://security.stackexchange.com/questions/20803/how-does-ssl-work/ 以获得史诗般的完整解释。 Public 服务器通常使用由 public CA 颁发和签名的证书，例如 Digicert、GoDaddy、LetsEncrypt/ISRG，它们已经在标准默认信任库中（对于文件 Java =10=]) 所以不需要任何操作。如果服务器使用来自 off-brand 或私有 CA 的证书，或 self-signed 证书（根本没有来自任何 CA），则（对于 Java）some 链中的证书必须添加到客户端信任库，否则将被覆盖；在服务器证书是 self-signed 的情况下（它本身是一个链并且没有相关的 CA 证书），这只需要是 server 证书。
Java/JSSE 通过一个 SSLContext 实现这个，其中包含一个 TrustManager，更具体地说是一个 X509ExtendedTrustManager，它是 initialized 来自信任库。您可以从任何一组受信任的证书（甚至不需要来自文件）的代码中显式创建 SSLContext，或者使用使用默认信任库文件的默认上下文，默认为上面的文件名除非被系统覆盖 属性。
收到服务器证书链后，会将其传递给上下文的 TrustManager 进行验证；在（许多！）其他检查中，在普通链的每个级别，或 self-signed 证书的单个级别，JSSE TrustManager 查找具有相同主题和 (Subject)Public 的锚证书密钥，如果是，则使用它来验证证书链。请注意，如果使用 Subject Alternative Name 代替，则普通 (CA-issued) 叶证书的 Subject 可以为空——请参阅 rfc5280 和 rfc2818——但 self-signed 证书不能，因为它有 Subject = Issuer 和 Issuer必须 而不是 为空。不同实体（例如不同的服务器）的证书通常应具有不同的密钥，尽管单个实体可以具有多个具有相同密钥或不同密钥的证书，并且可能对应于多个服务器名称 and/or 地址。
如果证书通常被确定为有效，对于 一些 TLS 应用程序，特别是 HTTPS，验证器 also 检查它是否适用于正确的服务器，特别是 Subject 字段中的 CommonName 属性，或者 Subject Alternative Name 扩展中的条目（如果存在）——对于 public CA 至少十年，它与主机 DNS 名称或 IP 地址相匹配在 URL。在 Java 的旧版本（通过 6 IIRC）中，这不是在 JSSE 中完成的，而是在调用应用程序或库中完成的，例如 HttpsURLConnection，它作为遗留物仍然可以选择使用它自己的 HostnameVerifier 而不是。
所有这些都可以通过使用自定义 TrustManager 代替标准来更改，Apache HttpClient 之类的东西可以有效地做到这一点，但您会找到（太多）答案这里和其他一些 Stacks 通过使用只接受任何证书的绝育 TrustManager 向您推荐 'solve' TLS 错误，无论它是否实际有效和正确，因此愉快地连接并将敏感数据发送到，或接受任何设法拦截 IP 流量的攻击者的更改，这在当今通常很容易。
我是运行Java进程（微服务）和JVM参数中配置的trustStore。如果微服务需要连接外部 URL 需要在 trustStore 中导入证书。
Example:
example.co.uk -> examplecouk as alias in trustStore
example.com -> examplecom as alias in trustStore
example.in -> examplein as alias in trustStore
Java 如何知道要从 trustStore 中为特定端点选择哪些证书和别名，因为我不 pass/mention JVM 参数中的别名？是随机挑选的吗？
别名是一种直接访问证书的方法，但您的密钥库还有关于证书的其他信息。 X.509 证书有一个名为 SAN（Subject Alternative name）的字段，其中包含证书的 DNS 信息。当您尝试连接到特定 URL 时，会在密钥库中查找 SAN 中相应的 DNS 名称，并选择正确的证书。
我希望它能澄清您对 java 不要求别名的疑虑。放心，这个过程没有任何随机性。
user207421 几乎是正确的。更准确地说：
当您作为客户端打开与服务器的 SSL/TLS 连接时，作为握手的一部分，服务器会发送其证书 'chain'，其中包含自己的证书，通常还有一个或多个链接的 CA（证书Authority) 证书以 'root' CA 结尾，应该是可信的。请参阅相邻的 Stack https://security.stackexchange.com/questions/20803/how-does-ssl-work/ 以获得史诗般的完整解释。 Public 服务器通常使用由 public CA 颁发和签名的证书，例如 Digicert、GoDaddy、LetsEncrypt/ISRG，它们已经在标准默认信任库中（对于文件 Java =10=]) 所以不需要任何操作。如果服务器使用来自 off-brand 或私有 CA 的证书，或 self-signed 证书（根本没有来自任何 CA），则（对于 Java）some 链中的证书必须添加到客户端信任库，否则将被覆盖；在服务器证书是 self-signed 的情况下（它本身是一个链并且没有相关的 CA 证书），这只需要是 server 证书。
Java/JSSE 通过一个 SSLContext 实现这个，其中包含一个 TrustManager，更具体地说是一个 X509ExtendedTrustManager，它是 initialized 来自信任库。您可以从任何一组受信任的证书（甚至不需要来自文件）的代码中显式创建 SSLContext，或者使用使用默认信任库文件的默认上下文，默认为上面的文件名除非被系统覆盖 属性。
收到服务器证书链后，会将其传递给上下文的 TrustManager 进行验证；在（许多！）其他检查中，在普通链的每个级别，或 self-signed 证书的单个级别，JSSE TrustManager 查找具有相同主题和 (Subject)Public 的锚证书密钥，如果是，则使用它来验证证书链。请注意，如果使用 Subject Alternative Name 代替，则普通 (CA-issued) 叶证书的 Subject 可以为空——请参阅 rfc5280 和 rfc2818——但 self-signed 证书不能，因为它有 Subject = Issuer 和 Issuer必须 而不是 为空。不同实体（例如不同的服务器）的证书通常应具有不同的密钥，尽管单个实体可以具有多个具有相同密钥或不同密钥的证书，并且可能对应于多个服务器名称 and/or 地址。
如果证书通常被确定为有效，对于 一些 TLS 应用程序，特别是 HTTPS，验证器 also 检查它是否适用于正确的服务器，特别是 Subject 字段中的 CommonName 属性，或者 Subject Alternative Name 扩展中的条目（如果存在）——对于 public CA 至少十年，它与主机 DNS 名称或 IP 地址相匹配在 URL。在 Java 的旧版本（通过 6 IIRC）中，这不是在 JSSE 中完成的，而是在调用应用程序或库中完成的，例如 HttpsURLConnection，它作为遗留物仍然可以选择使用它自己的 HostnameVerifier 而不是。
所有这些都可以通过使用自定义 TrustManager 代替标准来更改，Apache HttpClient 之类的东西可以有效地做到这一点，但您会找到（太多）答案这里和其他一些 Stacks 通过使用只接受任何证书的绝育 TrustManager 向您推荐 'solve' TLS 错误，无论它是否实际有效和正确，因此愉快地连接并将敏感数据发送到，或接受任何设法拦截 IP 流量的攻击者的更改，这在当今通常很容易。