„key values mismatch“: Wenn Zertifikat und Schlüssel nicht zusammenpassen

So sieht der Fehler aus

# nginx (OpenSSL 3)
SSL_CTX_use_PrivateKey("/etc/ssl/private/server.key") failed
(SSL: error:05800074:x509 certificate routines::key values mismatch)

# Apache
AH02565: Certificate and private key www.beispiel.de:443:0 from
/etc/ssl/certs/server.crt and /etc/ssl/private/server.key do not match

# HAProxy
inconsistencies between private key and certificate loaded from PEM file

Unter Windows bzw. IIS heißt dasselbe Problem anders: Beim Binden des Zertifikats erscheint „Eine angegebene Anmeldesitzung ist nicht vorhanden“, oder das Zertifikat zeigt in der Verwaltung kein Schlüsselsymbol.

Was der Server prüft

Ein Zertifikat enthält den öffentlichen Schlüssel. Der Server hält den dazugehörigen privaten Schlüssel. Beim Start prüft er, ob beide ein Paar bilden. Ist das nicht so, verweigert er den Dienst, denn kein Client könnte die Verbindung aufbauen.

Die vier häufigsten Ursachen

1. Das Zertifikat gehört zu einem anderen CSR

Der Klassiker: Für die Verlängerung wurde ein neuer CSR mit neuem Schlüssel erzeugt, eingespielt wurde aber der alte Schlüssel. Oder der CSR entstand auf einem anderen Server bzw. bei einem Kollegen.

2. Die Reihenfolge in der Zertifikatsdatei stimmt nicht

nginx und HAProxy vergleichen den Schlüssel mit dem ersten Zertifikat in der Datei. Steht dort das Zwischenzertifikat, weil die Dateien in falscher Reihenfolge zusammengefügt wurden, passt der Schlüssel natürlich nicht.

# richtig: erst das Server-Zertifikat, dann die Zwischenzertifikate
cat server.crt intermediate.crt > fullchain.pem

3. Die Konfiguration zeigt auf die falsche Datei

Ein Tippfehler im Pfad, ein Symlink auf eine alte Datei, oder Zertifikat und Schlüssel sind in der Konfiguration vertauscht.

4. Windows: Zertifikat ohne privaten Schlüssel

Wurde eine .cer-Datei importiert, obwohl der CSR auf einem anderen Rechner erzeugt wurde, fehlt der Schlüssel. Wurde der CSR auf demselben Server erstellt, lässt sich die Verbindung zum Schlüssel oft wiederherstellen:

certutil -repairstore my <Seriennummer des Zertifikats>

So findest du heraus, was zusammengehört

Am schnellsten geht es mit dem Key-Match: Zertifikat, Schlüssel und gegebenenfalls CSR in das Feld ziehen. Das Werkzeug berechnet für jedes Objekt den Fingerabdruck des öffentlichen Schlüssels und zeigt mit Buchstaben, was zusammengehört. Es funktioniert mit RSA- und ECC-Schlüsseln, mit DER-Dateien und mit verschlüsselten Schlüsseln. Nichts wird hochgeladen.

Auf der Kommandozeile geht dasselbe so. Alle drei Ausgaben müssen gleich sein:

openssl x509 -in server.crt -noout -pubkey | openssl sha256
openssl pkey -in server.key -pubout       | openssl sha256
openssl req  -in server.csr -noout -pubkey | openssl sha256

Der oft empfohlene Vergleich des Modulus (-modulus) funktioniert nur bei RSA. Der Vergleich über den öffentlichen Schlüssel klappt auch bei ECDSA.

Liegen mehrere Schlüssel herum, findest du den passenden so:

for k in /etc/ssl/private/*.key; do
  echo "$(openssl pkey -in "$k" -pubout 2>/dev/null | openssl sha256 | cut -d' ' -f2)  $k"
done

Die Lösung

• Passender Schlüssel gefunden: Pfad in der Konfiguration korrigieren und den Dienst neu laden.
• Falsche Reihenfolge: Datei in der Reihenfolge Server-Zertifikat → Zwischenzertifikate neu zusammensetzen, das geht auch im Zertifikat-Konverter.
• Schlüssel verloren: Mit dem CSR-Generator einen neuen Schlüssel und CSR erzeugen und das Zertifikat neu ausstellen lassen (Reissue). Das ist bei den meisten CAs kostenlos.
• Windows: Zertifikat und Schlüssel im Konverter zu einer PFX-Datei zusammenführen und diese importieren.