Mist AP error “Cloud cert time check failed”

I decided to move my home Wi-Fi to HPE Juniper Mist after hearing so many good things about it from the community. An industry friend was kind enough to lend me three unused AP43’s he had. These things were mint-in-box, he had not used them. So I excitedly “claimed” them in my Mist dashboard and hooked them up, but the excitement was shattered when the dashboard told me “Cloud cert time check failed”. Here is how I fixed it.

If I hovered over the error in the Mist dashboard I got a bit more information – “NTP time is not within cert’s not-before/not-after times”. My friend got these AP’s very early on. Given the error I encountered I am suspecting they were some of the first production AP43’s. And as a result the embedded cloud cert has expired and cannot be used to connect to the cloud. This assumption is mine, the Mist support team did not confirm the reason, just how to fix it.

The fix was relatively simple if you’re comfortable with switching and routing. I had to block UDP port 123 (the NTP service) on my access point VLAN.

Mist also advised disabling the NTP service or removing the NTP options from the DHCP scope, but I suspect this was unneeded so long as NTP couldn’t get in or out of the AP VLAN. I did both to be sure and if the above doesn’t work for you then its probably best to complete this extra step.

Putting all these pieces together this is my assumption of the what the problem is. Blocking NTP on the VLAN stopped the AP getting an up-to-date timestamp forcing it to use the one it had on its internal clock. As the AP hardware was so old this timestamp was within the certs validity period and it could use this to connect to the cloud. Once it saw the cloud it could get a new firmware with updated certs.

If you’re wondering if the AP being connected to the network before you had found this post and therefore already having an up to date timestamp, don’t worry. This is the situation I was in. Another assumption of mine is that the timestamp is thrown away when you power cycle the AP and it tries to get a new one, fails, and uses a hard coded timestamp.

I’ve not yet removed the ACL blocking port UDP 123 but I intend to do that once all three of these AP’s is up and upgraded. If I do that and it causes the issue again then I’ll come back here and update the post. If there is no update then you’re safe to go ahead and remove the ACL once you’ve fixed your problem.

I hope this helps someone!