Environment
- Product: YugabyteDB Universes deployed via YugabyteDB Anywhere
- Applies to: All Versions
Summary
This article explains how to diagnose and resolve SSL/TLS connection failures caused by the error
[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: EE certificate key too weak
or one of the corresponding server log message:
E0916 10:36:27.069799391 5076 ssl_transport_security.cc:846] Invalid cert chain file. E0916 10:36:27.069834302 5076 ssl_security_connector.cc:270] Handshaker factory creation failed with TSI_INVALID_ARGUMENT. E0916 10:36:27.069940688 5076 chttp2_server.cc:1045] UNKNOWN:Unable to create secure server with credentials of type Ssl
OpenSSL error: error:0A00018F:SSL routines::ee key too small.
These errors typically occur on hardened operating systems with strict security policies.
Symptoms
You may encounter one or both of the following errors when a client application or a YugabyteDB service attempts to establish a TLS-encrypted connection.
Client-side Error
The connection fails with a certificate verification error. An example of this is a YCQLSH health check failure reported in YugabyteDB Anywhere:
yb-prod-test-n2 (10.1.2.3) - Connectivity with cqlsh - 'Error executing command timeout 20 bash -c 'set -o pipefail; SSL_VERSION=TLSv1_2 SSL_CERTFILE=/home/yugabyte/yugabyte-tls-config/ca.crt /home/yugabyte/tserver/bin/cqlsh 10.1.2.3 9042 -e "SHOW HOST" --ssl': Connection error: ('Unable to connect to any servers', {'10.1.2.3:9042': PermissionError(1, "Tried connecting to [('10.1.2.3', 9042)]. Last error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: EE certificate key too weak (_ssl.c:1147)")})'
Server-side Log Error
A core YugabyteDB service may fail to start, and its logs will show a specific OpenSSL error indicating the certificate key is too small. For example, if the YB-Controller Service fails, you may see the following in its logs:
E20250916 10:45:18.598678 13924 server.cc:93] OpenSSL error: error:0A00018F:SSL routines::ee key too small
Cause and Diagnosis
The root cause is a mismatch between the system-wide cryptographic policy enforced by the host operating system and the key size of the TLS certificates generated by YugabyteDB Anywhere.
Modern Linux distributions (like RHEL 8+, CentOS 8+, and derivatives) use these policies to enforce a consistent security baseline for all applications using system libraries like OpenSSL. The error occurs when the policy is set to the highly restrictive FUTURE level, which mandates a minimum RSA key size of 3072 bits.
YugabyteDB Anywhere-generated certificates typically use a strong, but more common, 2048-bit RSA key. When the FUTURE policy is active, the system's OpenSSL library correctly identifies this key as non-compliant and rejects it during the TLS handshake.
You can confirm this diagnosis with two simple checks on the affected node:
1. Check the Current Crypto Policy:
update-crypto-policies --show
If the output is FUTURE, you have confirmed the cause.
2. Inspect the Certificate's Key Size:
Use OpenSSL to check the key size of the certificate in use.
# Corrected command openssl x509 -in /home/yugabyte/yugabyte-tls-config/node.crt -noout -text
Check the Subject Public Key Info section in the output.
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit) # <-- This is less than the 3072 bits required by the FUTURE policy.
Solution
The solution depends on whether you are using the default certificates managed by YugabyteDB Anywhere or custom certificates.
Solution 1: Downgrade the Crypto Policy (For YBA-Managed Certificates)
This is the recommended solution for universes using the default certificates generated by YugabyteDB Anywhere.
-
Set the system policy to DEFAULT:
This policy level provides a strong security posture while being compatible with 2048-bit keys.
sudo update-crypto-policies --set DEFAULT
-
Reboot the system:
A reboot is required to ensure all services and applications adopt the new, less restrictive policy.
sudo reboot
After the node reboots, the system will accept the existing 2048-bit certificate, and services and connections should succeed.
Solution 2: Regenerate Certificates (For Custom Certificates)
This solution applies only if you are using your own custom certificates instead of the ones managed by YBA. The best practice is to create new certificates that meet the FUTURE policy's security requirements.
-
Generate a new certificate with an RSA key size of at least 3072 bits.
# Example for generating a self-signed certificate with a 3072-bit key openssl req -x509 -newkey rsa:3072 -keyout new_private.key -out new_certificate.crt -sha256 -days 3650 -nodes
-
Deploy the new certificate and private key to your universe by following the YugabyteDB documentation for adding custom server certificates.
- Documentation: Add a Custom Self-Signed Certificate
Reference: SUPPORT-740
Comments
0 comments
Please sign in to leave a comment.