Pre-shared keys or certificates for IPsec authentication? What are the trade-offs?
Show the answer
Say this first
PSKs are simple and fine for a handful of tunnels, but every key is distributed and rotated by hand, a leaked key exposes every tunnel that shares it, and wildcard keys for dynamic peers are a big weakness. Certificates scale: each device has its own key pair signed by a CA, peers are checked against the CA and revocation, and adding a device touches nothing else. The price is running a PKI: enrollment, renewal, CRL or OCSP availability, and correct clocks everywhere.
Go deeper
PSK hygiene
- Long and random, unique per peer where possible.
- A weak PSK can be attacked offline from captured exchanges, and IKEv1 aggressive mode makes that easy.
Certificates on IOS, the moving parts
crypto pki trustpointwith enrollment (SCEP or manual), subject name and revocation policy.- In the IKEv2 profile:
authentication local rsa-sig,authentication remote rsa-sigandpki trustpoint NAME. revocation-check crl nonemeans check the CRL, but accept the certificate if the CRL cannot be fetched. Decide that on purpose.
Operational traps
- Clock: certificates have validity dates. Without NTP, a router whose clock is wrong rejects valid certificates.
- CRL reachability: if the CRL lives behind the tunnel it protects, a strict check can block the tunnel that would fetch it.
They will ask next
Why do certificate tunnels often fail at a branch after a power cut?
The router boots with the wrong time, so peer certificates look not yet valid or expired, and IKE authentication fails until NTP corrects the clock. Make sure NTP is reachable without the tunnel.
Can the two sides use different authentication methods?
In IKEv2, yes: authentication is per direction, for example the hub signs with a certificate and a user authenticates with EAP. IKEv1 needs the same method on both sides.
Traps
- One PSK shared by every branch. One leak or one departing admin exposes the whole network.