The TLS_RSA_WITH_AES_128_GCM_SHA256 cipher suite failed because the server could not find a private key matching any of the certificates it was configured to present.
Invalid Certificate Path
The most common culprit is a misconfigured certificate chain. The server needs the entire chain, from the end-entity certificate all the way up to a trusted root CA. If a certificate in the chain is missing, the server might present a certificate that the client can’t validate, leading to this error.
Diagnosis:
Use openssl s_client -connect your.server.com:443 -servername your.server.com and examine the Certificate chain section. Look for any gaps or unexpected issuers.
Fix:
Ensure your certificate file (e.g., server.crt) contains your server certificate followed by any intermediate CA certificates. The order is crucial. For example:
-----BEGIN CERTIFICATE-----
... your server certificate ...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... your intermediate CA certificate 1 ...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... your intermediate CA certificate 2 ...
-----END CERTIFICATE-----
Why it works: The client performs a chain validation. If any link in the chain is broken, the validation fails. By providing the full, ordered chain, you enable the client to successfully build a path to a trusted root.
Private Key Mismatch
The private key file specified in your web server’s configuration doesn’t actually correspond to the public key within the certificate file. This can happen if you accidentally swapped files, or if the private key was regenerated without updating the certificate.
Diagnosis:
Run openssl x509 -noout -modulus -in server.crt | openssl md5 and openssl rsa -noout -modulus -in server.key | openssl md5. The resulting MD5 hashes should be identical.
Fix:
If the hashes differ, you need to use the correct private key that matches your server.crt. If you’ve lost the original private key, you’ll need to generate a new certificate signing request (CSR) with a new private key, and then have your CA re-issue your certificate.
Why it works: The modulus of a public key (from the certificate) and its corresponding private key should be mathematically identical. This check verifies that the key pair is a valid match.
Incorrect File Permissions
The web server process (e.g., nginx or apache) doesn’t have the necessary read permissions for the certificate and key files. This is a common security measure, but it can inadvertently block the server from accessing its own TLS credentials.
Diagnosis:
Check the permissions of your certificate and key files using ls -l /path/to/your/server.crt and ls -l /path/to/your/server.key. The user or group running your web server process needs read access.
Fix:
Ensure the files are readable by the web server user. For example, if your web server runs as user www-data:
sudo chown www-data:www-data /path/to/your/server.crt
sudo chmod 644 /path/to/your/server.crt
sudo chown www-data:www-data /path/to/your/server.key
sudo chmod 600 /path/to/your/server.key
Why it works: The web server process needs to open and read these files to load the TLS configuration. Incorrect permissions prevent this read operation.
Stale Configuration or Reload Issues
The web server might be using old configuration files that point to non-existent or incorrect certificate/key paths, or it may not have successfully reloaded its configuration after updates.
Diagnosis:
Check your web server’s configuration files (e.g., /etc/nginx/nginx.conf, /etc/apache2/sites-available/your-site.conf) for the ssl_certificate and ssl_certificate_key directives (Nginx) or SSLCertificateFile and SSLCertificateKeyFile (Apache). Verify the paths are correct and that the files exist.
Fix:
After correcting the configuration file paths, force a reload or restart of your web server.
For Nginx: sudo systemctl reload nginx or sudo systemctl restart nginx
For Apache: sudo systemctl reload apache2 or sudo systemctl restart apache2
Why it works: Reloading/restarting the web server process makes it re-read its configuration files, applying the corrected paths and loading the actual certificate and key files.
Wildcard Certificate Mismatch
If you’re using a wildcard certificate (e.g., *.example.com), ensure that the hostname you are accessing (e.g., www.example.com or app.example.com) is covered by the wildcard. A wildcard certificate for *.example.com will not match example.com itself, nor will it match sub.sub.example.com.
Diagnosis:
Examine the Subject and Subject Alternative Name (SAN) fields of your certificate using openssl x509 -in server.crt -text -noout. Look for the wildcard entry.
Fix:
If the hostname isn’t covered, you’ll need a new certificate that includes the specific hostname or a broader wildcard. For example.com and *.example.com, you typically need two separate certificates or a certificate with both listed in the SANs.
Why it works: The server presents a certificate based on the hostname requested by the client. If the presented certificate’s subject or SANs don’t match the requested hostname, the client rejects it.
Expired Certificate
While less common for this specific error message (which usually implies a missing match), an expired certificate can sometimes lead to unexpected behavior or be misinterpreted by certain TLS client configurations as a failure to match.
Diagnosis:
Check the Not Before and Not After dates on your certificate: openssl x509 -in server.crt -noout -dates.
Fix: Renew your certificate with your Certificate Authority.
Why it works: A valid certificate must be within its validity period. An expired certificate is no longer trusted.
The next error you’ll likely encounter after fixing this is a certificate verify failed error if your intermediate chain is still incomplete or untrusted by the client.