Сбой проверки SSL-сертификата в Java - но работает везде - PullRequest
1 голос
/ 30 марта 2012

При доступе к нашему собственному веб-сайту в коде Java возникает исключение:

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching en.greatfire.org found.

Однако при доступе к нему в браузере или использовании curl проблем нет.

Любая идеяпочему это может быть?Если есть какие-то проблемы с нашими сертификатами, но браузеры как-то более снисходительны, мы бы хотели это исправить.

Не уверены, что это связано, у нас есть отдельные сертификаты для greatfire.org и en.greatfire.org.

Java-код, который выдает вышеуказанное исключение:

    URL url = new URL("https://en.greatfire.org");
    HttpURLConnection conn = (HttpURLConnection)url.openConnection();
    System.out.println("Response code: " + conn.getResponseCode());
    for(Entry<String, List<String>> header : conn.getHeaderFields().entrySet()) {
        for(String headerValue : header.getValue()) {
            System.out.println(header.getKey() + ": " + headerValue);
        }
    }

1 Ответ

3 голосов
/ 30 марта 2012

RFC 2818 (спецификация HTTPS) говорит:

Если присутствует расширение subjectAltName типа dNSName, это ДОЛЖНО использоваться в качестве идентификатора.В противном случае ДОЛЖНО использоваться (наиболее определенное) поле общего имени в поле «Тема» сертификата.Хотя использование общего имени является существующей практикой, оно устарело, и сертификационным органам рекомендуется вместо этого использовать dNSName.

По сути, если вообще нет расширения SAN, ему следует использовать CNв DN субъекта, в противном случае он должен использовать только записи SAN.(Более поздний RFC 6125 также идет по этим направлениям.)

Звучит так, как будто в вашем сертификате есть одна или несколько записей SAN, но ни одна из них не подходит для имени хоста, за которым вы следите (что можеттолько CN).

Java достаточно строга в этом вопросе, в том числе в отношении типа записи в SAN (например, для IP-адресов ), но некоторые браузеры более снисходительны.Я бы рекомендовал исправить сертификат, указав все имена хостов (или IP-адреса), которые вы хотите использовать, в альтернативных именах субъектов.

РЕДАКТИРОВАТЬ:

При этом, у вас есть пара связанных проблем.

Сертификат, который вы обслуживаете для en.greatfire.org, содержит записи SAN для en.greatfire.org и www.en.greatfire.org, что нормально и должно работать.

Однако, если вы используете клиент, который не поддерживает расширение индикации имени сервера SSL / TLS (например, openssl s_client -showcerts -connect en.greatfire.org:443 или Java 6 в этом отношении), вы получите сертификат для greatfire.org и www.greatfire.org.

Это двойная проблема, потому что:

  • Вы настроили SNI в своем браузере, который не поддерживается Java 6, любой версией IE на XP или Android под версией 3.0 (ивозможно, несколько других).
  • greatfire.org даже не разрешается на той же машине.

Похоже, один из ваших сертификатов в порядке, но клиенты, которые этого не делаютподдержка SNI не увидит.Если вы хотите избежать этой проблемы, получите сертификат, действительный для всех 4 имен (4 записи SAN), и укажите greatfire.org на правильный IP-адрес.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...