strongSwan: Key Type, Loader and the Wrong Backend

File extensions do not identify key algorithms, and a .pem envelope can hold RSA or ECDSA material. PEM describes how bytes are wrapped, while RSA and ECDSA name different algorithms, and a PKCS12 file is a third thing again. strongSwan loads credentials through plugins and a configuration backend, so a certificate can appear in a list while the private key never becomes usable. Separate those layers before editing any secret.

Encoding, Algorithm and Packaging Are Three Layers

A key file has an encoding, an algorithm and often a container. PEM is the familiar base64 envelope; DER is its binary counterpart; PKCS12 bundles a certificate with its key and chain. A certificate-chain file is yet another container, and it usually holds no private key at all. None of those labels tells you whether the material inside is RSA or ECDSA.

Read the algorithm from the object itself. A provider's marketing name or a file extension is not evidence, because the same issuer can hand out different key types.

Compare Public Keys Before Blaming the Loader

A certificate that loads proves the certificate parsed, not that its private key is present or usable. Derive the public key from the certificate and from the proposed private key, then compare the two digests. If either extraction fails, stop there, because a digest of empty output proves nothing. Matching digests prove the pair belongs together, and nothing more about whether the certificate suits the job.

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

The second command touches private material on your machine but emits only the public half. Keep it that way, and never paste a private key into a ticket. If the key is encrypted, let the supported tool prompt for the passphrase instead of putting it on a command line where the process list can expose it.

Legacy ipsec.secrets or swanctl Credentials

strongSwan has two credential paths in common use. The legacy starter stack reads type-specific entries from ipsec.secrets, and each entry has to name the right type for the material. The swanctl and vici stack loads keys from its own credential directory through its own configuration. Editing the file that the running backend does not read changes nothing.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

Find which backend is actually running, then place the key where that backend looks. The strongSwan 5.9 legacy manual defines the type-specific secrets entries, and it is not swanctl documentation. Mixing the two produces a daemon that ignores a file the administrator believes is authoritative. A reload that reports no error only means the configuration parsed.

Read the Load Event and the Auth Result

After a controlled reload, read the daemon's own loading output for the specific key. A certificate listed in a status dump does not show that the private key was matched to it.

If a client still fails, keep the server event and the client error separate. Chain validation, identity matching and method compatibility are later questions with their own evidence. Write the outcome down with the exact key path and the digest you compared, because the next shift will otherwise repeat the same reload. Replacing the CA is not the first response to a loader mismatch.