NTP is a fairly straightforward protocol, and unless you are using some of the more esoteric NTP options, there is little that can go wrong; however, if it does break, it can create problems with other services–for example, the aforementioned certificate validation. Therefore, you shouldn't overlook the possibility of an NTP failure.
Checking to make sure the preferred NTP server is up is always a good idea, and you can do that with the ntpq –p command. You can do this by typing the following at the console shell (or just navigate to Diagnostics | Command Prompt and type this in under Execute Shell command):
ntpq –p HOSTNAME
Where HOSTNAME is the hostname of the site whose NTP server we wish to query. If HOSTNAME is omitted, the local NTP server is queried. Running this query will result in output something like this:
As you can see, running this command produces a wealth of information about the local NTP server. remote is the IP address of the remote NTP server, while refid is the IP address of the time source to which remote is synced. st is the stratum of the remote NTP server, and t is its type (in this case, u for unicast). when is the number of seconds elapsed since the remote NTP server was polled, while poll is the polling interval (both these fields are in seconds).
reach is an 8-bit left-shifting register, which indicates success or failure within connecting with the NTP server. A 1 indicates success, while 0 indicates failure. The register is presented in octal format. The octal value of 377 is 11111111 in binary, indicating here that the last 8 attempts to connect to the NTP server were all successful.
delay is the time delay in milliseconds to connect to the NTP server, while offset is the offset between local and remote time. Finally, jitter is the observed jitter of time with the remote server.
If you are trying to set up a GPS or PPS device as a reference clock, this can create a host of potential causes. One possibility is to try temporarily disabling these devices (with the Do not use this clock option) and see whether it solves your NTP problems. If it does, then you know you have to revisit your GPS and PPS settings. If you are using a GPS device, it is possible that you selected the wrong GPS type or wrong option for NMEA sentences. It is also possible that your GPS device is not supported by your version of pfSense. If so, you may still be able to get it to work by manually entering the GPS initialization commands.
PPS devices are a bit more straightforward, but you may want to try checking the Enable PPS clock discipline checkbox and see whether it resolves your problem. You may also want to try changing signal processing from the rising edge of the pulse to the falling edge.