¿Es la alerta "SSL3_READ_BYTES: certificado de alerta sslv3 incorrecto" que indica que el SSL falló

17

Mientras ejecuta el siguiente comando openssl s_client -host example.xyz -port 9093

Obtuve el siguiente error:

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:

Pero al final recibo un "Verify return code: 0 (ok)"mensaje.

Mi pregunta es qué significa la alerta anterior y si el SSL fue exitoso. Muchas gracias por la ayuda de antemano.

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
fuente

Respuestas:

25

"Fallo de protocolo de enlace" significa que el protocolo de enlace falló y no hay conexión SSL / TLS. Debería ver que opensslsale al shell (o CMD, etc.) y no espera a que los datos de entrada se envíen al servidor. "Verificar el código de retorno 0" significa que no se encontró ningún problema en el certificado del servidor, ya sea porque no se verificó en absoluto o porque se verificó y era bueno (en lo que respecta a las verificaciones de OpenSSL, que no cubre todo); en este caso al conocer el protocolo podemos deducir que se aplica el último caso.

Recibir alertabad certificate (código 42) significa que el servidor exige que se autentique con un certificado, y no lo hizo, y eso provocó la falla del apretón de manos. Unas pocas líneas antes de la línea SSL handshake has read ... and written ...debería ver una línea Acceptable client certificate CA namesgeneralmente seguida de varias líneas que identifican a las CA, posiblemente seguidas por un comienzo de línea Client Certificate Typesy tal vez algunas sobre la base Requested Signature Algorithmsde su versión de OpenSSL y el protocolo negociado.

Encuentre un certificado emitido por una CA en la lista 'aceptable', o si estaba vacío, busque documentación en el servidor o sobre el servidor que indique en qué CA confía o comuníquese con los operadores o propietarios del servidor y pregúnteles, además de la clave privada correspondiente . en formato PEM y especifíquelos con -cert $file -key $file; si tiene ambos en un archivo, como es posible con PEM, simplemente use-cert $file. Si los tiene en un formato diferente, especifíquelo o busque aquí y quizás superusuario y seguridad. SX; Ya hay muchas preguntas y respuestas sobre la conversión de varios formatos de certificado y clave privada. Si su certificado necesita un certificado de "cadena" o "intermedio" (o incluso más de uno) para ser verificado, como suele ser el caso de un certificado de una CA pública (versus uno interno) dependiendo de cómo esté configurado el servidor, s_clientrequiere un truco: agregue los certificados de cadena al almacén de confianza de su sistema o cree un almacén de confianza local / temporal que contenga los certificados de CA que necesita para verificar el servidor MÁS los certificados de cadena que necesita enviar.

Si no tiene dicho certificado, necesita obtener uno, que es una pregunta diferente que requiere muchos más detalles para responder, o necesita encontrar una manera de conectarse al servidor sin usar la autenticación de certificado; nuevamente verifique la documentación y / o pregunte a los operadores / propietarios.

EDITAR: Parece que, por comentario, puede tener la clave del cliente y la cadena de certificados, así como los anclajes del servidor en Java. Al verificar, no veo una buena respuesta existente que cubra completamente ese caso, por lo que a pesar de que esto probablemente no busque bien:

# 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
fuente
Hola Dave; a continuación se muestra el procedimiento que seguimos. 1: cargue la CA raíz y los certificados intermedios en el almacén de claves. 2: Cargue el certificado de Comodo firmado en el almacén de claves. 3: Cargue la CA raíz y los certificados intermedios en el almacén de confianza. 4: Copie el almacén de claves y los archivos de custodia en cada nodo del clúster (cassandra) Los nodos usan SSL para la comunicación, y parecen intercambiar datos sin problemas. Sin embargo, cuando ejecuto el comando SSL mencionado anteriormente, surge el problema.
kris433
@ kris433: ¿qué almacén de claves es ese? El procedimiento que describe suena como el de Java si (y solo si) ya ha generado una clave privada para la que obtiene (editado) el 'certificado Comodo firmado', aunque si está utilizando una instalación estándar de Java, tiene un valor predeterminado Truststore que incluye Comodo, por lo que no debería necesitar cambiar eso. OpenSSL no utiliza ningún almacén de claves o almacén de confianza de Java y, de forma predeterminada, no utiliza ningún almacén de claves, por lo que debe especificar los archivos con -cert [-key]. Si he interpretado correctamente su comentario, vea editar.
dave_thompson_085
Muchas gracias Dave. Esto funcionó perfectamente. Me salvaste la semana. Si alguna vez vienes a Filadelfia, el filete de queso y el helado están sobre mí;). Gracias de nuevo.
kris433
@ kris433: de nada, pero la forma oficial de StackExchange es aceptar una respuesta útil utilizando la marca de verificación, para que el sistema pueda usar automáticamente esta información para mostrar los resultados a otras consultas; vea el 'recorrido' que se suponía que debía ver cuando visitó este sitio, o más específicamente serverfault.com/help/someone-answers .
dave_thompson_085
0

En mi caso, recibí este error cuando la clave privada no coincidía con el certificado. Había actualizado el certificado cuando expiró el mío y necesitaba crear una nueva clave privada. Sin embargo, olvidé hacer referencia a eso en mi aplicación. Cuando señalé la nueva clave privada, este error desapareció.

Blake
fuente