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