GlobalSign certificate with far-future notBefore

[Jonathan Rudenberg]

A certificate issued by GlobalSign showed up in CT today with a notBefore date of March 21, 2018 and a notAfter date of April 23, 2021, a validity period of ~1129 days (more than three years).

https://crt.sh/?id=311477948&opt=zlint

CA/B Forum ballot 193 modified the Baseline Requirements to set a maximum validity period of 825 days for certificates issued after March 1, 2018.

While the BRs do not appear to have any rules about forward-dating certificates, Mozilla’s CA Forbidden or Problematic Practices say:

> Certificates do not contain an issue timestamp, so it is not possible to be certain when they were issued. The notBefore date is the start of the certificate's validity range, and is set by the CA. It should be a reasonable reflection of the date on which the certificate was issued. Minor tweaking for technical compatibility reasons is accepted, but backdating certificates in order to avoid some deadline or code-enforced restriction is not.

https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date

This incident makes me think that two changes should be made:

1) The Root Store Policy should explicitly ban forward and back-dating the notBefore date.
2) Firefox should implement a technical check to enforce the validity period so that issuance practices like this do not impact users (see https://bugzilla.mozilla.org/show_bug.cgi?id=908125)

Jonathan

[David E. Ross]

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.

--
David E. Ross
<http://www.rossde.com/>

President Trump: Please stop using Twitter. We need
to hear your voice and see you talking. We need to know
when your message is really your own and not your attorney's.

[Gervase Markham]

Hi Jonathan,

On 23/01/18 22:55, Jonathan Rudenberg wrote:
> A certificate issued by GlobalSign showed up in CT today with a notBefore date of March 21, 2018 and a notAfter date of April 23, 2021, a validity period of ~1129 days (more than three years).

Thank you for pointing this out. This does seem at first look like an
attempted end-run around the 825-day validity period restriction which
comes into effect soon. Perhaps GlobalSign would care to comment here?
If not, I can file a bug and make a formal request.

> 1) The Root Store Policy should explicitly ban forward and back-dating the notBefore date.

I am not opposed to this, but I would want to allow CAs to make
representations about when this is necessary so we can see if any
exceptions do actually need to be made. But a general rule might be a
good idea.

> 2) Firefox should implement a technical check to enforce the validity period so that issuance practices like this do not impact users (see https://bugzilla.mozilla.org/show_bug.cgi?id=908125)

Does Chrome already do this? If so, I might expect this cert, once it
becomes valid, not to work in Chrome...

Gerv

[Gervase Markham]

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

[Rob Stradling]

On 23/01/18 22:55, Jonathan Rudenberg via dev-security-policy wrote:
<snip>

> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdating_the_notBefore_Date
>
> This incident makes me think that two changes should be made:
>

> 1) The Root Store Policy should explicitly ban forward and back-dating the notBefore date.

I think it would be reasonable and sensible to permit back-dating
insofar as it is deemed necessary to accommodate client-side clock-skew.

> 2) Firefox should implement a technical check to enforce the validity period so that issuance practices like this do not impact users (see https://bugzilla.mozilla.org/show_bug.cgi?id=908125)
>

> Jonathan

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Doug Beattie]

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=globals...@lists.mozilla.org] On Behalf Of Gervase
> Markham via dev-security-policy
> Sent: Wednesday, January 24, 2018 5:05 AM
> To: David E. Ross <nob...@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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Gervase Markham]

Hi Doug,

Thanks for the quick response.

On 24/01/18 11:52, Doug Beattie wrote:
> In the case below, the customer ordered a 39 month certificate and
> set the notBefore date for 2 months into the future.

Momentary 2017/2018 confusion in my brain had me thinking that this was
further into the future than it actually was. But yet still, it is the
other side of a reduction in certificate lifetime deadline.

> We permit customers to set a notBefore date into the future, possibly
> for the reason listed below, but there could be other reasons.

So if a customer came to you today and renewed their certificate for
www.example.com with validity from 24th Jan 2017 to 24th Apr 2020
(perfectly fine), and then requested a second 39-month certificate valid
from 24th Apr 2020 to 24th July 2023, would you issue this second one?

Gerv

[Doug Beattie]

> -----Original Message-----
> From: Gervase Markham [mailto:ge...@mozilla.org]
> Sent: Wednesday, January 24, 2018 7:00 AM
> To: Doug Beattie <doug.b...@globalsign.com>; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: GlobalSign certificate with far-future notBefore
>

> Hi Doug,
>
> Thanks for the quick response.
>
> On 24/01/18 11:52, Doug Beattie wrote:

> > In the case below, the customer ordered a 39 month certificate and set
> > the notBefore date for 2 months into the future.
>

> Momentary 2017/2018 confusion in my brain had me thinking that this was
> further into the future than it actually was. But yet still, it is the other side of a
> reduction in certificate lifetime deadline.
>

