We've received a credible report of a problem with ACME TLS-SNI-01 validation
which could allow people to get certificates they should not be able to get.
While we investigate further we have disabled tls-sni-01 validation.
We'll post more information soon.
__
At approximately 5 p.m. Pacific time on January 9, 2018, we received a report
from Frans Rosén of Detectify outlining a method of exploiting some shared
hosting infrastructures to obtain certificates for domains he did not control,
by making use of the ACME TLS-SNI-01 challenge type. We quickly
On Thursday, January 11, 2018 at 3:36:50 PM UTC-6, Ryan Sleevi wrote:
> On Wed, Jan 10, 2018 at 4:33 AM, josh--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > At approximately 5 p.m. Pacific time on January 9, 2018, we received a
> >
On Thursday, January 11, 2018 at 4:29:09 PM UTC-6, jo...@letsencrypt.org wrote:
> On Thursday, January 11, 2018 at 3:36:50 PM UTC-6, Ryan Sleevi wrote:
> > On Wed, Jan 10, 2018 at 4:33 AM, josh--- via dev-security-policy <
> > dev-security-policy@lists.mozilla.org>
On Friday, January 12, 2018 at 9:38:42 PM UTC-6, jo...@letsencrypt.org wrote:
> On Thursday, January 11, 2018 at 4:29:09 PM UTC-6, jo...@letsencrypt.org
> wrote:
> > On Thursday, January 11, 2018 at 3:36:50 PM UTC-6, Ryan Sleevi wrote:
> > > On Wed, Jan 10, 2018 at 4:3
We (ISRG / Let's Encrypt) have completed our 2017 WebTrust audits, the letters
are written and signed, but CPA Canada is unable to process our final seals due
to a personnel issue on their end. Nobody who can sign off is available, and
apparently it could take another 2+ weeks for them to resolv
On Monday, February 26, 2018 at 8:30:54 PM UTC-6, jo...@letsencrypt.org wrote:
> We (ISRG / Let's Encrypt) have completed our 2017 WebTrust audits, the
> letters are written and signed, but CPA Canada is unable to process our final
> seals due to a personnel issue on their end. Nobody who can sig
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=3537
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
> >
At 12:45 UTC we received a report to our cert-prob-repo...@letsencrypt.org
contact address that Let’s Encrypt was improperly handling CAA records with
mixed case tags, resulting in mis-issuance under the baseline requirements.
Thanks to Corey Bonnell of TrustWave for the report.
RFC 6844 Sectio
To see the original communication on our Community Forums, click here:
https://community.letsencrypt.org/t/2018-08-23-ocsp-responder-incident/70350
At 17:47 UTC on August 23rd, 2018 we deployed a configuration change to our
OCSP responder service that resulted in 90% of traffic to our origin
in
Let’s Encrypt allows subscribers to validate domain control using any one of a
few different validation methods. For much of the time Let’s Encrypt has been
operating, the options were “DNS-01”, “HTTP-01”, and “TLS-SNI-01”. We recently
introduced the “TLS-ALPN-01” method. Today we are announcing
At 11:30am PST on August 10, 2017, Let’s Encrypt was made aware of a compliance
issue regarding unicode normalization of domain names. During the same day we
were made aware of the issue, all unexpired non-compliant certificates were
found and revoked, a fix was applied to our CA systems, and we
Thank you for bringing this oversight to our attention. The certificate in
question has been revoked.
The original incident report from July 16 was accidentally considered closed on
the basis of a fix for our infrastructure without actually revoking the
certificate that led to the report.
Read
t; Alex
>
> On Sat, Sep 9, 2017 at 8:14 PM, josh--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Thank you for bringing this oversight to our attention. The certificate in
> > question has been revoked.
> >
> > The orig
We applaud the recent addition of CAA checking requirements to the Baseline
Requirements. However, there are known problems with the CAA checking algorithm
specified in RFC 6844, and those problems are leading to many reports from our
subscribers. The issues are described here:
https://communit
On September 8, 2017, Let’s Encrypt received a report from researcher Andrew
Ayer that we accepted an expired DNSSEC RRSIG during certificate issuance. The
RRSIG was very recently expired (< 1hr).
This violates RFC 4033 Section 8.1 [1]:
“The signatures associated with signed zone data are only
On Friday September 8, 2017, at 10:04pm US Pacific time, Let's Encrypt received
a report pointing out a certificate that should not have been issued per CAA
RFC 6844 [1].
When CAA checking became mandatory on September 8, 2017, it only allowed the
CAA checking algorithm specified in RFC 6844. S
A report regarding this incident has been published on the Let's Encrypt
community site:
https://community.letsencrypt.org/t/2017-09-09-late-weak-key-revocation/42519
The text is copied here:
On July 16, 2017 it was reported to Let’s Encrypt by researcher Hanno Böck that
it was possible to get
On Tuesday, November 14, 2017 at 8:31:34 AM UTC-8, Kathleen Wilson wrote:
> On 11/14/17 4:34 AM, douglas...@gmail.com wrote:
> >
> > Do we believe that this issue has been resolved by the Registry and
> > issuance an resume as normal, or are there ongoing concerns which CAs
> > should be aware o
Let's Encrypt has now received confirmation from CAFE Informatique & Télécom
(.tg operators) that the .tg registry was compromised around Nov 1, 2017.
Apparently a vulnerability in some front-end software ultimately allowed
attackers to access and manipulate the registry database. CAFE Informati
21 matches
Mail list logo
