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 functionality -- on that parallel staging infrastructure is the mechanism by which mis-issuances such as those mentioned in this thread may be avoided within production environments. Let's Encrypt has been a shining example of best practices up to this point and has enjoyed the attendant minimization of production issues (presumably as a result of exercising said best practices). Despite that, however, either the test cases which resulted in these mis-issuances were not first executed on the staging platform or did not result in the mis-issuance there. A reference was made to a Go lang library error / non-conformance being implicated. Were the builds for staging and production compiled on different releases of Go lang? Certainly, I think these particular mis-issuances do not significantly affect the level of trust which should be accorded to ISRG / Let's Encrypt. Having said that, however, it is worth noting that in a fully new and novel PKI infrastructure, it seems likely -- based on recent inclusion / renewal requests -- that such a mis-issuance would recently have resulted in a disqualification of a given root / key with guidance to cut a new root PKI and start the process over. 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 these things can happen in a celebrated best-practices environment, can they really in isolation be cause to reject a new application or a new root from an existing CA? 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 environments, why would one not perform all tests in ONLY the staging environment, with no tests and nothing other than production transactions on the production environment? That tests continue to be executed in the production environment while holding to the notion that a fully parallel staging environment is the place for tests seems to signal that confidence in the staging environment is -- in some measure, however small -- limited. On Tue, Mar 13, 2018 at 8:46 AM, josh--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > > > https://crt.sh/?id=353758875 > > > https://crt.sh/?id=353757861 > > > https://crt.sh/?id=353756805 > > > https://crt.sh/?id=353755984 > > > https://crt.sh/?id=353754255 > > > > > Somebody noticed there > > https://community.letsencrypt.org/t/acmev2-and-wildcard- > launch-delay/53654/62 > > that the certificate of *.api.letsencrypt.org (apparently currently in > > use), issued by "TrustID Server CA A52" (IdenTrust) seams to have the > > same problem: > > https://crt.sh/?id=8373036&opt=cablint,x509lint > > I think it's just a coincidence that we got a wildcard cert from IdenTrust > a long time ago and it happens to have the same encoding issue that we ran > into. I notified IdenTrust in case they haven't fixed the problem since > then. > _______________________________________________ > 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
