VPN recovery: the tunnel configuration is not the private key

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

A VPN restore that puts the tunnel configuration back and not the credentials will load a description of a tunnel that cannot prove who it is. On the strongSwan swanctl directory page opened for this article, the configuration file and the credentials are different objects in one directory. swanctl.conf is the configuration. A fixed set of subdirectories holds private keys, end-entity certificates, CA certificates and revocation lists. Those files are read by swanctl --load-creds. Copying the configuration into place does not, on this page, load the keys, and copying the keys into the wrong subdirectory puts them where that kind of file is not what the directory is for.

This article covers the file-based certificate and private-key layout managed by swanctl. Other authentication methods and external key providers are outside that scope. It is the list of stores this recovery design must account for, and the order in which to bring them back. It is not a command sequence to rebuild a tunnel, and no key material was handled.

Why it matters

Tunnels fail authentication in ways that look like network failures. The peer is reachable. The proposal matches. The handshake dies because the key on disk is not the key the certificate was issued for, or because the CA that signed the peer is not in the trust store, or because a revocation list the last operator left behind still names a certificate you just restored.

Those are three files, and a backup of "the VPN config" often has only the first one's neighbour, the text file that points at them. The page says the directory contains swanctl.conf and the subdirectories that provide the file-based credentials. A backup that archives the conf file and skips the subdirectories, because they looked like a certificate dump, has archived the tunnel's description and not its identity.

The same directories are also a secret store. The page lists PKCS#1 RSA keys, plain ECDSA keys, PKCS#8 keys of any type, PKCS#12 containers, and a private directory for private keys in any format. A recovery copy of those directories is a copy of the private keys. It has to be stored as keys, not as a configuration export on a general file share. The page does not say that. It is the consequence of what the directories contain.

What each directory is for

The usual path is /etc/swanctl. The page says "usually". A host that was installed with a different path will not be healed by restoring files to the usual one. Since strongSwan 5.7.2, the subdirectories are found relative to the swanctl.conf that was loaded, including when that file is loaded from somewhere else with the --file option of the load commands. The directory can also be set at runtime with the environment variable SWANCTL_DIR. A restore plan has to name the path this host actually uses. Restoring to /etc/swanctl on a host whose process was started with a different SWANCTL_DIR restores a tree nothing is reading.

The page's table, which is the part to recover against, is:

All of those files may be DER or PEM. A restore that converts everything to one encoding because a script prefers PEM is a conversion this page allows only in the sense that both are accepted. It does not say every file in a PKCS#12 container survives being unpacked and re-encoded by a tool. Do not transform key files during a recovery. Put back the bytes that were saved, in the directory the table names for that kind of object.

The distinctions are the recovery mistakes. An end-entity certificate in x509ca is in the CA directory. A CA certificate in x509 is in the end-entity directory. The page assigns each directory a kind of credential. It does not say the loader searches the others. Our recommendation, not a sentence on the page: if you do not know which directory a file came from, do not guess from the file name. The backup has to have preserved the directory, not a flat folder of certificates.

conf.d is configuration, included by the default swanctl.conf since version 5.6.0. A restore of swanctl.conf that drops the include, or a restore that omits conf.d, loses every connection that lived only in a snippet. The default file's include is part of the configuration. Read it before you decide the conf file you saved is complete.

Loading is a separate step from copying

The page says these subdirectories are read by swanctl --load-creds. Since 5.7.2 that read is relative to the loaded configuration file. Copying a tree into place and not loading credentials leaves the running daemon with whatever it had loaded before, which may be nothing if the daemon was just installed, or the old credentials if it was not restarted. The page does not describe a restart policy. It names the command that reads the files.

Our recommendation: treat "files are on disk" and "credentials are loaded" as two states, and do not test the tunnel until the second has been done from the tree you restored. This article does not give the full load sequence, because the directory page does not specify the order of load-creds, load-conns and a reload, and those commands were not run. The related command names exist in the same documentation set. They were not opened beyond the statement that swanctl --load-creds reads these directories. A recovery procedure for a given strongSwan version has to be read from that version's pages before anyone runs it.

Revocation and trust are not the end-entity file

x509crl holds certificate revocation lists. x509ca holds the CA certificates you trust. x509ocsp holds OCSP signer certificates. A restore that brings back a working end-entity certificate and an old CRL can present a certificate the previous CRL revoked. Omitting a needed CA can prevent chain-based validation, while direct certificate trust and other configured authentication methods have different requirements. A certificate file does not depend on its issuer being reachable as a running service. The page does not say which of those the daemon rejects, or whether a missing CRL is ignored. Those behaviours are outside this page. What the page does establish is that the CRL, the CA and the OCSP signer are separate stored objects, read from named directories. Leaving them out of the backup is an incomplete credential set, not a tidier one.

