SSL routines:ssl3_read_bytes:tlsv13 alert certificate required

OpenSSL gibt „error:0A00045C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required:…:SSL alert number 116“ aus; curl gibt „curl: (56) OpenSSL SSL_read: OpenSSL/<version>: error:0A00045C:SSL routines::tlsv13 alert certificate required, errno 0“ aus. Bei TLS 1.2 endet dieselbe Situation stattdessen meist mit handshake_failure (Alert 40).

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

Was der Fehler bedeutet

Der Server verlangt Mutual TLS, und der Client hat einen Handshake mit TLS 1.3 abgeschlossen, ohne ein Zertifikat vorzulegen; deshalb hat der Server mit dem Alert 116 (certificate_required) geantwortet. In TLS 1.3 wird das Client-Zertifikat erst geprüft, wenn der Client den Handshake bereits für abgeschlossen hält. Deshalb melden Tools wie curl den Fehler beim ersten Lesen (curl-Exit-Code 56) und nicht schon beim Verbindungsaufbau.

Warum der Fehler auftritt

• Kein Client-Zertifikat konfiguriert

  häufig

  Dem Client wurden kein Zertifikat und kein Schlüssel übergeben (curl ohne --cert, eine Bibliothek ohne ihre Option für das Client-Zertifikat, ein neuer Rechner, auf dem das Zertifikat nicht installiert ist).

• Der Client hatte ein Zertifikat, aber nicht von einer akzeptierten CA

  gelegentlich

  Clients, die automatisch ein Zertifikat auswählen (Browser, manche Bibliotheken), senden nur eines, das von einer CA aus der Liste „acceptable CA names“ des Servers ausgestellt wurde; passt keines, senden sie gar nichts.

• Ein Proxy terminiert TLS vor dem mTLS-Server

  gelegentlich

  Ein Load Balancer oder Proxy zwischen Client und Server terminiert die erste TLS-Verbindung und öffnet eine eigene ohne Client-Zertifikat zum Backend, das eines verlangt.

So behebst du den Fehler

1. 1.

   Client-Zertifikat vorlegen

   Übergib dem Client das Zertifikat und den privaten Schlüssel (curl --cert/--key, s_client -cert/-key, die Option der HTTP-Bibliothek für das Client-Zertifikat).

   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.

   Vom Server akzeptierte CAs auslesen

   openssl s_client listet die „Acceptable client certificate CA names“ auf, die der Server sendet; dein Zertifikat muss sich mit einer davon verketten lassen.

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

   Zertifikat selbst prüfen

   Das Zertifikat muss in seinem Gültigkeitszeitraum liegen und von einer akzeptierten CA ausgestellt sein, und seine extendedKeyUsage muss (falls vorhanden) clientAuth enthalten.

   # 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

← Gesamte Signaturfehler-Datenbank durchsuchen