> > We permit customers to set a notBefore date into the future, possibly
> > for the reason listed below, but there could be other reasons.
>

> So if a customer came to you today and renewed their certificate for
> www.example.com with validity from 24th Jan 2017 to 24th Apr 2020
> (perfectly fine), and then requested a second 39-month certificate valid from
> 24th Apr 2020 to 24th July 2023, would you issue this second one?

No, we would not issue that certificate. In no case would we issue a certificate that has a notAfter more than 39 months from today, which is currently 24 Apr 2021.


> Gerv

[Ryan Sleevi]

On Wed, Jan 24, 2018 at 7:05 AM Doug Beattie via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
>
> > -----Original Message-----
> > From: Gervase Markham [mailto:ge...@mozilla.org]
> > Sent: Wednesday, January 24, 2018 7:00 AM

> > To: Doug Beattie <doug.b...@globalsign.com>; mozilla-dev-security-
> > pol...@lists.mozilla.org
> > Subject: Re: GlobalSign certificate with far-future notBefore
> >

> > Hi Doug,
> >
> > Thanks for the quick response.
> >
> > On 24/01/18 11:52, Doug Beattie wrote:

> > > In the case below, the customer ordered a 39 month certificate and set
> > > the notBefore date for 2 months into the future.
> >

> > Momentary 2017/2018 confusion in my brain had me thinking that this was
> > further into the future than it actually was. But yet still, it is the
> other side of a
> > reduction in certificate lifetime deadline.
> >

> > > We permit customers to set a notBefore date into the future, possibly
> > > for the reason listed below, but there could be other reasons.
> >

> > So if a customer came to you today and renewed their certificate for
> > www.example.com with validity from 24th Jan 2017 to 24th Apr 2020
> > (perfectly fine), and then requested a second 39-month certificate valid
> from
> > 24th Apr 2020 to 24th July 2023, would you issue this second one?
>
> No, we would not issue that certificate. In no case would we issue a
> certificate that has a notAfter more than 39 months from today, which is
> currently 24 Apr 2021.

That’s purely a business decision, right? I couldn’t see anything in the
BRs prohibiting a CA from doing this, particularly given how validation
data is allowed to be reused, but I’m curious if GlobalSign reached a
different decision.

>
>

[Ryan Sleevi]

On Wed, Jan 24, 2018 at 6:52 AM Doug Beattie via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> 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.

This has a variety of both technical problems (e.g. when logs are
disqualified) and policy problems (using CT as a trusted timestamping
service rather than disclosure) that makes this, as a practical matter,
non-viable.

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.

As of Chrome 66, It will be rejected as an invalid certificate and users
will be forced to click through. I would have included this in Chrome 65 or
earlier, but in general, I try to land enforcement code in a way that it
rolls out approximate to the transition date, in the event of any issues.
The use of the notBefore as a proxy for issuance date has been a behavior
of a Chrome for nearly 5 years now, and was originally behavior contributed
by Opera, which had similar checks even longer.

In general, a certificate with a given notBefore is minimally expected to
comply with all of the policies as of that date. NotBefore backdating
attempts to circumvent that, which is problematic, but notBefore
forward-dating runs the risk that the certificate will be unusable at the
time it is valid, because it does not comply with the policies of its
validity period.

>
> Doug
>
> > -----Original Message-----
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of
> Gervase
> > Markham via dev-security-policy
> > Sent: Wednesday, January 24, 2018 5:05 AM

> > To: David E. Ross <nob...@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.
> >

[Tim Hollebeek]

> > This incident makes me think that two changes should be made:
> >
> > 1) The Root Store Policy should explicitly ban forward and back-dating
the
> notBefore date.
>
> I think it would be reasonable and sensible to permit back-dating insofar
as it is
> deemed necessary to accommodate client-side clock-skew.

Indeed. This was discussed at a previous Face to Face meeting, and it was
generally
agreed that a requirement that the notBefore date be within +-1 week of
issuance
would not be unreasonable.

The most common practice is backdating by a few days for the reason Rob
mentioned.

-Tim

[Doug Beattie]

Can we consider this case closed with the action that the VWG will propose a ballot that addresses pre and postdating certificates?

Doug

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-

[Tim Hollebeek]

With respect to the action item, I'll add it to next week's VWG agenda.

-Tim

> -----Original Message-----
> From: Doug Beattie [mailto:doug.b...@globalsign.com]
> Sent: Wednesday, January 24, 2018 11:02 AM
> To: Tim Hollebeek <tim.ho...@digicert.com>; Rob Stradling
> <rob.st...@comodo.com>; Jonathan Rudenberg
> <jona...@titanous.com>; mozilla-dev-security-policy
<mozilla-dev-security-
> pol...@lists.mozilla.org>
> Subject: RE: GlobalSign certificate with far-future notBefore
>

[Jakob Bohm]

