System time and certificates

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).

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.