<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 1, 2017, at 8:07 PM, Geoff Keating <<a href="mailto:geoffk@apple.com" class="">geoffk@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">On 1 Aug 2017, at 6:13 pm, Peter Bowen via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>> wrote:<br class=""><br class="">We’ve had an interesting situation come up that isn’t clearly covered in the BRs.<br class=""></blockquote>…<br class=""><blockquote type="cite" class="">So I have two questions:<br class="">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?<br class=""></blockquote><br class="">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.<br class=""><br class="">(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.)<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">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?<br class=""></blockquote><br class="">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.<br class=""><br class="">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.</div></div></blockquote></div><br class=""><div class="">Oct 31, 2020 is 39 months from today, so that is the actual max.</div><div class=""><br class=""></div><div class="">However, I thought I remembered Chrome adding some date checks. After a little poking I found <a class="f-b f-L" href="https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc.h?l=28&ct=xref_jump_to_def&gsn=CertVerifyProc" style="background-color: rgb(255, 255, 170); color: rgb(85, 26, 139); font-family: monospace; font-size: medium; font-variant-ligatures: normal; orphans: 2; white-space: pre; widows: 2;">CertVerifyProc</a><span style="font-family: monospace; font-size: medium; font-variant-ligatures: normal; orphans: 2; white-space: pre; widows: 2; background-color: rgb(255, 255, 255);" class="">::</span><a class="f-b" href="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" style="text-decoration: none; color: rgb(85, 26, 139); font-family: monospace; font-size: medium; font-variant-ligatures: normal; orphans: 2; white-space: pre; widows: 2; background-color: rgb(255, 255, 255);">HasTooLongValidity</a> (<a href="https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc.cc?l=874" class="">https://cs.chromium.org/chromium/src/net/cert/cert_verify_proc.cc?l=874</a>)</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">If we could backdate even further it would be pre-BRs, but that maxes out at July 1, 2019.</div><div class=""><br class=""></div><div class="">So it seems that if we want to go for Jan 1, 2017, then the max notAfter is March 31, 2020.</div><div class=""><br class=""></div><div class="">Of course none of this matters if Chrome compatibility is not an issue.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Peter</div></body></html>