The recovery decision is which generation of each object you intend. The certificate must match its private key cryptographically and satisfy the intended identity, validity and trust policy. Their backup timestamps need not match: a renewed certificate can legitimately reuse an existing key. Revocation information needs appropriate freshness and authenticity, not merely the same age as the certificate backup. The page does not provide a tool that checks that set. Matching backup times and directories is provenance evidence, not proof that a key matches a certificate. An authorised, non-disclosing cryptographic validation procedure is needed before use; none was executed for this article. This article did not perform that check on any real material and does not describe how to print a certificate.

Private keys in rsa, ecdsa, pkcs8, pkcs12 and private are the objects a backup system must not leave world-readable because they were "just certificates". The page groups them with the certificates in one tree. A file-level backup of /etc/swanctl that is readable by the same people who can read ordinary configuration has copied the keys into that audience. Restrict the copy to the people who may load credentials on this host. The page does not state a permission mode. The recommendation is editorial, and it follows from the table: those directories hold private keys.

What to decide

Name the directory the running process reads: the usual /etc/swanctl, or the path in SWANCTL_DIR, or the directory of the swanctl.conf that --file points at since 5.7.2. Restore to that tree. A second copy in the usual path, on a host that does not read it, is not a restore.

Plan to recover the connection file and any included snippets together with the credential stores the deployment actually uses. Preserve source paths and encodings, while checking whether any old key is compromised or any restored status object is stale before it becomes active. Include x509, x509ca, x509crl and x509ocsp when they were in use, not only the end-entity file. Include the private-key directory that matches how the key was stored. A PKCS#12 file belongs in pkcs12. An unpacked PKCS#8 key belongs in pkcs8. The table is the map.

Do not load those credentials into a daemon that is about to accept connections until the set is the generation you chose. Loading is what the page says makes the files credentials the tool reads. A tunnel test before that load tests the previous credentials, or none.

Keep the backup of the private-key directories as key material. Do not attach it to a ticket. Do not drop it on the file share used for switch configurations. If the corresponding private key is irretrievably lost, that certificate can no longer authenticate this endpoint and replacement credentials are needed. First determine whether the deployment uses an external key provider or another approved key backup; absence from this directory alone does not prove global key loss. The page does not describe enrolment. It does describe where an existing key would have been. Absence from every one of those directories, in every backup, means the key is not in the store this page documents.

Record which strongSwan documentation version you followed. The page offered 6.1, 6.0 and 5.9 in its switcher, and the sentences about 5.6.0 and 5.7.2 are version thresholds on the page itself. A host on an older release than 5.7.2 does not, on this page's wording, resolve the subdirectories relative to an arbitrary --file path. Read the page for the release you run before you rely on that relative lookup.

Risks and limits

This is one page: the swanctl directory layout. It does not specify handshake behaviour, which alerts a missing CA produces, or whether a missing CRL is fatal. Those limits are stated here so they are not filled in from memory. IKE, EAP and vendor VPN appliances were not opened. Windows certificate stores, which the same documentation set links to, were not opened. A tunnel to a peer that keeps its key in a different product still needs that peer's key to be the one your restored trust store expects. This page does not recover the peer.

No file was copied, no credential was loaded, and no tunnel was started. Paths and directory names are the page's. Permission recommendations are editorial.

The page carries a 2021–2025 copyright notice, which is not its publication date. It was independently reopened on 13 November 2026 from the latest documentation URL. If the site has moved a newer minor version into that URL since, re-read the table before you treat this article as the current layout.

Research and verification

Drafted with AI assistance on 11 November 2026 and independently source-reviewed on 13 November 2026. No equipment was configured, no article commands were executed and no lab behaviour is claimed. This is educational source research, not an approved production recovery procedure.

Sources

• strongSwan, swanctl Directory. https://docs.strongswan.org/docs/latest/swanctl/swanctlDir.html — usual path /etc/swanctl; swanctl.conf and credential subdirectories; swanctl --load-creds; relative lookup since 5.7.2; SWANCTL_DIR; conf.d include since 5.6.0; the directory table for x509, x509ca, x509aa, x509ocsp, x509crl, x509ac, rsa, ecdsa, pkcs8, pkcs12, private and pubkey; DER or PEM. Independently reopened 13 November 2026. Version switcher on the page listed 6.1, 6.0 and 5.9. Copyright notice 2021–2025.

This article was originally published on 13 November 2026.