A new WAN Edge at a warehouse shows DTLS down to the SD-WAN Controller and SD-WAN Validator, its system clock is 18 minutes behind, its certificates were issued 10 minutes ago and the organization name matches. Underlay ping to controllers succeeds. Which control-plane connectivity issue should the engineer fix first to restore secure peering?

DTLS control peering requires valid time for certificate authentication, so an 18-minute lag causes handshake failure even though the organization name matches, because the edge clock is earlier than the not-before time of the freshly issued certificates, so they are not yet valid at the edge, making NTP synchronization the first fix. Changing to TLS over TCP 443 is legitimate when firewalls filter UDP needed for DTLS, but it fails here because ping to controllers shows underlay reachability without UDP-block evidence, and TLS performs the same time checks so skew still blocks peering. Refreshing the trusted root bundle from the enterprise CA is standard when the chain is expired or re-issued, but it fails here because the matching organization and fresh issue date show the chain is not the problem and time, not chain content, is breaking authentication. Bouncing control connections and adjusting OMP timers suits transient flaps or hold-time expiry, but it fails here because simultaneous failure to both controller roles with good ping points to a common authentication factor that reinitiation alone cannot correct. For exams, separate reachability from authentication since ping validates path while DTLS validates identity and time, and in practice compare show clock to controller time, verify NTP synchronization, then recheck DTLS sessions and certificate dates.