Hello Jon, I have addressed this with other customers by having a script that saves the current date/time every minute.  At startup it checks to see if the current date is before a certain date, if so restores the last known date/time (from file) - this should allow you to connect to the network, then you can resync to the correct time.

John, Here are some work arounds for the situation your customer has encountered- 1) If using AppCenter, create a desktop item that provides end-users access to the time/date function. The AppCenter manual includes the instructions on how to add this by configuration settings.  End users can then set current date and/or time so that the cert becomes valid. 2) Create a script or simple application that runs on boot to check the date- if the date is prior to the certificate's valid start date, have the script or application set the current date to match the start date of the certificate.  Once the wireless network connection is authenticated- have the script or application set the current date and time from a network or internet resource and terminate. 3) Have your customer create certificates with start dates that match the cold boot default and install. NOTE:  Security policies or personell at your customer will most likely have strong opinions about the #2 and #3 options.  Be certain to balance your discussion between the defaults of the operating system and the resources available while unauthenticated to the wireless network in balance with end-user needs for simple use.  You can always work up more complex solutions- for example dropping the unit in a network attached cradle so that a script or application can access time and certificate resources securely over the wired infrastructure prior to wireless access.

The new Certificate Settings Class within MSP v3.3 has functionality to automatically adjust the date/time to be inside the range of an install certificate. This is from page 75 of the understanding MSP v3.3 guide…

 

Each Certificate Settings Object can configure one or more of the following settings:

 

Device date and time:

This determines whether the date and time on the device should be adjusted, if needed, to allow the proper installation of the Certificate. The possible values are:

 

Do not change

This indicates that no attempt to adjust the date and time on the device will be made. If the current date and time set on the device is outside the laceType w:st="on">Range laceType> of laceName w:st="on">Operational Validity laceName> for the Certificate, then the installation of the certificate will fail.

 

Set to certificate NotBefore time, if necessary

This indicates that a check should be made to determine if the current date and time set on the device is inside or outside the laceType w:st="on">Range laceType> of laceName w:st="on">Operational Validity laceName> for the Certificate. If the current date and time set on the device is inside the laceType w:st="on">Range laceType> of laceName w:st="on">Operational Validity laceName> for the Certificate, then it will be left alone. If the current date and time set on the device is outside the Range of Operational Validity for the Certificate, then the current date and time of the device will be changed to be the beginning date and time of the Range of Operational Validity for the Certificate.

 

Important:

While changing the current date and time of the device to fall within the laceType w:st="on">Range laceType> of laceName w:st="on">Operational Validity laceName> for the Certificate will allow the Certificate to be installed successfully, it generally will not result in the correct date and time being set on the device. But if a Certificate is required to get on the network so the time can be synchronized properly, setting the date and time on the device based on the Range of Operational Validity of the Certificate can be a good mechanism to enable bootstrapping, especially during Staging.