Пока не полный ответ, но некоторые идеи / направления:
Это изменение шифровщика не имеет смысла. Вы добавили термин TLS_DHE_RSA_WITH_AES_256_CBC_SHA
в стандартном формате RFC, также используемом в Java и некоторых других вещах, таких как Wireshark, но НЕ в формате, используемом OpenSSL; формат OpenSSL - DHE-RSA-AES256-SHA
который был / уже есть в вашем списке.
Также !EXPORT
здесь бесполезен; он удалит все наборы экспорта, которые были добавлены, но ни один из них не был добавлен, и предотвратит их дальнейшее добавление, но дальнейших спецификаций нет.
Некоторые ранние версии Java 7 SSL (JSSE), я точно не помню, какие, но, возможно, включая 7.03, имели свой список шифров по умолчанию в неправильном порядке, что может привести к выбору менее необходимого шифра, но ваш SSLHonorCipherOrder on
игнорирует заказ клиента, так что этого не может быть.
Последние версии httpd начали использовать по умолчанию более крупные группы DH (для DHE, которые вы предпочитаете), и это вызывает проблемы для Java 7 (и более ранних версий), по крайней мере, с использованием стандартных поставщиков шифрования. Но http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile говорит, что эти изменения были 2.4.7 и .10, поэтому .10 к .12 не должны вносить каких-либо дополнительных изменений, о которых я знаю. Запрос: у вас на самом деле DH 1024bit настроен как http://httpd.apache.org/docs/2.4/ssl/ssl_faq.html#javadh ?
Если это не так, мне нужно больше данных. Что-нибудь записывается в журнале httpd при возникновении проблемы? Можете ли вы получить более подробную информацию от клиента Java с проблемой, например, точное сообщение об исключении? (Это клиент, которым вы можете управлять самостоятельно, или он принадлежит другому человеку или людям?) Можете ли вы получить сетевой захват неудачной попытки с помощью Wireshark или tcpdump или аналогичного? Если все остальное терпит неудачу, может кто-то запустить клиент Java с -Djavax.net.debug=ssl
или эквивалентным, и получить (довольно большой) результирующий вывод?