Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

Please put also this certificate on that list: https://crt.sh/?id=181538497=cablint,x509lint Best Regards, Jozsef ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Thu, Mar 15, 2018 at 12:22 PM, Tom via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Should another bug be opened for the certificate issued by IdenTrust with > apparently the same encoding problem? > > Yes - this is bug 1446121 (

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

Le 15/03/2018 à 20:04, Wayne Thayer a écrit : This incident, and the resulting action to "integrate GlobalSign's certlint and/or zlint into our existing cert-checker pipeline" has been documented in bug 1446080 [1] This is further proof that pre-issuance TBS certificate linting (either by

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

This incident, and the resulting action to "integrate GlobalSign's certlint and/or zlint into our existing cert-checker pipeline" has been documented in bug 1446080 [1] This is further proof that pre-issuance TBS certificate linting (either by incorporating existing tools or using a comprehensive

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Tuesday, March 13, 2018 at 4:27:23 PM UTC-6, Matthew Hardeman wrote: > I thought I recalled a recent case in which a new root/key was declined > with the sole unresolved (and unresolvable, save for new key generation, > etc.) matter precluding the inclusion being a prior mis-issuance of test >

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Tue, Mar 13, 2018 at 6:27 PM Matthew Hardeman wrote: > Another question this incident raised in my mind pertains to the parallel >>> staging and production environment paradigm: If one truly has the >>> 'courage >>> of conviction' of the equivalence of the two

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

> So to clarify I understand this: The same problem was in the staging > environment and there where also certificates with illegal encoding issued in > staging, but you didn't notice them because no one manually validated them > with the crt.sh lint? That's correct. > Or are there

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Tuesday, March 13, 2018 at 23:51:01 UTC+1 js...@letsencrypt.org wrote: > Clearly we should have caught this earlier in the process. The changes we > have in the pipeline (integrating certlint and/or zlint) would have > automatically caught the encoding issue at each staging in the pipeline:

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Tuesday, March 13, 2018 at 2:02:45 PM UTC-7, Ryan Sleevi wrote: > I'm hoping that LE can provide more details about the change management > process and how, in light of this incident, it may change - both in terms > of automated testing and in certificate policy review. Forgot to reply to this

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Tue, Mar 13, 2018 at 4:02 PM, Ryan Sleevi wrote: > > > On Tue, Mar 13, 2018 at 4:13 PM, Matthew Hardeman via dev-security-policy > wrote: > >> I am not at all suggesting consequences for Let's Encrypt, but rather >> raising a question

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Tuesday, March 13, 2018 at 2:02:45 PM UTC-7, Ryan Sleevi wrote: > availability of certificate linting tools - such as ZLint, x509Lint, > (AWS's) certlint, and (GlobalSign's) certlint - there's no dearth of > availability of open tools and checks. Given the industry push towards > integration of

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Tue, Mar 13, 2018 at 4:13 PM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I am not at all suggesting consequences for Let's Encrypt, but rather > raising a question as to whether that position on new inclusions / renewals > is appropriate. If

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

The fact that this mis-issuance occurred does raise a question for the community. For quite some time, it has been repeatedly emphasized that maintaining a non-trusted but otherwise identical staging environment and practicing all permutations of tests and issuances -- especially involving new

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Tuesday, March 13, 2018 at 3:33:50 AM UTC-5, Tom wrote: > > During final tests for the general availability of wildcard > certificate support, the Let's Encrypt operations team issued six test > wildcard certificates under our publicly trusted root: > > > > https://crt.sh/?id=353759994 > >

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

> During final tests for the general availability of wildcard certificate support, the Let's Encrypt operations team issued six test wildcard certificates under our publicly trusted root: > > https://crt.sh/?id=353759994 > https://crt.sh/?id=353758875 > https://crt.sh/?id=353757861 >

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Mon, Mar 12, 2018 at 11:38 PM jacob.hoffmanandrews--- via dev-security-policy wrote: > On Monday, March 12, 2018 at 8:22:46 PM UTC-7, Ryan Sleevi wrote: > > Given that Let's Encrypt has been operating a Staging Endpoint ( > >

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Monday, March 12, 2018 at 8:27:06 PM UTC-7, Ryan Sleevi wrote: > Also, is this the correct timestamp? For example, examining > https://crt.sh/?id=353754255=ocsp > > Shows an issuance time of Not Before: Mar 12 22:18:30 2018 GMT and a > revocation time of 2018-03-12 23:58:10 UTC , but you

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Monday, March 12, 2018 at 8:22:46 PM UTC-7, Ryan Sleevi wrote: > Given that Let's Encrypt has been operating a Staging Endpoint ( > https://letsencrypt.org/docs/staging-environment/ ) for issuing wildcards, > what controls, if any, existed to examine the certificate profiles prior to > being

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Mon, Mar 12, 2018 at 11:22 PM, Ryan Sleevi wrote: > > > On Mon, Mar 12, 2018 at 10:35 PM, josh--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> During final tests for the general availability of wildcard certificate >> support, the Let's

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Mon, Mar 12, 2018 at 10:35 PM, josh--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > During final tests for the general availability of wildcard certificate > support, the Let's Encrypt operations team issued six test wildcard > certificates under our publicly

2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

During final tests for the general availability of wildcard certificate support, the Let's Encrypt operations team issued six test wildcard certificates under our publicly trusted root: https://crt.sh/?id=353759994 https://crt.sh/?id=353758875 https://crt.sh/?id=353757861