O alerta "SSL3_READ_BYTES: sslv3 alert bad certificate" indica que o SSL falhou

17

Durante a execução do comando abaixo, openssl s_client -host example.xyz -port 9093

Estou tendo o erro a seguir:

139810559764296:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:s3_pkt.c:1259:SSL alert number 42
39810559764296:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:

Mas no final eu recebo uma "Verify return code: 0 (ok)"mensagem.

Minha pergunta é o que significa o alerta acima e se o SSL foi realmente bem-sucedido. Muito obrigado pela ajuda antecipadamente.

SSL handshake has read 6648 bytes and written 354 bytes
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1.2
Cipher    : AES128-SHA
Session-ID: xx
Session-ID-ctx:
Master-Key: xx
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1475096098
Timeout   : 300 (sec)
**Verify return code: 0 (ok)**
kris433
fonte

Respostas:

25

"Falha no handshake" significa que o handshake falhou e não há conexão SSL / TLS. Você deve ver que opensslsai para o shell (ou CMD etc) e não espera que os dados de entrada sejam enviados ao servidor. "Verificar código de retorno 0" significa que não foi encontrado nenhum problema no certificado do servidor, porque não foi verificado ou porque foi verificado e estava em boas condições (tanto quanto as verificações do OpenSSL, o que não cobre tudo); neste caso, conhecendo o protocolo, podemos deduzir que o último caso se aplica.

Receber alertabad certificate (código 42) significa que o servidor exige que você se autentique com um certificado, e você não o fez, o que causou a falha do handshake. Algumas linhas antes da linha, SSL handshake has read ... and written ...você verá uma linha Acceptable client certificate CA namesgeralmente seguida por várias linhas que identificam CAs, possivelmente seguidas por uma linha iniciada Client Certificate Typese talvez algumas Requested Signature Algorithmsdependendo da versão do OpenSSL e do protocolo negociado.

Encontre um certificado emitido por uma CA na lista 'aceitável' ou, se estiver vazio, procure documentação no servidor ou sobre o servidor dizendo em quais CAs confia ou entre em contato com os operadores ou proprietários do servidor e pergunte a eles, além da chave privada correspondente , ambos no formato PEM e especifique-os com -cert $file -key $file; se você tiver os dois em um arquivo, como é possível com o PEM, use-cert $file. Se você os tiver em um formato diferente, especifique-o ou pesquise aqui e talvez superusuário e security.SX; já existem muitas perguntas e respostas sobre a conversão de vários formatos de certificado e chave privada. Se o seu certificado precisar de um certificado "em cadeia" ou "intermediário" (ou até mais de um) para ser verificado, como geralmente é o caso de um certificado de uma CA pública (versus uma interna), dependendo de como o servidor está configurado, s_clientrequer um truque: adicione os certificados da cadeia ao armazenamento confiável do sistema ou crie um armazenamento confiável local / temporário que contenha os certificados da CA. Você precisa verificar o servidor MAIS os certificados da cadeia que você precisa enviar.

Se você não possui esse certificado, é necessário obter um, que é uma pergunta diferente, que exige muito mais detalhes para responder, ou precisa encontrar uma maneira de se conectar ao servidor sem usar a autenticação de certificado; verifique novamente a documentação e / ou pergunte aos operadores / proprietários.

EDIT: Parece que, a partir do comentário, você pode ter a chave do cliente e a cadeia de certificados, bem como as âncoras do servidor em Java. Ao verificar, não vejo uma boa resposta existente cobrindo completamente esse caso, portanto, mesmo que isso provavelmente não procure bem:

# Assume Java keystore is type JKS (the default but not only possibility)
# named key.jks and the privatekey entry is named mykey (ditto)
# and the verify certs are in trust.jks in entries named trust1 trust2 etc.

# convert Java key entry to PKCS12 then PKCS12 to PEM files
keytool -importkeystore -srckeystore key.jks -destkeystore key.p12 -deststoretype pkcs12 -srcalias mykey 
openssl pkcs12 -in key.p12 -nocerts -out key.pem
openssl pkcs12 -in key.p12 -nokeys -clcerts -out cert.pem
openssl pkcs12 -in key.p12 -nokeys -cacerts -out chain.pem
# extract verify certs to individual PEM files
# (or if you 'uploaded' PEM files and still have them just use those)
keytool -keystore trust.jks -export -alias trust1 -rfc -file trust1.pem
keytool -keystore trust.jks -export -alias trust2 -rfc -file trust2.pem
... more if needed ...
# combine for s_client 
cat chain.pem trust*.pem >combined.pem
openssl s_client -connect host:port -key key.pem -cert cert.pem -CAfile combined.pem
dave_thompson_085
fonte
oi Dave; abaixo está o procedimento que seguimos. 1: Faça o upload da CA raiz e dos certificados intermediários no keystore. 2: Faça o upload do certificado Comodo assinado no keystore. 3: Carregue a CA raiz e os certificados intermediários no armazenamento confiável. 4: Copie os arquivos keystore e trustore para todos os nós do cluster (cassandra). Os nós usam SSL para comunicação e parecem trocar dados sem problemas. No entanto, quando executo o comando SSL acima mencionado, o problema aumenta.
precisa saber é o seguinte
@ kris433: que keystore é esse? O procedimento que você descreve soa como o do Java se (e somente se) ele já gerou uma chave privada para a qual você obteve (ed) o 'certificado Comodo assinado', embora, se você estiver usando uma instalação Java padrão, ele tenha um padrão armazenamento confiável que inclui o Comodo, portanto você não precisa alterar isso. O OpenSSL não usa nenhum keystore ou armazenamento confiável Java e, por padrão, não usa nenhum keystore, e é por isso que você precisa especificar arquivos com -cert [-key]. Se eu interpretei corretamente o seu comentário, consulte editar.
Dave_thompson_085 30/09/16
Muito obrigado Dave. Isso funcionou perfeitamente. Você salvou minha semana. Se você vier à Filadélfia, o bife com queijo e o Gelato estão comigo;). Mais uma vez obrigado.
precisa saber é o seguinte
@ kris433: de nada, mas a maneira oficial do StackExchange é aceitar uma resposta útil usando a marca de seleção, para que o sistema possa usar automaticamente essas informações na exibição de resultados para outros consultores; consulte o 'tour' que você deveria assistir ao visitar este site ou, mais especificamente, serverfault.com/help/someone-answers .
Dave_thompson_085
0

No meu caso, recebi esse erro quando a chave privada não correspondia ao certificado. Eu atualizei o certificado quando o meu expirou e precisava criar uma nova chave privada. No entanto, eu esqueci de referenciar isso no meu aplicativo. Quando apontei para a nova chave privada - esse erro desapareceu.

Blake
fonte