On Friday evening (JST) I was reviewing the website of a company dealing with currency trading. No problems. On Saturday morning try I go back to the site, but both Chrome and Safari say they don't trust the security certificate. I checked it and the validation had expired. Odd that.

Screen Shot 2016-08-13 at 11 - Safari

Then this morning, I visited the site again and the certificate is valid and I can get in (on both Chrome and Safari)

Screen Shot 2016-08-14 at 7 - Chrome

Then I noticed a quirk.

With the failed certificate, the notice said the certificate expired Saturday Aug 13, 2016 at 8:59:59 JST.

But with today's valid certificate the notice says the the certificate is valid from Aug 13 2016 00:00:00 GMT.

I did a check of the time difference and 8:59:59 JST is 23:59:59 GMT (note: the UK is on summer time)

Time zone difference

Is this a problem with how browsers check certificate validity? Do they always assume the expiry time is 23:59:59 and the validity time is 00:00:00, but never check if there is a time zone difference or a summertime difference?


My guess is that the website's certificate actually expired, and then they bought a new one and replaced it before you checked again.

When Comodo issues a certificate, the "valid from" time is backdated to 00:00:00 UTC the day it was issued, and the "valid until" time is 23:59:59 the day it expires. So the new certificate could have been issued any time of the day on August 13.

(That's just Comodo's particular policy. Other CAs handle it differently.)

It's a bit late to try to prove this now, but you could search for the domain on a tool like Censys and see if they have a copy of yesterday's certificate.

Hypothetical timeline:

  1. 2016-08-12 21:00:00 JST (2016-08-12 12:00:00 UTC): You visit the website successfully. The old certificate will expire at 2016-08-13 08:59:59 JST (2016-08-12 23:59:59 UTC), 11:59:59 from now. The sysadmins have no idea.
  2. 2016-08-13 08:59:59 JST (2016-08-12 23:59:59 UTC): The old certificate expires. All of the sysadmins are asleep.
  3. 2016-08-13 10:00:00 JST (2016-08-13 01:00:00 UTC): You visit the website and get an error. The old certificate expired 01:00:01 ago. The sysadmins are still asleep.
  4. 2016-08-13 15:00:00 JST (2016-08-13 06:00:00 UTC): The sysadmins wake up, notice that they blew it, and scramble to replace the certificate. The new one is valid starting 2016-08-13 09:00:00 JST (00:00:00 UTC).
  5. 2016-08-14 07:00:00 JST (2016-08-13 22:00:00 UTC): You visit the website again. The new certificate is, of course, valid.
  • 1
    You're correct. Censys says: Validity Period: 2015-08-13 00:00:00to 2016-08-12 23:59:59 (365 days, 23:59:59) – mycowan Aug 15 '16 at 9:00
  • Okay here's another newbie question. With security certificates is there a propagation delay like there is with changes of DNS addresses? – mycowan Aug 15 '16 at 23:48

never check if there is a time zone difference or a summertime difference?

The expiration time of a certificate is set in GMT (UTC). What you see is the difference of how different browsers present expiration time of the certificate, i.e. Safari transforms it to JST (probably your local time zone) while Chrome shows it in GMT. The check itself is done by comparing both time within the same time zone, i.e. usually comparing the local time to GMT before checking.

Do they always assume the expiry time is 23:59:59 and the validity time is 00:00:00,

The expiration time has a precision of seconds and browsers check it this way. Also some CA might set the expiration time to 23:59:59, others don't.

  • That's true. Still both said the certificate was invalid Saturday morning, but now the certificate is valid and there is no gap in the validity. – mycowan Aug 14 '16 at 5:47
  • 1
    @mycowan: Given the timestamps there was no gap, But it looks like that the new certificate was not installed on time. It does not matter if they already have the renewed certificate if the server still provides the old certificate. – Steffen Ullrich Aug 14 '16 at 7:13
  • Well, there would have been a one second gap in any case. – Matt Nordhoff Aug 14 '16 at 7:24
  • @MattNordhoff: when exactly would this gap be? The one certificate is valid until and including 23:59:59 while the other is valid from (and including) 00:00:00 and the granularity for the checks is one second. – Steffen Ullrich Aug 14 '16 at 10:11
  • @SteffenUllrich My mistake. I thought they stopped being valid at 23:59:59.0, not after 23:59:59.9. – Matt Nordhoff Aug 14 '16 at 10:48

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.