Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow tolerance for pkcs7 signing time during device enrolment #73

Open
alwatts opened this issue Apr 8, 2023 · 2 comments
Open

Allow tolerance for pkcs7 signing time during device enrolment #73

alwatts opened this issue Apr 8, 2023 · 2 comments

Comments

@alwatts
Copy link

alwatts commented Apr 8, 2023

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.

@jessepeterson
Copy link
Member

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.

@jessepeterson
Copy link
Member

See relevant discussion in smallstep/pkcs7#21.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants