micromdm/nanomdm

Allow tolerance for pkcs7 signing time during device enrolment

Opened this issue · 2 comments

An iPad failed to enrol due to a clock issue, most likely due to the iPad's clock not having properly synced yet (server clock confirmed correct and NTP synchronised).

level=info handler=cert-extract trace_id=7dc2a24bd394756e msg=verifying Mdm-Signature header err=pkcs7: signing time "2023-04-07T00:16:58Z" is outside of certificate validity "2023-04-07T00:16:59Z" to "2033-04-04T00:16:59Z" caller=mdm_cert.go: 92

As the iPad was enrolled in DEP and management was mandatory, this left the following consequences:

  • The iPad retried enrolment using the enrolment profile it had already obtained (it doesn't try and get another one)
  • The SCEP one-time challenge had therefore already been used, so certificate enrolment now failed
  • The iPad required erasure by connecting to a Mac and issuing the command with Configurator 2

While chances of this happening are small, it can leave users in a tricky situation with regards to recovering the device.

A tolerance on the signing time when checking against NotBefore of around 2-5 seconds is proposed to mitigate this event.

It's funny you bring this up. This was a topic in the #micromdm channel with @korylprince a few days back and resulted in micromdm/micromdm#871. Part of the discussion was that the code has been like this for however many years the MicroMDM project has been a thing and we hadn't heard of it (though, admittedly, because the errors were effectively hidden it's hard to rule out that people just weren't seeing the error).

Anyway a couple notes/questions:

of around 2-5 seconds is proposed to mitigate this event.

Can you give a basis for your recommendation of 2-5 seconds here? Kory suggested five minutes (in the issue). I'm curious why you couldn't just wait for NTP to sync and re-attempting enrollment?

Secondly since this is NanoMDM and because of our previous Slack conversations I'd highly suggest taking a look at using mTLS (instead of relying on the Mdm-Signature header). This is enabled in NanoMDM by using the -cert-header flag and requires your upstream proxy to hand over the header containing the certificate. I think mTLS is a much better option than the Mdm-Signature header if you can afford it in your environment.

See relevant discussion in smallstep/pkcs7#21.