An OT vendor's site-to-site IPsec tunnel to a substation was working for months, but after the vendor rotated their edge device's certificate, the tunnel stopped establishing phase 1 entirely. Which explanation best accounts for this specific failure pattern?
Select an answer to reveal the explanation.
Short Explanation
If everything worked fine until the certificate got rotated, the certificate itself is the obvious suspect: the substation FortiGate simply doesn't trust the new one yet. That's a phase 1 identity problem, not something to do with subnets, DH groups, or timers.
Full Explanation
The most direct explanation for a phase 1 failure that begins precisely when a certificate is rotated is that the substation FortiGate does not yet trust the new certificate — either because the new certificate was issued by a CA the FortiGate doesn't have in its trusted CA store, or because the FortiGate's phase 1 configuration still references or pins the old certificate's identity, and certificate-based authentication requires the validating side to trust the presented certificate's chain before the peer relationship can be authenticated. Phase 2 selectors define the subnets considered interesting traffic for encryption and are configured independently of which authentication method or certificate is used; a certificate rotation has no mechanism to automatically alter selector definitions, so a selector mismatch would not explain a failure that started specifically at rotation time. The DH group is a phase 1 cryptographic negotiation parameter chosen by administrators and has no dependency on certificate rotation — swapping a certificate does not force, trigger, or require any DH group change on either peer. Dead peer detection timers are unrelated to certificate trust; DPD governs how the FortiGate checks whether an already-established peer is still responsive, and there is no concept of a 'cached DPD timer' tied to a specific certificate that would block a new session from forming. The practical fix and verification step is to confirm the new certificate's issuing CA is present under 'config vpn certificate ca' on the substation FortiGate and to check 'diagnose vpn ike gateway list' or the IKE debug log for a certificate validation failure at the exact time the tunnel stopped negotiating.