Turkey (Turkish)
Germany (German)
Worldwide (English)
Request flowClient, NGINX, and backend connection break point
Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
NGINX SSL errors can be caused by missing certificate file, private key mismatch, incomplete intermediate chain, incorrect SNI vhost, expired certificate, or TLS incompatibility. This guide verifies certificate-key matching and actual offered chain.
nginx: [emerg] SSL_CTX_use_PrivateKey("/etc/ssl/private/example.key") failed
error:05800074:x509 certificate routines::key values mismatch
SSL_do_handshake() failedIn the HTTPS connection, NGINX must load the correct certificate chain and matching private key, the client must select a vhost suitable for SNI, and agree on a common TLS protocol/cipher suite.
A fullchain file containing the server certificate and intermediate certificates in the correct order should be used for the ssl_certificate.
If the private key certificate does not match, the NGINX config test will fail with a key values mismatch error similar to 'test key values mismatch'. Instead of relying on file names, the public key fingerprint/modulus should be compared.
The same IP has multiple HTTPS domains separated by SNI. If server_name matching or default SSL server is incorrect, the user may see a certificate for a different domain.
Even if Certbot renewal is successful, NGINX might be looking at the old copy of the file or hasn't been reloaded. The serial number of the live certificate should be compared with the one on disk.
Do not share the certificate and key via email or open terminal output; instead, compare the public fingerprint and file permissions.
Search for the phrase you see in the email, browser, or SSH log. Each card includes meaning, probable cause, and safe initial action.
Meaning: The certificate and private key do not belong to the same key pair.
Possible cause: Incorrect key file or path confusion after refresh.
Meaning: NGINX failed to load the private key.
Possible cause: File not found, permission, format, encrypted key, or match error.
Meaning: The certificate file cannot be opened.
Possible cause: Incorrect path, broken symlink, or permissions.
Meaning: TLS negotiation was not completed.
Possible cause: Protocol/password mismatch, client issue or bad traffic.
Meaning: The provided certificate has expired.
Possible cause: Refresh or reload failed.
Meaning: Client cannot complete the chain to a trusted root.
Possible cause: Incomplete or incorrect intermediate chain.
Meaning: Another vhost certificate is provided for the requested hostname.
Possible cause: SNI/server_name/default_server error.
Meaning: SSL listening server block has no certificate defined.
Possible cause: Missing include or incorrect server block structure.
No records matching this expression were found.
Commands are for root access. Collect only status and logs first; Do not change the permanent setting without seeing the reason.
nginx -t
nginx -T | grep -nE 'listen .*ssl|server_name|ssl_certificate(_key)?'Displays active certificate paths and SSL vhosts.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -serial -dates -ext subjectAltNameDisplays the actual certificate and SAN information.
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 sha256The public key hash match is verified without showing the private key.
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/nullVerifies the certificate chain and intermediate certificates.
certbot certificates
systemctl status certbot.timer --no-pager
journalctl -u certbot -n 100 --no-pagerDisplays the refresh date, timer, and error logs.
nginx -t && systemctl reload nginx
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -serial -datesVerifies that the new certificate is live.
Although the root cause of the NGINX error is the same, package paths, service names, security layers and virtual host management vary depending on the Linux distribution or Plesk infrastructure used.
NGINX SSL and Handshake Error for systemd, package path, and journald controls.
nginx -t
certbot certificates
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subjectNGINX SSL and Handshake Error for SELinux, PHP-FPM pool, and RHEL-based service controls.
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 virtual host files generated by Plesk: nginx SSL and handshake error check.
plesk bin certificate --list -domain example.com
nginx -t
plesk repair web example.com -nLook at the live certificate presented, not the file on disk; verify the path, match, chain, SNI, and TLS layers in order.
Record subject, SAN, issuer, and dates using SNI.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates -serialVerify which certificate and key file the real server block uses.
nginx -T | grep -nE 'server_name example.com|ssl_certificate(_key)?'Symlink chain, owner and key access must be secure.
namei -l /etc/letsencrypt/live/example.com/fullchain.pem
namei -l /etc/letsencrypt/live/example.com/privkey.pemPublic key hashes must be the same.
openssl x509 -in CERT -pubkey -noout | openssl sha256
openssl pkey -in KEY -pubout | openssl sha256Fullchain order and server_name/default SSL vhost must be correct.
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/nullThe new serial/date live endpoint should be visible.
nginx -t && systemctl reload nginxIncorrect private key file selected; hash matching is performed.
openssl x509 -in CERT -pubkey -noout | openssl sha256; openssl pkey -in KEY -pubout | openssl sha256Certbot timer, challenge, and reload steps are checked.
certbot certificates; systemctl list-timers | grep certbotcert.pem should be replaced with the fullchain file.
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/nullSNI, server_name and default_server are examined.
nginx -T | grep -nE 'listen .*443|server_name|ssl_certificate'The Origin certificate is for the Cloudflare-origin connection, not for browser trust.
Read Origin and proxied hostname certificates separately using the openssl command.Hosting Settings and mail/panel certificate assignments are checked separately.
plesk bin certificate --list -domain example.comThis indicates that the certificate and ssl_certificate_key file do not belong to the same key pair.
Server presents necessary intermediate certificates with its certificate; assists the client in completing its trust chain.
SNI server_name match, default SSL vhost or listen order is incorrect, another vhost certificate may be provided.
NGINX may be using a different file path, not reloaded, or a CDN is serving an old certificate.
No. Bots, old clients, and incompatible TLS offers can also generate this log; frequency and client information should be examined.
You can compare the SHA-256 hash values of the two files without showing the private key.
Domain hosting, panel hostname, and mail service certificates can be assigned separately; each endpoint must be validated live.
By analyzing cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim and security layers together, we fix the root cause of the failure instead of just removing the service.