The fact that this mis-issuance occurred does raise a question for the
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 <
> 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-
> > 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
> dev-security-policy mailing list
dev-security-policy mailing list