error:05800074:x509 certificate routines::key values mismatch

nginx -t meldet den Fehler als „[emerg] SSL_CTX_use_PrivateKey("<key file>") failed (SSL: error:05800074:x509 certificate routines::key values mismatch)“; die OpenSSL-CLI fügt den Funktionsnamen hinzu („x509 certificate routines:ossl_x509_check_private_key:key values mismatch“); Python gibt „[X509: KEY_VALUES_MISMATCH] key values mismatch“ aus; Node.js setzt den Code ERR_OSSL_X509_KEY_VALUES_MISMATCH. OpenSSL 1.1.1 verwendete den Code 0B080074.

OpenSSL 3 — X509_R_KEY_VALUES_MISMATCH when loading a certificate with a private key (nginx, Node.js, Python, openssl s_server)

Was der Fehler bedeutet

Ein TLS-Server (oder eine Bibliothek) hat ein Zertifikat und einen privaten Schlüssel bekommen, die nicht zusammengehören: Der öffentliche Schlüssel im Zertifikat ist nicht die öffentliche Hälfte des privaten Schlüssels. OpenSSL weigert sich, das Paar zu laden, deshalb startet der Server nicht, oder der Kontext lässt sich nicht erstellen. Jede der beiden Dateien ist für sich genommen in Ordnung.

Warum der Fehler auftritt

• Das Zertifikat wurde für einen neueren (oder älteren) Schlüssel ausgestellt

  häufig

  Bei der Erneuerung wurden ein neuer Schlüssel und ein neuer CSR erzeugt, aber die Konfiguration zeigt noch auf die alte Schlüsseldatei, oder das neue Zertifikat wurde mit dem Schlüssel vom Vorjahr kombiniert.

• Das Bundle beginnt mit dem Zwischenzertifikat statt mit dem Leaf-Zertifikat

  häufig

  Server vergleichen den Schlüssel mit dem ersten Zertifikat in der Datei. Eine Kettendatei in der Reihenfolge Zwischenzertifikat, Leaf-Zertifikat (oder mit einem Root-Zertifikat am Anfang) löst diesen Fehler aus, obwohl Leaf-Zertifikat und Schlüssel zusammenpassen.

• Dateien verschiedener Hosts oder Umgebungen wurden vermischt

  gelegentlich

  Wer Zertifikate zwischen Staging und Produktion oder zwischen mehreren Namen auf einem Server kopiert, kombiniert leicht ein Zertifikat mit dem Schlüssel eines anderen Hosts.

So behebst du den Fehler

1. 1.

   Öffentliche Schlüssel vergleichen

   Berechne den Hash des öffentlichen Schlüssels aus dem Zertifikat und den Hash des öffentlichen Schlüssels, der aus dem privaten Schlüssel abgeleitet ist; sind die Hashes identisch, gehören beide zusammen. Das funktioniert für RSA-, EC- und Ed25519-Schlüssel gleichermaßen.

   # The two hashes must be identical
   openssl x509 -in server.pem -noout -pubkey | openssl sha256
   openssl pkey -in server.key -pubout | openssl sha256

2. 2.

   Leaf-Zertifikat an den Anfang des Bundles stellen

   Liste die Subjects im Bundle auf; das Leaf-Zertifikat für deinen Hostnamen muss zuerst kommen, danach die Zwischenzertifikate.

   # Servers match the key against the FIRST certificate of the file: make it the leaf
   openssl crl2pkcs7 -nocrl -certfile fullchain.pem | openssl pkcs7 -print_certs -noout | grep subject=
   cat api.example.com.crt intermediate.crt > fullchain.pem

3. 3.

   Passenden Schlüssel unter mehreren finden

   Vergleiche den Hash des öffentlichen Schlüssels im Zertifikat mit jedem infrage kommenden Schlüssel; passt keiner, ist der Schlüssel verloren, und das Zertifikat muss mit einem neuen Schlüssel neu ausgestellt werden.

   # Which of several keys belongs to the certificate?
   cert=$(openssl x509 -in server.pem -noout -pubkey | openssl sha256)
   for k in /etc/ssl/private/*.key; do
     [ "$(openssl pkey -in "$k" -pubout 2>/dev/null | openssl sha256)" = "$cert" ] && echo "match: $k"
   done

← Gesamte Signaturfehler-Datenbank durchsuchen