SSLHandshakeException：证书中的主机名不匹配

本文介绍了SSLHandshakeException：证书中的主机名不匹配的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我正在编写一个系统，必须向服务器（一个名为ARX的第三方程序，当前在开发期间在localhost上运行）发出一个多部分帖子，该系统具有自签名证书。

I am writing a system that must make a multipart post to a server (a third-party program called ARX that is currently running on localhost during the development) that has a self-signed certificate.

我试图找到它的证书，但只能找到三个不同的jks文件; server.jks ， servertrust.jks 和 serverca.jks 。

I tried to find its certificate, but can only find three different jks files; server.jks, servertrust.jks and serverca.jks.

我有尝试使用 System.setProperty（javax.ssl.trustStore，Program Files \\< path> \\ _jksfile） with每个jks文件。然而;当我这样做时，我收到以下错误： 证书中的主机名不匹配：< localhost>！=< 9200416 arx sa cert> 。

I have tried to use the System.setProperty("javax.ssl.trustStore", "Program Files\\<path>\\jksfile") with each of the jks files. However; when I do, I get the following error: hostname in certificate didn't match: < localhost> != <9200416 arx sa cert>.

我在stackoverflow上浏览了大量类似的问题，试图了解如何获取解决这个问题，但我无法解决我的问题。

I have browsed plenty of similar questions here on stackoverflow to try and get an idea on how to fix this, but I have not been able to resolve my problem.

有什么建议吗？非常感谢所有帮助。

Any suggestions? All help is very much appreciated.

推荐答案

证书本身似乎是可信的，所以你的 javax。 ssl.trustStore 设置工作，但主机名不匹配。

The certificate itself seems trusted, so your javax.ssl.trustStore setting worked, but the host name doesn't match.

主机名匹配是根据客户端识别主机的方式完成的它试图访问。如果它试图访问 https：// localhost / ，则证书必须对 localhost 有效。如果它正在尝试访问 https：//something-else.example ，则证书必须对某事有效 - else.example ，即使 localhost 和 something-else.example 也是同一台机器。

Host name matching is done according to how the client identifies the host it's trying to access. If it's trying to access localhost/, then the certificate must be valid for localhost. If it's trying to access something-else.example, then the certificate must be valid for something-else.example, even if localhost and something-else.example are one and the same machine.

证书中的标识符应该是主题备用名称扩展名，如果没有，则在主题专有名称的公用名（CN）中。

The identifier in the certificate should be in a Subject Alternative Name extension or, failing that, in the Common Name (CN) of the Subject Distinguished Name.

在这里，看起来你的证书只有CN，而且这个CN用于 9200416 arx sa cert 。

Here, it looks like your certificate only has a CN and that this CN is for "9200416 arx sa cert".

原则上，您可以通过在开发计算机上使用 hosts 文件将该名称指向localhost来解决该问题。但是，该名称包含空格，因此它甚至不是有效的主机名。

In principle, you could address that problem by having that name point to your localhost using your hosts file on your development machine. However, that name contains spaces, so it's not even a valid host name.

您可以获得以下几种选择：

You get a couple of options:

重新生成该应用程序的证书，以便它使用正确的主机名（如果需要，可以调整 hosts 文件）。这可能只是在设置时出错。也许有人只是用空格填充了这个名字，却没有意识到它会像证书中那样使用（例如，OpenSSL有时称之为你的名字）。

Re-generate the certificate for that application, so that it uses a proper host name (and if required, adapt your hosts file). This might just be a mistake when it was set up. Maybe someone just filled in that name with spaces, without realising it would be used like that in the cert (OpenSSL sometimes calls this "Your Name", for example).

错误的选择是更改您的应用程序以忽略主机名验证。这是一个糟糕的选择，因为这会使您的代码对MITM攻击开放。当然，从localhost到localhost几乎没什么问题，但这就是代码中保留的那种代码。因为它可以防止发生错误（否则会出现预期的错误），所以很可能会忘记从生产代码中删除它。即使在具有良好开发实践的地方，也很容易错过。这是一个糟糕的选择（只是为了强调这一点）。

A bad option would be to change your application to ignore host name validation. This is a bad option because this leaves your code open to MITM attacks. Of course, this barely matters from localhost to localhost, but that's the kind of code that stays in the code. Because it will prevent an error (that would otherwise be an intended error) from happening, it's likely that removing this from production code will be forgotten. Even in places with good development practices, it's easy to miss. That's a bad option (just to stress this point).

稍微好一点的变体是拥有一个自定义主机名验证器来检查它找到的名称是你知道的名字是在证书中。

A slightly better variant for this would be to have a custom host name verifier that checks the name it finds is the name you know to be in the certificate.