When deploying an HTTPS-enabled Nginx server, administrators may occasionally encounter startup errors. A typical error message is:

　　nginx: [emerg] SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values ​​mismatch.

　　Although this string of characters may seem cryptic, it actually indicates that Nginx detected a mismatch between the SSL certificate and private key it was loading. Many beginners encounter this error when setting up an HTTPS environment for the first time. They try restarting, regenerating certificates, and modifying configuration files, but still can't get Nginx to start properly. To thoroughly resolve this issue, it's important to understand the underlying mechanism and triggering logic to address it effectively.

　　When Nginx displays the "SSL: error:0B080074" error upon startup, it's typically because the certificate and private key loaded in the configuration file aren't generated from the same key generation process. In other words, the public key in the certificate doesn't match the specified private key. In the SSL/TLS system, a certificate consists of a public key and a signature. The public and private keys are a pair of independently generated keys. This inconsistency can occur if the private key is replaced or lost at some point in the process, or if the certificate is reissued without updating the corresponding private key. If Nginx fails this verification at startup, it will immediately report an error and terminate loading to prevent security vulnerabilities.

　　To troubleshoot this issue, the first step is to confirm that the certificate path loaded in the configuration file is correct. Nginx typically enables SSL with the following two lines of configuration:

ssl_certificate /etc/nginx/ssl/example.crt;
ssl_certificate_key /etc/nginx/ssl/example.key;

　　The .crt file is the server certificate or certificate chain, and the .key file is the corresponding private key. If the path points to the wrong one, or the private key file is mistakenly replaced with the key of another domain name, an error will be reported. You can use the OpenSSL command to verify whether the two match:

openssl x509 -noout -modulus -in example.crt | openssl md5
openssl rsa -noout -modulus -in example.key | openssl md5

　　If the output MD5 values ​​are the same, the certificate and private key match. If they are different, you need to find the correct matching file. This verification method is the most direct and effective way to troubleshoot SSL errors.

　　Another common cause is a corrupted or incorrectly formatted certificate file. Many people may accidentally add extra blank lines or omit the "-----BEGIN CERTIFICATE-----" or "-----END CERTIFICATE-----" markers when copying the certificate contents, causing Nginx to parse it incorrectly. Some users also edit the certificate file in Windows and upload it to a Linux server. This can cause parsing errors due to different line breaks (CRLF vs. LF). It is recommended to use cat -A or the file command to verify the file format to ensure that it is UTF-8 encoded and contains no extraneous characters.

　　When using a chain certificate, SSL verification failures may also occur due to incorrect file order. Some users may reverse the order of the primary and intermediate certificates or only load the primary certificate without the intermediate certificates. Although browser access may still work, Nginx will strictly verify the integrity during startup, resulting in errors. The correct approach is to place the primary certificate at the top of the file, followed by the intermediate certificates, and finally the root certificate. For example, when using Let's Encrypt, the fullchain.pem file should be configured as the ssl_certificate path, not cert.pem, as the former contains the complete trust chain.

　　Note that compatibility issues may also occur when using different versions of the OpenSSL library with Nginx. Some older OpenSSL versions will incorrectly report a "key values ​​mismatch" when parsing newer encryption algorithms (such as ECDSA certificates). If you confirm that the certificate and private key match but still receive an error, run the nginx -V command to check the compilation parameters and OpenSSL version. If the version is outdated, it is recommended to upgrade to version 1.1.1 or higher. Furthermore, for environments using ECDSA certificates, ensure that the corresponding ssl_certificate_key file is used in the configuration file, not the RSA private key.

　　In some automated deployment environments, such as when using tools like Certbot and Acme.sh to generate certificates, this error may also occur due to permissions or symbolic link issues. Certbot typically creates symbolic links in the /etc/letsencrypt/live/domain/ directory pointing to the actual stored certificate files. If these links are corrupted or have insufficient permissions, Nginx cannot read them, resulting in an SSL error. Use ls -l to verify that the links are valid and confirm that the Nginx user (usually www-data or nginx) has read access to the relevant files. If permissions are restricted, run chmod 644 or chown nginx:nginx to fix the issue.

　　In addition to the direct causes listed above, there's also a special case where the administrator changes the domain name or reissues the certificate but forgets to update the private key. Some CAs don't generate a new private key when reissuing a certificate. If a user mistakenly uses an old private key file, signature verification will fail. The solution is to generate a new key pair and reapply for the certificate using a CSR, ensuring that the public and private keys are from the same source.

　　Many beginners attempt to resolve this type of error by simply restarting Nginx or regenerating the certificate. However, if this doesn't address the root cause, the error will often recur. A more effective approach is to follow the following troubleshooting sequence: Verify that the path and file name in the configuration file are correct. Use OpenSSL commands to verify that the certificate and private key match. Check the integrity of the certificate chain and the order of the files. Confirm that the file format, permissions, and encoding are correct. Verify that the Nginx and OpenSSL versions are compatible. If the problem persists, regenerate the key pair and certificate.

　　For servers in production environments, it is recommended to establish a systematic certificate management strategy. For example, uniformly name and store certificates, private keys, and intermediate certificates in a specific directory. Set up version control and backup mechanisms to prevent file confusion during updates. Regularly checking certificate validity periods and chain integrity can help identify potential problems before they occur.

　　During the troubleshooting process, it is also important to understand the meaning behind the error code. In the OpenSSL error code 0B080074, "0B" represents the x509 module, and "080074" indicates a failure in the public key verification phase. In other words, this error doesn't involve file permissions or encryption algorithms, but rather clearly indicates a mismatch between the certificate and private key. This provides a direct path for troubleshooting. If the error code is different, such as related to SSL_CTX_use_certificate or PEM_read_bio, the file may be corrupted or have a formatting issue.