Provavelmente não é uma resposta ainda, mas mais do que posso tornar legível nos comentários:
Esse código de erro (e string) é sobre uma chave pública Diffie-Hellman . A menos que você esteja usando DH estática, o que seria muito incomum - eu nunca vi um problema de CA público em um certificado DH - esta deve ser a chave DH efêmera do cliente para um ciphersuite DHE. Para que seja inválido sugere algo bastante estranho na pilha SSL do cliente, um "ataque" (ou pelo menos dano) na sessão, ou os parâmetros DH em seu servidor ficarão em xeque - tudo isso não deveria acontecer. Se o cliente afirma 'cert autoassinado' e você não está usando um, esse é um problema diferente que não deveria estar relacionado, mas pode ser através de algum bug estranho.
O cliente parece ser algo em PHP, que eu não estou familiarizado, mas eu acho que é provável que usando openssl para fazer conexões SSL de cliente (neste caso, para você) (assim como o nginx AFAIK usa o openssl no lado do servidor). Se você configurou seu servidor para fornecer uma cadeia completa de certificados, incluindo root, e o cliente openssl não possui essa raiz no armazenamento confiável que está usando (que pode ser configurável), ele pode confundir o relatório 'certificado autoassinado' em vez de uma 'raiz não confiável' mais exata.
Se eu estiver certo, é openssl, posso (você pergunta) as pessoas do cliente tentam uma conexão com você usando a linha de comando openssl s_client ,
com o mesmo truststore que seu programa está usando, e a mesma lista de cifras (possivelmente padrão) -
e veja se isso causa algum erro e, em caso afirmativo, a informação de erro (muito mais detalhada) s_client dá?
Em outras palavras, o comando seria algo como
openssl s_client -connect $yourhost:$yourport -CAfile $file_if_any -CApath $dir_if_any -cipher $string_if_any
(Se ele se conectar, apenas controle-D para sair sem enviar nada.)
Se s_client disser algo como verify error: ... self-signed , eles deverão corrigir o armazenamento confiável que estão usando para incluir
o certificado raiz da cadeia que você está usando. (Isso pode significar mudar para usar um diferente
truststore, se eles não podem ou não querem modificar o que eles usam atualmente.)
Entretanto, o que (se alguma coisa) está configurado no seu servidor para ssl_dhparam ?
Tente openssl dhparam -check -noout nesse arquivo apenas no caso, embora qualquer coisa
errado deveria ter falhado em um passo anterior no aperto de mão.
Quando outras conexões (cliente) são bem-sucedidas, você pode verificar se elas negociam DHE ou não?
Lembre-se de que um certificado RSA, o mais comum, de longe, pode suportar cifras simples RSA DHE-RSA e ECDHE-RSA.
Alguns clientes podem exibir a codificação selecionada, em especial a maioria dos navegadores, se o servidor aceitar solicitações https do navegador.
Eu mesmo não uso o nginx, mas o link indica que ele pode registrar isso.
s_client sempre informa a cifra, juntamente com muitas outras coisas.
Se o problema ainda ocorrer, você pode, ou eles ou alguém, obter uma captura de rede - usando o wireshark / tshark, tcpdump, ou similar - de uma conexão com falha? Isso confirmará o ciphersuite e outras opções usadas, e mostrará o DHE troca até o fracasso, que deveria pelo menos diminuir o problema. A maneira mais fácil de olhar (IMO) é exibir em wireshark (mesmo se você capturou com outra coisa), expanda o ServerHello e obtenha o CipherSuite, e expanda o ServerKeyExchange e o ClientKeyExchange e obtenha todos os detalhes.