strongSwan send_cert: When the IKE Certificate Is Sent

Gateways log certificate-related authentication failures, and the first instinct is to add another CA to the receiver. That assumes the certificate arrived and was rejected. The other possibility is that it was never sent, and the sender's connection policy decides that. Work out which of the two happened before editing trust.

What send_cert actually controls

Certificate authentication needs the peer's end-entity certificate to reach the other side through the IKE exchange or through prior provisioning. In swanctl the connection setting send_cert governs whether this endpoint includes its certificate payload: never, always, or ifasked. The default ifasked sends it in response to a certificate request from the peer. Requesting a certificate is a separate setting, because asking the other side for its certificate is not the same act as offering your own.

Older ipsec.conf deployments used leftsendcert and rightsendcert, and those names map onto local and remote roles rather than onto swanctl directly.

Read one attempt before editing the connection

Diagnose from a single controlled attempt, not from a general impression that certificates are involved. Both the policy and the live association are inspectable.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

The connection listing shows the configured send_cert value, and the SA listing shows which connections actually came up. The log adds negotiation detail: whether a certificate request was received and whether a certificate payload went out. A generic authentication failure does not identify a delivery problem, so look for the specific exchange before concluding anything. Record the attempt timestamp so the log window covers the whole handshake.

The receiver's trust is a separate decision

Delivery and trust are different properties, and fixing one does not fix the other. A receiver must hold the intended trust anchor, receive a usable chain and match the expected peer identity. An end-entity certificate arriving without its intermediate still fails a strict chain check. Conversely, installing a CA does not compel a peer to send its certificate at all.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

The inspection shows which issuer signed the certificate and when it expires, which is what the receiver's anchor must correspond to. Trust the issuing CA the deployment owns, not every intermediate in the chain, because promoting each intermediate to a root broadens trust far beyond one peer. Keep identity verification active, since a connection that only succeeds with validation disabled is not a fix. Where the chain is incomplete, repair provisioning rather than the sender policy.

Change the sender only with evidence

Once the log shows the certificate was never sent and the receiver did request one, setting send_cert to always is a justified change for that connection. Apply it in the swanctl configuration, reload the connections and establish a new session instead of reusing the existing SA. Confirm the certificate payload now appears and that the receiver accepts it against the intended anchor. If nothing changes, the fault was on the trust side after all and the sender setting was not the cause.

Write the observed exchange, the anchor and the resulting verification into the change record. A certificate fix that cannot be described in those terms is a coincidence.