The BRs make no reference to the "Not Before" date in a certificate,
which is why backdating certificates does not excuse a CA from the
rules.

BR 1.6.1 (definitions) defines "validity period" as follows

Expiry Date: The “Not After” date in a Certificate that defines the end
of a Certificate’s validity period.

Validity Period: The period of time measured from the date when the
Certificate is issued until the Expiry Date

BR 6.3.2 sets the limits on the "validity period"

So the BRs limit the time between the /actual/ date of issuance and the
"Not After" date in the certificate.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Jakob Bohm]

Please also consider the practice of having an off-line CA (typically a
root) pre-issue CRLs, OCSP responses, intermediary CAs and OCSP
responder certificates for the period until the next root-key-usage
ceremony.

This practice will naturally involve forward-dating of all of these
items.

[Tim Hollebeek]

That's a good point, thank you. I think I would lean towards making this
an end-entity only requirement until we've thought through the details
for other certificates.

We've been burned by this before (requirements for OCSP related certificates
were under-specified during the SHA1->SHA2 transition).

-Tim

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-

> bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of Jakob
> Bohm via dev-security-policy
> Sent: Wednesday, January 24, 2018 12:11 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: GlobalSign certificate with far-future notBefore
>
> Please also consider the practice of having an off-line CA (typically a
> root) pre-issue CRLs, OCSP responses, intermediary CAs and OCSP responder
> certificates for the period until the next root-key-usage ceremony.
>
> This practice will naturally involve forward-dating of all of these items.
>
> On 24/01/2018 19:03, Tim Hollebeek wrote:

> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.

> https://clicktime.symantec.com/a/1/w3EBVE2BUeC8MLN64pffPHe_ALFM8rW
> FtYSZz0xKgUQ=?d=0cp29hFCr5Urpdzx-
> Mfh962Yi0YHT8LIyoz29Y64zpxMuZ5acgO3veRerXVznnhS8okM5L2iK7Cfn-
> QM7GjRJRKhm9VLVunmzxGFY3ZEBLSt1WL9J_pv6EL3P9LWZ2hVLFetfoezYOko
> 0x-zSINeQfcGEdm1mIF6ToqUHA6FT-PImc0BUUM0RYQrHLClDEtxX9-
> CxA7_Q5Hi-
> dY_G2jx0s6sq6K5ezLrkKQ3gAzBEza0Zh3b1wW58ngKVU5vpeJvvlR_imWg-
> ZYQ3krbn6QKzJDxbo-
> uRsICLMequfXT4i7CTjcmzrWZ6i4wFJ_YwP7494F9dwa63QJ04UWu1VpygY_FO
> 9yp5t7UHK6F0Gm6dZv-
> Dbs0rvQeyRhJcD76INT9CIRVg0NYqzetnqGr_FXERUBlZySFZ5JHbXWLIq7YkZCEB
> 0bzP5csI62QM1CdL8dKJuEkEICGDDorGrSz8TIvahk%3D&u=https%3A%2F%2Fw

> ww.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This
public
> discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://clicktime.symantec.com/a/1/kC_2afz6-
> xbFBgJiUlml8gw9eo6BNgViMVS2LeeuzvE=?d=0cp29hFCr5Urpdzx-
> Mfh962Yi0YHT8LIyoz29Y64zpxMuZ5acgO3veRerXVznnhS8okM5L2iK7Cfn-
> QM7GjRJRKhm9VLVunmzxGFY3ZEBLSt1WL9J_pv6EL3P9LWZ2hVLFetfoezYOko
> 0x-zSINeQfcGEdm1mIF6ToqUHA6FT-PImc0BUUM0RYQrHLClDEtxX9-
> CxA7_Q5Hi-
> dY_G2jx0s6sq6K5ezLrkKQ3gAzBEza0Zh3b1wW58ngKVU5vpeJvvlR_imWg-
> ZYQ3krbn6QKzJDxbo-
> uRsICLMequfXT4i7CTjcmzrWZ6i4wFJ_YwP7494F9dwa63QJ04UWu1VpygY_FO
> 9yp5t7UHK6F0Gm6dZv-
> Dbs0rvQeyRhJcD76INT9CIRVg0NYqzetnqGr_FXERUBlZySFZ5JHbXWLIq7YkZCEB
> 0bzP5csI62QM1CdL8dKJuEkEICGDDorGrSz8TIvahk%3D&u=https%3A%2F%2Fli
> sts.mozilla.org%2Flistinfo%2Fdev-security-policy

[Gervase Markham]

On 24/01/18 18:02, Doug Beattie wrote:
> Can we consider this case closed with the action that the VWG will
> propose a ballot that addresses pre and postdating certificates?

Yes. I don't believe anyone has suggested that Globalsign broke a formal
rule, either in the BRs or Mozilla's requirements. Thank you for
engaging with us on this topic.

Gerv

[bettyl...@gmail.com]