I'll try to respond to the few questions on the topic in this one email. In the case below, the customer ordered a 39 month certificate and set the notBefore date for 2 months into the future. The notAfter is within the allowed 39 month validity as measured from time of issuance. Posting the precertificate to CT helps document the actual issuance date as "proof".
We permit customers to set a notBefore date into the future, possibly for the reason listed below, but there could be other reasons. We will never permit the notAfter date ever exceed 39 months from the issuance date (and soon this will be 825 days). As Jonathan pointed out, "the certificate issued was valid for 1129 days (more than three years)" but the expiration date is less than 39 months from the date of the SCT (by a few seconds). - Date posted to CT logs: 2018-01-23 09:32:50 - NotAfter: 2021-04-23 09:32:47 Not renewing a month earlier isn't a valid use case since the notAfter never violates the BR max validity as measured from issuance time to expiration time. We don't allow customers to set the notBefore date into the past. And regarding the Mozilla checks for https://bugzilla.mozilla.org/show_bug.cgi?id=908125, perhaps the "notBefore" date used in the check should be the earlier of the certificate NotBefore or the date the included SCT was created. I don't know how Chrome would handle this certificate, but if it marks it as invalid, it would be good to know so we can relay this to customers that have set the notBefore date after March 1st. Doug > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign....@lists.mozilla.org] On Behalf Of Gervase > Markham via dev-security-policy > Sent: Wednesday, January 24, 2018 5:05 AM > To: David E. Ross <nobody@nowhere.invalid>; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: Re: GlobalSign certificate with far-future notBefore > > On 24/01/18 04:57, David E. Ross wrote: > > I am not sure about prohibiting forward-dating the notBefore date. I > > can picture a situation where an existing site certificate is going to > > expire. The site's administration decides to obtain a new certificate > > from a different certification authority. Because of various > > administrative processes, the switch to the new site certificate > > cannot be accomplished quickly (e.g., moving the server); so they > > establish a notBefore date that is a month in the future. > > Why would that be _necessary_? What would go wrong if the cert was cut > with a notBefore of the current date, apart from the fact that they'd need to > renew it a month earlier? > > Gerv > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
