Как должна выполняться проверка имени хоста, определено в RFC 6125 , который является довольно новым и обобщает практику для всех протоколов, и заменяет RFC 2818 , который был специфичен для HTTPS.,(Я даже не уверен, что Java 7 использует RFC 6125, что может быть слишком новым для этого.)
С RFC 2818 (Раздел 3.1) :
Если присутствует расширение subjectAltName типа dNSName, оно ДОЛЖНО использоваться в качестве идентификатора.В противном случае ДОЛЖНО использоваться (наиболее определенное) поле общего имени в поле «Тема» сертификата.Хотя использование общего имени является существующей практикой, оно устарело, и сертификационным органам рекомендуется вместо этого использовать dNSName.
[...]
В некоторых случаях указывается URIкак IP-адрес, а не имя хоста.В этом случае iPAddress subjectAltName должно присутствовать в сертификате и должно точно соответствовать IP-адресу в URI.
По сути, конкретная проблема возникает из-за того, что вы используете IP-адресав вашем CN, а не имя хоста.Некоторые браузеры могут работать, потому что не все инструменты строго следуют этой спецификации, в частности потому, что «наиболее специфичный» в RFC 2818 не определен четко (см. Обсуждения в RFC 6215).
Если вы используете keytool, с Java 7, keytool имеет возможность включить альтернативное имя субъекта (см. Таблицу в документации для -ext): вы можете использовать -ext san=dns:www.example.com или -ext san=ip:10.0.0.1.
РЕДАКТИРОВАТЬ:
Вы можете запросить SAN в OpenSSL, изменив openssl.cnf (он выберет копию в текущем каталоге, если вы не хотите редактировать глобальныйКонфигурация, насколько я помню, или вы можете выбрать явное местоположение, используя переменную окружения OPENSSL_CONF.
Установите следующие параметры (сначала найдите соответствующие разделы в скобках):
[req]
req_extensions = v3_req
[ v3_req ]
subjectAltName=IP:10.0.0.1
# or subjectAltName=DNS:www.example.com
Есть также хороший прием для использования переменной окружения (вместо того, чтобы фиксировать ее в файле конфигурации): http://www.crsr.net/Notes/SSL.html