> ## Documentation Index
> Fetch the complete documentation index at: https://docs.futurex.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting

> Resolve observed strongSwan, FxChlibs, credential, and AppArmor failures.

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.

```shell theme={null}
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:

```shell theme={null}
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.