Türkei (Türkisch)
Germany (German)
Worldwide (English)
AnforderungsflussClient, NGINX und Backend-Verbindungsbrempunkt
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
NGINX-SSL-Fehler können durch fehlendes Zertifikat, privater-Schlüssel-ungleichheit, unvollständige Intermediate-Kette, falsche SNI-Vhost, abgelaufenes Zertifikat oder TLS-Inkompatibilität verursacht werden. Diese Anleitung überprüft Zertifikat-Schlüssel-Übereinstimmung und tatsächliche angebotene Kette.
nginx: [emerg] SSL_CTX_use_PrivateKey("/etc/ssl/private/example.key") failed
error:05800074:x509 certificate routines::key values mismatch
SSL_do_handshake() failedBei der HTTPS-Verbindung muss NGINX den korrekten Zertifikatschlüssel und den passenden privaten Schlüssel laden, der Client muss einen vhost auswählen, der für SNI geeignet ist, und sich auf einen gemeinsamen TLS-Protokoll-/Ziffern-Satz einigen.
Für die ssl_certificate sollte ein fullchain-File verwendet werden, das den Serverzertifikat und Intermediate-Zertifikate in der richtigen Reihenfolge enthält.
Wenn der private Schlüssel-Zertifikat nicht übereinstimmt, schlägt die NGINX-Konfigurationsprüfung mit einer ähnlichen Fehlermeldung 'test key values mismatch' fehl. Anstatt auf Dateinamen zu vertrauen, sollten der öffentliche Schlüssel-Fingerprint/Modul verglichen werden.
Die gleiche IP hat mehrere HTTPS-Domains, die durch SNI getrennt sind. Wenn die server_name-Übereinstimmung oder der Standard-SSL-Server falsch ist, kann der Benutzer ein Zertifikat für ein anderes Domän sehen.
Selbst wenn die Certbot-Erneuerung erfolgreich ist, könnte NGINX möglicherweise auf die alte Kopie der Datei schauen oder nicht neu geladen worden sein. Die Seriennummer des Live-Zertifikats sollte mit der auf der Festplatte verglichen werden.
Teilen Sie das Zertifikat und die Schlüssel nicht via E-Mail oder offener Terminalausgabe; vergleichen Sie stattdessen den öffentlichen Fingerabdruck und die Dateirechte.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: Das Zertifikat und der private Schlüssel gehören nicht zum gleichen Schlüsselpaar.
Mögliche Ursache: Falsche Schlüsseldatei oder Pfadverwirrung nach Refresh.
Bedeutung: NGINX konnte den privaten Schlüssel nicht laden.
Mögliche Ursache: Datei nicht gefunden, Berechtigung, Format, verschlüsselter Schlüssel oder Übereinstimmungsfehler.
Bedeutung: Die Zertifikatsdatei kann nicht geöffnet werden.
Mögliche Ursache: Falscher Pfad, gebrochener Symbolischer Link oder Berechtigungen.
Bedeutung: Die TLS-Verhandlung wurde nicht abgeschlossen.
Mögliche Ursache: Protokoll/Kennwort-Fehlpassung, Client-Problem oder schlechter Datenverkehr.
Bedeutung: Das bereitgestellte Zertifikat ist abgelaufen.
Mögliche Ursache: Wiederherstellung oder Reload fehlgeschlagen.
Bedeutung: Der Client kann die Kette nicht zu einem vertrauenswürdigen Wurzelknoten abschließen.
Mögliche Ursache: Unvollständige oder falsche Zwischenkette.
Bedeutung: Ein anderer vhost-Zertifikat wird für den angeforderten Hostnamen bereitgestellt.
Mögliche Ursache: SNI/server_name/default_server-Fehler.
Bedeutung: SSL lauschender Serverblock hat keine Zertifikatsdefinition.
Mögliche Ursache: Fehlende Include oder falsche Serverblockstruktur.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
nginx -t
nginx -T | grep -nE 'listen .*ssl|server_name|ssl_certificate(_key)?'Zeigt aktive Zertifikatspfade und SSL-Vhosts an.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -serial -dates -ext subjectAltNameZeigt die tatsächlichen Zertifikats- und SAN-Informationen an.
openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -pubkey -noout | openssl sha256
openssl pkey -in /etc/letsencrypt/live/example.com/privkey.pem -pubout | openssl sha256Der öffentliche Schlüssel-Hash-Vergleich wird ohne Anzeigen des privaten Schlüssels überprüft.
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /etc/letsencrypt/live/example.com/cert.pem
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/nullÜberprüft den Zertifikatschlüssel und die bereitgestellten Zwischenzertifikate.
certbot certificates
systemctl status certbot.timer --no-pager
journalctl -u certbot -n 100 --no-pagerZeigt die Wiederherstellungsdatum, Timer und Fehlerprotokolle an.
nginx -t && systemctl reload nginx
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -serial -datesBestätigt, dass die neue Zertifizierung live ist.
Obwohl die Grundursache des NGINX-Fehlers dieselbe ist, variieren Paketpfade, Dienstnamen, Sicherheitsebenen und die Verwaltung virtueller Hosts je nach verwendeter Linux-Distribution oder Plesk-Infrastruktur.
NGINX SSL und Handshake Fehler für systemd, Paketpfad und journald-Prüfunglen.
nginx -t
certbot certificates
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subjectNGINX SSL und Handshake Fehler für SELinux, PHP-FPM-Pool und RHEL-basierte Dienstkontrollen.
nginx -t
certbot certificates 2>/dev/null
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subjectNGINX virtuelle Host-Dateien von Plesk generiert: Überprüfung von nginx-SSL- und Handshake-Fehlern.
plesk bin certificate --list -domain example.com
nginx -t
plesk repair web example.com -nSchauen Sie sich das live präsentierte Zertifikat an, nicht die Datei auf der Festplatte; überprüfen Sie den Pfad, die Übereinstimmung, die Kette, SNI und die TLS-Schichten in der richtigen Reihenfolge.
Mit SNI verwenden Sie subject, SAN, issuer und Datum.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates -serialBestätigen Sie, welche Zertifikat- und Schlüsseldatei der echte Serverblock verwendet.
nginx -T | grep -nE 'server_name example.com|ssl_certificate(_key)?'Symlink-Kette, Besitzer- und Schlüsselzugriff müssen sicher sein.
namei -l /etc/letsencrypt/live/example.com/fullchain.pem
namei -l /etc/letsencrypt/live/example.com/privkey.pemDie öffentlichen Schlüssel-Hashes müssen identisch sein.
openssl x509 -in CERT -pubkey -noout | openssl sha256
openssl pkey -in KEY -pubout | openssl sha256Die Reihenfolge der Fullchain und server_name/default SSL-Vhost müssen korrekt sein.
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/nullDer neue serielle/Datums-Live-Endpunkt sollte sichtbar sein.
nginx -t && systemctl reload nginxFalsche private Schlüsseldatei ausgewählt; Hash-Abgleich wird durchgeführt.
openssl x509 -in CERT -pubkey -noout | openssl sha256; openssl pkey -in KEY -pubout | openssl sha256Certbot-Timer, Challenge- und Reload-Schritte werden überprüft.
certbot certificates; systemctl list-timers | grep certbotcert.pem sollte durch die fullchain-Datei ersetzt werden.
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/nullSNI, server_name und default_server werden untersucht.
nginx -T | grep -nE 'listen .*443|server_name|ssl_certificate'Das Origin-Zertifikat dient der Cloudflare-Origin-Verbindung und nicht der Browser-Vertrauenswürdigkeit.
Lesen Sie die Origin- und proxied-Hostname-Zertifikate getrennt mit der openssl-Kommandozeile.Hosting-Einstellungen und Mail/Panel-Zertifikatszuweisungen werden getrennt überprüft.
plesk bin certificate --list -domain example.comDies zeigt an, dass das Zertifikat und die ssl_certificate_key-Datei nicht zum gleichen Schlüsselpaar gehören.
Server stellt erforderliche Intermediate-Zertifikate zusammen mit seinem Zertifikat bereit; unterstützt den Client bei der Abschluss seiner Vertrauenskette.
SNI-Server-Name-Ubereinstimmung, Default-SSL-Vhost oder Listen-Reihenfolge ist falsch, kann ein anderer Vhost-Zertifikat bereitgestellt werden.
NGINX könnte ein anderes Dateisystem verwenden, nicht neu geladen werden oder ein CDN könnte ein altes Zertifikat bereitstellen.
Nein. Bots, alte Clients und inkompatible TLS-Angebote können auch diesen Log erzeugen; Häufigkeit und Client-Informationen sollten untersucht werden.
Sie können die SHA-256-Hashwerte der beiden Dateien ohne das Anzeigen des privaten Schlüssels vergleichen.
Domain-Hosting, Panel-Hostname und Mail-Service-Zertifikate können separat zugewiesen werden; jeder Endpunkt muss live validiert werden.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.