Não é uma resposta completa ainda, mas algumas ideias / orientações:
Essa alteração da lista de codificação é sem sentido . O termo que você adicionou TLS_DHE_RSA_WITH_AES_256_CBC_SHA está no formato RFC padrão, também usado por Java
e algumas outras coisas como o Wireshark, mas NÃO o formato usado pelo OpenSSL;
o formato OpenSSL é DHE-RSA-AES256-SHA , que já estava na sua lista.
Além disso, !EXPORT é inútil aqui; removeria quaisquer suítes de exportação que tivessem
foi adicionado, mas nenhum foi, e evitaria qualquer especificação adicional de
adicionando-os de volta, mas não há mais especificações.
Algumas das primeiras versões do Java 7 SSL (JSSE), não me lembro exatamente qual, mas provavelmente incluindo o 7.03, tem sua lista de cifras padrão
na ordem errada, o que poderia resultar na seleção de um ciphersuite mais pobre do que o necessário, mas o seu SSLHonorCipherOrder on ignora a ordem do cliente, então não pode ser isso.
As versões recentes do httpd começaram a padronizar grupos DH maiores (para DHE, que você está preferindo), e isso causa problemas para o Java 7 (e anteriores), pelo menos, usando seus provedores de criptografia padrão. Mas o link diz que essas alterações foram 2.4.7 e .10, portanto, .10 para. 12 não deve fazer mais nenhuma mudança que eu saiba. Consulta: Você tem DH 1024bit configurado como link sugere?
Se não for isso, precisarei de mais dados . Existe alguma coisa escrita no (s) log (s) httpd (s) quando o problema ocorre? Você pode obter mais detalhes do cliente Java com o problema, como uma mensagem de exceção exata? (Esse cliente pode ser executado por você mesmo ou pertence a outra pessoa ou pessoas?) Você pode obter uma captura de rede de uma tentativa malsucedida com Wireshark ou tcpdump ou semelhante? Se tudo mais falhar, alguém pode executar o cliente Java com -Djavax.net.debug=ssl ou equivalente e obter a saída resultante (bastante volumosa)?