- Newest
- Most votes
- Most comments
The error ENGINE_Load_private_key:no Load function typically occurs because OpenSSL cannot correctly map the dynamic engine's functionality without the explicit path to the CloudHSM shared library, or the key identifier format is slightly off for SDK 5.
On RHEL 9 with SDK 5, try the following corrected command structure:
openssl req -new \
-engine /opt/cloudhsm/lib/libcloudhsm_openssl.so \
-keyform engine \
-key "label=your-key-label" \
-config csr.conf \
-out rsa.csr
Key adjustments to resolve this:
- Explicit Path: Instead of just
-engine cloudhsm, provide the full path to the library:/opt/cloudhsm/lib/libcloudhsm_openssl.so.This ensures OpenSSL loads the correct symbols for the Load_private_key function. - Key Identifier: While handles work, SDK 5 often prefers the
label=NAMEorid=HEXformat. Ensure the Crypto User (CU) executing the command is the owner of the key or has shared access. - Verify Client Status: Ensure the cloudhsm-client service is active on your RHEL instance:
sudo systemctl status cloudhsm-client
If you must use the handle, ensure it is prefixed correctly as "handle=0x00..." and matches the output from the key list command in the CloudHSM CLI.
Regarding your last comment:
You are likely on the right track with both suspicions. In OpenSSL 3.x, the legacy engine support is much more restrictive, and key attributes are the most common reason for "missing" keys in CloudHSM.
Try these two specific steps to address your questions:
1. Is it the Key Attributes? (Highly Likely)
If a key is missing the SIGN attribute, the HSM will refuse to "load" it for a CSR operation, resulting in the error you see. Verify your key attributes using the CloudHSM CLI:
/opt/cloudhsm/bin/cloudhsm-cli key list --filter attr.label="your-key-label"
- Check: Look for OBJ_ATTR_SIGN. It must be true.
- Check: Ensure OBJ_ATTR_SENSITIVE is true and OBJ_ATTR_EXTRACTABLE is false (standard for HSM keys).
- Note: If SIGN is false, you cannot edit it. You must generate a new key pair with --attributes sign=true.
2. Is it OpenSSL 3.5.1? (Configuration Issue)
OpenSSL 3.x often fails to trigger the engine's "Load Key" function via CLI alone. You may need to explicitly initialize the engine inside your csr.conf file so OpenSSL knows how to handle the dynamic symbols:
Add this to the top of your csr.conf:
openssl_conf = openssl_init
[openssl_init]
engines = engine_section
[engine_section]
cloudhsm = cloudhsm_section
[cloudhsm_section]
engine_id = cloudhsm
dynamic_path = /opt/cloudhsm/lib/libcloudhsm_openssl.so
default_algorithms = ALL
init = 1
3. Session Check
Since you are using SDK 5, ensure you have an active session. The engine cannot "find" handles if the middleware isn't authenticated:
- Have you executed cloudhsm-cli login in the same environment?
- Is the cloudhsm-client service definitely healthy (systemctl status cloudhsm-client)?
If these configuration changes don't work, I strongly recommend switching from the Engine to the Provider (libcloudhsm_provider.so), as the Provider is the native architecture for OpenSSL 3.x and handles key-loading much more reliably.
Hello.
Can you check the engine status using the following command?
If it's working correctly, it should show as "available".
https://docs.aws.amazon.com/cloudhsm/latest/userguide/openssl5-install.html
openssl engine -t cloudhsm
You've probably set your username and password in the following environment variables, but you should also check if they are set correctly.
https://docs.aws.amazon.com/cloudhsm/latest/userguide/cloudhsm_cli-modes.html
echo $CLOUDHSM_PIN
In addition to AI-generated answers, the answers at the following URL may also be helpful.
https://repost.aws/questions/QUavo-JmUqRTeD02R_d8c-Qg/how-to-sign-data-using-openssl-cloudhsm-dynamic-engine#ANHIkdsGPOSVO-ZmPV6GcfRA
openssl engine -t cloudhsm this shows as available and CLOUDHSM_PIN is set in the format username:password
Relevant content
- asked 3 years ago
- asked a year ago
- asked a year ago
- asked a year ago
- AWS OFFICIALUpdated 2 years ago

Thank you for your inputs. I have tried the corrected command with label, id and handle and I still see the same error. Is it something to do with open ssl version 3.5.1 or something to do with the key attributes?