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 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
> These certificates contain a subject common name that includes a  “*.”
> label encoded as an ASN.1 PrintableString, which does not allow the
> asterisk character, violating RFC 5280.
> We became aware of the problem on 2018-03-13 at 00:43 UTC via the linter
> flagging in crt.sh [1]. All six certificates have been revoked.
> The root cause of the problem is a Go language bug [2] which has been
> resolved in Go v1.10 [3], which we were already planning to deploy soon. We
> will resolve the issue by upgrading to Go v1.10 before proceeding with our
> wildcard certificate launch plans.
> We employ a robust testing infrastructure but there is always room for
> improvement and sometimes bugs slip through our pre-production tests. We’re
> fortunate that the PKI community has produced some great testing tools that
> sometimes catch things we don’t. In response to this incident we are
> planning to integrate additional tools into our testing infrastructure and
> improve our test coverage of multiple Go versions.
> [1] https://crt.sh/
> [2] https://github.com/golang/go/commit/3b186db7b4a5cc510e71f90682732e
> ba3df72fd3
> [3] https://golang.org/doc/go1.10#encoding/asn1
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 deployed in production? Normally, that would flush these out -
through both manual and automated testing, preferably.

Given that Let's Encrypt is running on an open-source CA (Boulder), this
offers a unique opportunity to highlight where the controls and checks are
in place, particularly for commonNames. RFC 5280 has other restrictions in
place that have tripped CAs up, such as the exclusively using
PrintableString/UTF8String for DirectoryString types (except for backwards
compatibility, which would not apply here), or length restrictions (such as
64 characters, per the ASN.1 schema), it would be useful to comprehensively
review these controls.

Golang's ASN.1 library is somewhat lax, largely in part to both public and
enterprise CAs' storied history of misencodings. What examinations, if any,
will Let's Encrypt be doing for other classes of potential encoding issues?
Has this caused any changes in how Let's Encrypt will construct
TBSCertificates, or review of that code, beyond the introduction of
additional linting?
dev-security-policy mailing list

Reply via email to