Yeah the 5 minutes was a bit arbitrary, but a fairly safe bet. For instance, this is what Microsoft recommends. I added a commit to move it to a documented var.

I'm also surprised this is the first time we've seen it. I'm not sure, but it seems like the cert in question wasn't the SCEP cert, but a cert generated by the device (so maybe this was OTA enrollment? I don't really have any experience with that). The biggest reason I think that is because how else would this situation arise? If it was a SCEP cert, it would be generated by the server, so it wouldn't really matter what the device's time was. I think this would also answer the question of why it hasn't been seen yet: most people using MicroMDM are using DEP, so they would just use the SCEP cert to begin with. This particular issue occurred when someone was enrolling an Apple TV with Configurator.

Apologies if I'm not understanding these processes correctly; I've read through the wiki and the OTA code, but I'm still not 100% clear on the process. Would it even make sense to see a device-generated cert on the /mdm/checkin endpoint?

Assuming I am correct above, then adding a skew (of 5 minutes or whatever) makes a lot of sense. If a device is generating it's own cert on the fly, if it's just a few seconds ahead of the server, then it will be out of the validity period. When @tgunz synced his server with NTP, it was only 2 seconds offset, and that was enough to allow the device to enroll.

To recap our discussion of this PR during office hours today:

• The issue is not to do with devices generating their own certificates (in both the normal and OTA enrollments, the device uses a SCEP cert)
• The issue is because the device is generating pkcs7 signatures for requests, and clock skew between the device and the server is causing the signatures to be invalid
• Because the issue seems to occur rarely, the clock skew is now behind an adjustable (default off) flag

After doing some testing, I'm less convinced that a configurable skew (or skew at all) is needed.

Despite adding a manual skew of several hours in both directions on the server, MicroMDM seems to have no issue verifying requests on /mdm/checkin. It does seem like MicroMDM is using this modified time, as the DEP API doesn't like being on the wrong time. This differs from the results @tgunz was seeing, but I'm, as of yet, unable to reproduce the error. I'd like to eventually dump the pkcs7 data to see what actually comes in, but that's an exercise for another day.

For now, I suggest we merge this PR, which I've rebased to only contain the go-kit error logging fix, as we know that's definitely an issue and an easy fix.

I've kept the skew flag code on this branch. If this does end up becoming a visible issue now that the error logging is fixed, we can address those changes again.

Now that this is merged I came across #406 again fwiw — sort of related to errors being hidden and such. 🤷