SSL routines:ssl3_read_bytes:tlsv13 alert certificate required

OpenSSL imprime «error:0A00045C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required:…:SSL alert number 116»; curl imprime «curl: (56) OpenSSL SSL_read: OpenSSL/<version>: error:0A00045C:SSL routines::tlsv13 alert certificate required, errno 0». Con TLS 1.2, la misma situación suele terminar en cambio con handshake_failure (alerta 40).

OpenSSL (client side) — TLS 1.3 alert 116 (certificate_required) from a mutual-TLS server

Qué significa

El servidor exige TLS mutuo y el cliente terminó un handshake TLS 1.3 sin presentar un certificado, así que el servidor respondió con la alerta 116 (certificate_required). En TLS 1.3, el certificado de cliente se comprueba cuando el cliente ya da por completado el handshake; por eso herramientas como curl notifican el error durante la primera lectura (código de salida 56 de curl) y no durante la conexión.

Por qué ocurre

• No hay ningún certificado de cliente configurado

  frecuente

  Al cliente no se le dio un certificado y una clave (curl sin --cert, una biblioteca sin su opción de certificado de cliente, un equipo nuevo sin el certificado instalado).

• El cliente tenía un certificado, pero no de una CA aceptada

  ocasional

  Los clientes que eligen un certificado automáticamente (navegadores, algunas bibliotecas) solo envían uno emitido por una CA de la lista «acceptable CA names» del servidor; si ninguno coincide, no envían nada.

• Un proxy termina TLS antes del servidor mTLS

  ocasional

  Un balanceador de carga o un proxy entre el cliente y el servidor termina la primera conexión TLS y abre la suya propia, sin certificado de cliente, hacia el backend que lo exige.

Cómo solucionarlo

1. 1.

   Presentar el certificado de cliente

   Pasa el certificado y la clave privada al cliente (curl --cert/--key, s_client -cert/-key, la opción de certificado de cliente de la biblioteca HTTP).

   openssl s_client -connect mtls.example.com:443 -servername mtls.example.com \
     -cert client.pem -key client.key -brief </dev/null
   curl --cert client.pem --key client.key https://mtls.example.com/

2. 2.

   Leer las CA que acepta el servidor

   openssl s_client muestra la lista «Acceptable client certificate CA names» que envía el servidor; la cadena de tu certificado debe llegar a una de ellas.

   # Which CAs does the server accept client certificates from?
   openssl s_client -connect mtls.example.com:443 -servername mtls.example.com </dev/null 2>/dev/null \
     | sed -n '/Acceptable client certificate CA names/,/^Requested/p'

3. 3.

   Comprobar el propio certificado

   Debe estar dentro de su período de validez y haberlo emitido una CA aceptada, y su extendedKeyUsage (si existe) debe incluir clientAuth.

   # The client certificate must be valid, issued by an accepted CA, and allow clientAuth
   openssl x509 -in client.pem -noout -subject -issuer -dates -ext extendedKeyUsage

← Explorar toda la base de datos de errores de firma