Troubleshooting - Futurex Documentation

Use these entries for failures observed on the validated CryptoHub 7.3.0.x route.

load-token reports success=no

Confirm that the module path, CHLIBS_CONFIG service environment, token PIN, and CKA_ID match the endpoint and key.

sudo systemctl show strongswan-starter -p Environment
sudo test -x /usr/local/lib/libcryptohub-pkcs11.so
sudo swanctl --load-creds --clear --raw

Missing module, missing CHLIBS_CONFIG, missing or incorrect PIN, and an unavailable CKA_ID all produce this failure family.

C_Login reports CKR_USER_ALREADY_LOGGED_IN

Remove the password from cryptohub.json. Keep only the endpoint username and set pkcs11.check_already_logged_in to true. Supply the endpoint password only through the strongSwan token PIN.

pki rejects —cakey-type

strongSwan 5.9.13 does not implement --cakey-type. Remove that option and allow pki to infer the CA key type.

AppArmor hides the real failure

Inspect the kernel audit log:

sudo journalctl -k --since "10 minutes ago" --no-pager \
  | grep -i 'apparmor.*DENIED' \
  | grep -E 'charon|swanctl'

Add the exact installed module, configuration, TLS, PIN, log, or temporary authentication path to the matching local AppArmor override. Reload the profile before retrying.

IKE_AUTH fails after the token key loads

Compare each local.id with the subject or SAN in its certificate and with the peer’s remote.id. Then verify the CA certificate and traffic selectors on both gateways.

​load-token reports success=no

​C_Login reports CKR_USER_ALREADY_LOGGED_IN

​pki rejects —cakey-type

​AppArmor hides the real failure

​IKE_AUTH fails after the token key loads

load-token reports success=no

C_Login reports CKR_USER_ALREADY_LOGGED_IN

pki rejects —cakey-type

AppArmor hides the real failure

IKE_AUTH fails after the token key loads