When establishing IPSec connections using StrongSwan, certificate-based authentication is frequently employed. Certificates can either be obtained from external Certificate Authorities or self-signed. In the latter case, StrongSwan's built-in pki utility facilitates certificate generation.

To generate a self-signed root CA certificate and its corresponding private key:

ipsec pki --gen --outform pem > caPrivateKey.pem
ipsec pki --self --in caPrivateKey.pem --dn "C=CN, O=ExampleOrg, CN=Example CA" --ca --outform pem > caCertificate.pem

Next, create RSA private keys for both endpoints (e.g., client at 192.168.171.129 and server at 192.168.171.131), then issue certificates signed by the CA:

ipsec pki --gen --size 4096 --type rsa --outform pem > serverKey.pem
ipsec pki --pub --in serverKey.pem --type rsa | ipsec pki --issue --lifetime 3650 --cacert caCertificate.pem --cakey caPrivateKey.pem --dn "CN=192.168.171.131" --san="192.168.171.131" --flag serverAuth --flag ikeIntermediate --outform pem > serverCert.pem

ipsec pki --gen --size 4096 --type rsa --outform pem > clientKey.pem
ipsec pki --pub --in clientKey.pem --type rsa | ipsec pki --issue --lifetime 3650 --cacert caCertificate.pem --cakey caPrivateKey.pem --dn "CN=192.168.171.129" --san="192.168.171.129" --flag serverAuth --flag ikeIntermediate --outform pem > clientCert.pem

Place these files into appropriate directories under /etc/ipsec.d/. For instance, on the client machine (192.168.171.129):

cp caCertificate.pem /etc/ipsec.d/cacerts/
cp clientKey.pem /etc/ipsec.d/private/
cp clientCert.pem /etc/ipsec.d/certs/

On the server side (192.168.171.131):

cp caCertificate.pem /etc/ipsec.d/cacerts/
cp serverKey.pem /etc/ipsec.d/private/
cp serverCert.pem /etc/ipsec.d/certs/

After deploying certificates, it is essential to restart the StrongSwan service for changes to take effect:

systemctl restart strongswan

Alternatively, use the command ipsec restart. To verify that certificates have been correctly loaded, run:

ipsec listcerts

Ensure that all deployed certificates appear in the outputt; missing entries indicate misconfiguration.

During certificate creation, the Common Name (CN) field plays a crucial role in identification. This value should match the leftid or rightid specified in the configuration file (ipsec.conf). Mismatched identifiers will result in failed authentication attempts. Below shows an example configuration snippet where leftid matches the CN defined during certificate issuance.

For the client node:

conn host-to-host
    left=192.168.171.129
    leftid=192.168.171.129
    leftcert=clientCert.pem
    right=192.168.171.131
    rightid=192.168.171.131

And for the server node:

conn ipsec-tunnel
    left=192.168.171.131
    leftid=192.168.171.131
    leftcert=serverCert.pem
    right=192.168.171.129
    rightid=192.168.171.129

While IP addresses are used here for simplicity, alternative unique identifiers like domain names or email addresses may also serve as valid CN values.

Two distinct tools exist for managing StrongSwan: ipsec and swanctl. The former relies on configurations stored in /etc/ipsec.conf, whereas the latter uses /etc/swanctl/swanctl.conf. These tools operate independent and do not share configuration data. Choose one method consistently throughout deployment.

Whenever modifications occur within configuration files, reloading becomes necessary. Use the following commands according:

• After updating /etc/ipsec.conf: ipsec reload
• After modifying /etc/ipsec.secrets: ipsec rereadsecrets
• Following edits to /etc/swanctl/swanctl.conf: swanctl --load-all

Failure to reload results in unchanged behavior despite apparent updates.