Recently I accidentally changed the system time to a different month, and then I surfed to a secure site. I got a warning from Google Chrome that mentioned my system time and said the certificate isn't valid.

If I have a valid certificate which is ok for a time period that had already passed and I'm able to change the system time, what would happen? Would it work ok? Would there be a warning anyway?

Explanations would be welcomed.

  • Just a note, SSL certificates continue to encrypt data even after the expiration date. – k1DBLITZ Nov 29 '12 at 20:38

Verification of certificates entails checking several dates with regards to "the current time" as known by the system which does the verification (i.e. your desktop or laptop). In particular, your system will try to obtain fresh revocation information (the CRL). If your system clock is off, it will not consider whatever CRL it can download as "fresh"; it may spew out scary warnings, in particular if it sees a CRL "from the future".

Also, in SSL/TLS, the client and the server inform each other of their notion of the current time. There again, discrepancies could be warned upon.

To sum up, changing your clock to accept a certificate which has expired may "work", but not "work well". This, of course, depends on the leniency of your browser with regards to certificate validation, so the best course of action for your particular problem is to test it. Create your own CA, issue a server certificate with an expiry date on the past, install your CA as a trusted CA in your browser, set the clock back, connect to a test server which uses your expired test certificate, and see what happens. Anyway, this would hardly be a reasonable setup for production uses (asking your customers to set their clock back is kind of, let's say, commercially suboptimal).

| improve this answer | |

SSL certificates serve a primary purpose of attesting to a client that they have connected to the correct site that they were trying to reach. It is up to the client to check the time the certificate is valid against their own time. Since your time ended up ahead by a month, you probably browsed to a site that was nearing needing to replace their SSL certificate and so your browser thought it invalid. If you changed the time on the server, the server would think it ok, but any clients connecting would have the actual time and reject the certificate as out of date.

| improve this answer | |
  • Thanks for the answer, the time in my computer (client) was not ahead it was set to half a year ago.And i asked if this is the case and a site shows a valid certificate for this data but not valid to the current date (let's say it expired 3 months ago) would it pass o.k? – TheNewOne Nov 29 '12 at 13:48
  • 1
    An SSL cert is valid for a period of time (has a start and end date) if the time your client uses is not in that time range, an error will be indicated. If the time your client is using is within the range the certificate is valid for, it will indicate that the certificate is valid(as long as other checks also pass). – AJ Henderson Nov 29 '12 at 14:17

If you change the system time, the certificate will be considered invalid if the browser or software you are using uses local system time as it's time source. There are some pieces of software which use remote systems for time sources and are thus not affected by a local time change, however this is rare.

The reason that this is done is because certificates can be cracked via a brute force, but that takes time and substantial CPU cycles. Usually you will see a 1 year time span for public SSL certificates, but they can be as high as 4 years with most large vendors (VeriSign, Thawte, etc.). The theory is that it is "impossible" for the private key associated with the public key (public key = certificate) to get brute forced within 1 year. Therefore the Certificate Authorities refrain from saying that this certificate is valid forever, because in 10 years it is very possible that this could be cracked because 1 - 10 years has gone past and 2 - it is assumed that CPUs will be much more powerful as time goes on (Moore's law/Rose's law).

To answer your question more directly - yes, the certificate would "work o.k," if by ok you mean that it will encrypt your communications, as long as you accept the risk (risk = warning) that this is not a legitimate server (Possible impersonation or communication interception/Man in the middle). If you change your clock back to the correct time, and there are no warnings (and you haven't said to permanently allow the exception in your browser), you can be reasonably assured that you are not the victim of an attack. What will not be assured is the "authentication" portion of SSL, where the server is being vouched for by the Certificate Authority, if you are required to click "accept."

If you want more details please let me know. I'm not sure what else you'd be interested in.

| improve this answer | |

As suggested by the previous answers ran a simulation with different time setting. (Advanced the local clock ahead of the certificate expiry date). Here we go!

SSL after changing the client time

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.