> On Aug 1, 2017, at 8:07 PM, Geoff Keating <[email protected]> wrote:
>
>> On 1 Aug 2017, at 6:13 pm, Peter Bowen via Public <[email protected]>
>> wrote:
>>
>> We’ve had an interesting situation come up that isn’t clearly covered in the
>> BRs.
> …
>> So I have two questions:
>> 1) Does anyone think setting a notBefore well before the issuance dates a
>> problem, as long as the certificate includes a timestamp that represents the
>> issuance date and the CA previously issued a certificate for the same domain
>> name(s) to the same applicant that has a validity period that spans from the
>> notBefore to issuance date?
>
> I can’t immediately think of any reason not to allow this, but if you do
> this, please create a precertificate, upload it to CT, and put a SCT in the
> certificate as an indicator of the the actual time of issuance.
>
> (I think it’s a good general rule that the more weird is the thing you’re
> doing, the more transparent you want to be about it.)
I agree. Hence this post. There is nothing in the BRs that says you can’t
backdate, but I wanted to be transparent about it.
>> 2) What is the latest acceptable notAfter date? 39 months (or 825 days in
>> the future) from the notBefore date or from the issuance date?
>
> From the issuance date—in the BRs, the ‘Validity Period’ runs from issuance
> to expiry. In fact I can’t find anything in the BRs about when the notBefore
> timestamp should be.
>
> What people will actually check is the time between the SCT and the
> certificate expiry. Make sure that’s less than 39 months/825 days.
Oct 31, 2020 is 39 months from today, so that is the actual max.
However, I thought I remembered Chrome adding some date checks. After a little
poking I found CertVerifyProc
<https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc.h?l=28&ct=xref_jump_to_def&gsn=CertVerifyProc>::HasTooLongValidity
<https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc.cc?l=875&gs=cpp%253Anet%253A%253Aclass-CertVerifyProc%253A%253AHasTooLongValidity(const%2Bnet%253A%253AX509Certificate%2B%2526)%2540chromium%252F..%252F..%252Fnet%252Fcert%252Fcert_verify_proc.cc%257Cdef&gsn=HasTooLongValidity&ct=xref_usages>
(https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc.cc?l=874
<https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc.cc?l=874>)
We would need to date back to March 31, 2015 to get longer than 39 months
accepted by Chrome; it would then accept 60 months, which only takes one to
March 31, 2020; that doesn’t really help.
If we could backdate even further it would be pre-BRs, but that maxes out at
July 1, 2019.
So it seems that if we want to go for Jan 1, 2017, then the max notAfter is
March 31, 2020.
Of course none of this matters if Chrome compatibility is not an issue.
Thanks,
Peter
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
