Four new WAN Edges at a warehouse fail to establish control connections after a template push. SD-WAN Validator is reachable, certificates show valid, organization name matches, but logs show TLS errors and the devices are five minutes behind NTP. Which control-plane connectivity failure reason explains this onboarding symptom?

The correct explanation is clock skew: SD-WAN control connections use DTLS/TLS with X.509 certificate validation, which checks system time against each certificate’s not-before and not-after window. WAN Edges five minutes behind NTP can therefore fail the handshake with TLS errors even when the Validator is reachable, certificates appear valid, and the organization name matches. Installing a missing root CA chain addresses trust-anchor validation, but does not explain the stated time skew; the certificate chain can be intact while time-window validation still rejects a handshake. Updating authorized serial numbers addresses chassis authorization, but an unauthorized chassis would produce authorization rejections, not explain TLS errors correlated with a shared five-minute clock offset. Rolling back the template push addresses possible configuration drift, but template parameters or policy attachment do not explain certificate time-validation failures associated with NTP skew. Exam caveat: distinguish a correctly issued certificate with a matching organization from one that is currently time-valid; TLS log mentions can tempt you to reissue certificates or change trust settings unnecessarily. Practical check: compare show clock and show ntp associations on a WAN Edge with the Manager and Validator, correct the NTP source and offset, force synchronization, then monitor the control logs for successful DTLS/TLS establishment.