4 ms·

Why client does not accept certificate from the future? What attack is supposed to be prevented?

toast0 6y ago
X.509 cerrificates have a not before and a not after date, so validators check them. It's a real pain when you have to let a certificate sit for a day to compensate for clients with poorly set clocks or poorly written date comparisons.
- tialaramex 6y ago
  Google's experiments suggest that the vast majority of clients are off by an hour (incorrect "daylight saving" adjustments / next door's timezone) or less. They did do work on having clients with Internet access just bootstrap a roughly correct time from first principles, but I don't know if Chrome/ Android do this out of the box. Public Issuers generally backdate certificates by a small amount of time to allow for that one hour. This is permitted (unlike backdating to avoid other rules) by the Baseline Requirements, so you should find you don't need to wait before using the certificates you are issued.
  - toast0 6y ago
    > so you should find you don't need to wait before using the certificates you are issued. Thanks, but no. I had to wait about 12 hours to deploy replacement certificates after Heartbleed, in order to balance cert errors with loss of privacy. A large number of the clients I had to support interpret the dates as local time, which isn't helpful when they're in the western hemisphere and GoDaddy wouldn't backdate certs at all. Last I had a cert issued, DigiCert set not before to the order time even for re-issues or duplicates, so that was a lot easier to manage.
- a1369209993 6y ago
  This is true, but doesn't actually answer the question of what attack respecting the not-before date is supposed to prevent.
  - londons_explore 6y ago
    I think the 'attack' is allowing certificate issuers to work around validity rules by issuing a certificate that begins in 2098 and ends in 2099.
- deleted 6y ago
  [deleted]

X.509 cerrificates have a not before and a not after date, so validators check them. It's a real pain when you have to let a certificate sit for a day to compensate for clients with poorly set clocks or poorly written date comparisons.

tialaramex 6y ago
Google's experiments suggest that the vast majority of clients are off by an hour (incorrect "daylight saving" adjustments / next door's timezone) or less. They did do work on having clients with Internet access just bootstrap a roughly correct time from first principles, but I don't know if Chrome/ Android do this out of the box. Public Issuers generally backdate certificates by a small amount of time to allow for that one hour. This is permitted (unlike backdating to avoid other rules) by the Baseline Requirements, so you should find you don't need to wait before using the certificates you are issued.
- toast0 6y ago
  > so you should find you don't need to wait before using the certificates you are issued. Thanks, but no. I had to wait about 12 hours to deploy replacement certificates after Heartbleed, in order to balance cert errors with loss of privacy. A large number of the clients I had to support interpret the dates as local time, which isn't helpful when they're in the western hemisphere and GoDaddy wouldn't backdate certs at all. Last I had a cert issued, DigiCert set not before to the order time even for re-issues or duplicates, so that was a lot easier to manage.
a1369209993 6y ago
This is true, but doesn't actually answer the question of what attack respecting the not-before date is supposed to prevent.
- londons_explore 6y ago
  I think the 'attack' is allowing certificate issuers to work around validity rules by issuing a certificate that begins in 2098 and ends in 2099.
deleted 6y ago
[deleted]