I have an application that runs in mobile devices and connects to my server via HTTPS.

At times the connection fail because the device has a date set in the past (before the 'valid from' date on my certificate).

I can change the application code running on the mobile devices and also can change things on server side, how do I fix that?

I'm investigating 2 possibilities:

  • Pick the current date from the server response and change the client application to use that to validate the certificate ( I know the date is available at least from the "Date" http header). Can I / should I interfere in the validation process like that?

  • Try to buy a certificate valid since 1/1/1970 (which is the date some of the mobile clients assume) and up to 1 year from now. Do you see potential issues in that?

Any other options to go around this?

  • 1
    Another option would be to notify user that his time is incorrect and ask him to set it.
    – user43488
    Commented Apr 22, 2014 at 12:07
  • 1
    Your first suggestion rather defeats date validation entirely, as a server that is trying to "get away with" presenting an expired certificate merely need provide in its response headers a date for which that certificate would have been valid. If you wish to go this route, it would be better to obtain current date from an NTP server and validate against that: but can you trust the NTP response? As @edvinas.me suggests, notifying the user in such cases that their settings do not meet your security requirements (i.e. correctly set date) ought to suffice.
    – eggyal
    Commented Apr 22, 2014 at 12:36

1 Answer 1


Using the date from the server itself is self-defeating: a fake server could send a fake date.

Actually there is in SSL itself a field for the date: the first four bytes of the client_random and server_random fields contain the current date and time, as known by the client and the server, respectively. This implies the following:

  • A passive attacker, eavesdropping on the line, can detect clients whose clock is amiss.
  • An active attacker, running a fake server, can know the client's date and time, down to a precision of 1 second.

The attack scenario here is an attacker who has stolen an server's private key. The certificate has been revoked; however, the attacker also obtained CA certificates and CRL which "proved" the certificate to be valid at various previous dates. The attacker, in position to do MitM, then runs a fake server and emulates the Internet at that time, in particular sending back to the client the past CRL bearing the date that the client believes to be current.

An out of date client may make connections fail in case their current date is too far in the past, or too far in the future. The normal recovery for that case is to complain to the user, so that he sets the date and time properly. On a pure theoretical basis, there cannot be any other method which always works against MitM attackers: such an attacker can, as I said, "emulate" an old version of the Internet (as a whole), thus preventing the device from obtaining the true current date or even noticing that its clock is not set properly.

You could try to obtain a time stamp from some Time Stamp Authority; however, this implies validating the TSA certificate, or, more accurately, assuming that the TSA private key has never been stolen. So, in practice, it is possible to make a reasonably strong guess of the current date and time in a way which attackers will find difficult to fool. But that's expensive (extra connections to TSA) and depends on these external TSA, who might not be free and/or might not agree with getting so many time stamp requests from your deployed devices.

Edit: if you do revocation checks with OCSP, and the client insists on including a nonce in the request, then you get (somehow) the same property as with the TSA -- with the same caveats: you still have to assume that some entity's key has not been stolen (TSA, OCSP responder, CA...), and you still need to do extra connections.

  • Would get a certificate valid from 1970 (if that is even possible) have the same security issues? Commented Apr 22, 2014 at 14:30
  • The main security issue is that a client with a clock set in the past cannot reliably check for revocation status, at least not with CRL. Setting the validity start date to 1970 does not change this. Commented Apr 22, 2014 at 14:38
  • Also, the CAB Forum rules currently explicitly limit a subscriber (end-user) cert validity period to 5 years, and implicitly use the "not before" field as the time of issuance and hence the time ownership/entitlement was verified. Commented Apr 22, 2014 at 17:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .