Skip to content

Reminder: Set Your Clocks and Check Your SSL Certificates

Here in Seattle we follow Daylight Savings Time so today is the day to “fall back” by resetting the clocks 1 hour back. Because here have been so many “irregularities” in IT world regarding the calculation of Daylight Savings Time, it is also a great idea to quick-check your various servers and systems to verify they have the time “right”. The biggest cost of incorrect server time is not the absolute time issue (we often don’t care when a clock is off) bt the potential to make bigger mistakes by assuming time stamps are correct. Better to spend a few minutes making sure things are copacetic now, than get caught in a “gotcha” later because someone’s time stamp was actually off.

It is also a god time to re-evaluate your choice of SSL Certificates, for a few reasons. First, we humans tend to forget that SSL certificates expire, so we let them go until we get warnings that the SSL cert has expired. There’s no real god reason to work that way, if this simple reminder can get you to check your expiration date and execute any needed renewals now. We reset our clocks twice a year, so why not check your SSL certificate expiration dates twice a year? This is a particularly good time to do it, in advance of the shopping season. I am sure many of you will remember stories of merchants dealing with expired SSL certs last year during holiday crunch time. For homework, figure out when those annual renewals expire again this year ;-)

Another issue to consider is the compatibility of your particular SSL cert. I run several versions of most popular browsers routinely, and I am seeing more and more “invalid certificate” warnings these days, even from certificates bought through respectable vendors. Some advise that the difference in costs between the various SSL cert deals is purely a reflection of the dollar transaction insurance provided by the certificate vendor. A cert with $250,000 insurance does cost more than a cert with $100,000 insurance. But, there is also a cost associated with broad browser compatibility. Not all SSL certificate vendors provide certs that verify all browsers, and It seems certificate vendors may now be cutting corners by dropping support for older browsers.. I won’t name names here but you should check your certificate’s compatibility. If a user gets an invalid certificate message ater clicking “checkout now” you are likely to lose consumer confidence at best, if not a sale every time.
So Happy Daylight Savings Sunday: be sure to check your clocks and check your SSL certs.


  1. Suzanne wrote:

    you know this is something i always forget to do….until now!

    thank you so much for reminding me

    Monday, November 3, 2008 at 7:28 am | Permalink
  2. Cave Diving wrote:

    John, so what will it take for you to name names? That would certainly be useful to those of who are interested in that kind of business intelligence.


    @hansas I understand it the compatibility is on the shoulder of the signing authority, because browsers need to recognize the signing authority URL. So the cert issuers need to make sure they are backward compatible with what the browsers already trust. I saw Verisign come up in FF1.5 as untrusted just this month, for example, and that’s Verisign the mother of all signing authorities.

    Another example of Verisign wierdness: Verisign claims “universal browser compatibility” for their certificates (see  But if you go to their “Browser Check” page where it says:

    With one click, Browser Check instantly tells you: * What browser and version you’re using * Your browser’s encryption strength-standard 40-bit SSL, or 128-bit SSL: the strongest encryption available * Upgrade recommendations

    and click “check browser” using Firefox 3, it comes up with a manual selection request offering me choices of Netscape Communicator or Internet Explorer versions 4 and less. It apparently couldn’t recognize FF3 and thus can’t “auto detect”?  What does that mean for their certificates? It shouldn’t matter because they are supposed to present a root URL that is in the browser’s trusted signing authority list. But it does make me wonder if the signing authority is simply trusting that the Firefox folks will make sure their browser includes the appropriate URLs for Verisign, instead of the other way around (Verisgn maintaining backward compatibility with old browsers, and actually testing browsers before claiming “browser ubiquity”).

    Consumer science says the cert seller is responsible for “merchantability and fitness for purpose” and so I encourage buyers to question their vendors when compatibility is an issue. You can’t do that if you don’t check, and if you’re not checking (and the sellers aren’t checking) the only one losing a sale is you.

    Monday, November 3, 2008 at 2:40 pm | Permalink
  3. google had recent issues when a Gmail server ssl cert expired…one would think google would pay closer attention, but i guess we all make mistakes

    Sunday, December 21, 2008 at 11:56 am | Permalink
  4. Anonymous wrote:

    Thanks for the great advice, I never really paid much attention to the time stamps but I will certainly keep an eye on it from now. I also think it is terrible that vendors aren’t paying attention to older browsers.

    Monday, May 4, 2009 at 4:30 am | Permalink