3 ms·
Yes, but the relevant portion of the RFC for inclusive time ranges is > CAs conforming to this profile MUST always encode certificate validity dates through th
by gpm 5y ago
Yes, but the relevant portion of the RFC for inclusive time ranges is
> CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime; certificate validity dates in 2050 or later MUST be encoded as GeneralizedTime. Conforming applications MUST be able to process validity dates that are encoded in either UTCTime or GeneralizedTime.
> The validity period for a certificate is the period of time from notBefore through notAfter, inclusive.
The way I'm reading this a conforming application must first decode the date to a point in time, and then must perform an inclusive check on that decoded date as a point in time.
The certificate expiring at 10:00:00 is not valid at 10:00:00.0001, the restrictions on the time format are just saying you can't make a certificate that is valid at 10:00:00.0001 and not valid at 10:00:00.0002.
So the fence post error "exists" here, but the size of it is t = limit granularity as granularity goes to 0 = 0...
- grumple 5y agoIn fact, your post makes it clear that a certificate expiring at 09:59:59 presents a problem too; there's a whole second where checks may be invalid before 10:00:00. This would depend on the browser implementation which is not specified in the RFC (I checked). Hopefully they all do truncation of fractional seconds. The easiest fix though, is for LetsEncrypt to say their certs are valid for 90 days and a second.
- mkishi 5y agoIf that's the case, the previous implementation was correct and they'll start issuing certificates with 90 days - 1 second now.