SSL routines:ssl3_read_bytes:tlsv13 alert certificate required

OpenSSL affiche « error:0A00045C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required:…:SSL alert number 116 » ; curl affiche « curl: (56) OpenSSL SSL_read: OpenSSL/<version>: error:0A00045C:SSL routines::tlsv13 alert certificate required, errno 0 ». En TLS 1.2, la même situation se termine généralement plutôt par handshake_failure (alerte 40).

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

Ce que cela signifie

Le serveur exige le TLS mutuel et le client a terminé un handshake TLS 1.3 sans présenter de certificat ; le serveur a donc répondu par l’alerte 116 (certificate_required). En TLS 1.3, le certificat client est vérifié alors que le client considère déjà le handshake comme terminé : c’est pourquoi des outils comme curl signalent cette erreur lors de la première lecture (code de sortie 56 de curl) plutôt que lors de la connexion.

Pourquoi cela se produit

• Aucun certificat client configuré

  fréquente

  Le client n’a reçu ni certificat ni clé (curl sans --cert, une bibliothèque sans son option de certificat client, une nouvelle machine sur laquelle le certificat n’est pas installé).

• Le client avait un certificat, mais émis par une AC non acceptée

  occasionnelle

  Les clients qui choisissent automatiquement un certificat (navigateurs, certaines bibliothèques) n’envoient qu’un certificat émis par une AC figurant dans la liste « acceptable CA names » du serveur ; si aucun ne correspond, ils n’envoient rien.

• Un proxy termine TLS avant le serveur mTLS

  occasionnelle

  Un répartiteur de charge ou un proxy placé entre le client et le serveur termine la première connexion TLS et ouvre la sienne, sans certificat client, vers le backend qui en exige un.

Comment corriger l’erreur

1. 1.

   Présenter le certificat client

   Transmettez le certificat et la clé privée au client (curl --cert/--key, s_client -cert/-key, l’option de certificat client de la bibliothèque 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.

   Lire les AC acceptées par le serveur

   openssl s_client liste les « Acceptable client certificate CA names » envoyés par le serveur ; votre certificat doit se rattacher à l’un d’eux.

   # 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.

   Vérifier le certificat lui-même

   Il doit être dans sa période de validité, émis par une AC acceptée, et son extendedKeyUsage (s’il est présent) doit inclure 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

← Parcourir toute la base de données des erreurs de signature