On Monday, March 30, 2020 at 4:48:38 PM UTC-4, Josh Aas wrote:
> On Thursday, March 26, 2020 at 6:27:10 PM UTC-4, Ryan Sleevi wrote:
> > Apologies for the delay here. I filed
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1625322 for this.
>
> We are looking into this.
On Thursday, March 26, 2020 at 6:27:10 PM UTC-4, Ryan Sleevi wrote:
> Apologies for the delay here. I filed
> https://bugzilla.mozilla.org/show_bug.cgi?id=1625322 for this.
We are looking into this.
Matt - It would be helpful if you could report issues like this to the CA in
question, not just
On 2019.08.20 at 08:48 UTC we received a report from community member and
Apache httpd developer, Stefan Eissing, that under certain conditions our OCSP
caching layer would return a valid OCSP response but not the one that was
requested. This resulted in our OCSP service acting in violation of
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
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
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
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
> >
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
to resolve the issue, which
could bring us close to the deadline.
What would the root programs like us to do if CPA Canada is not able to perform
in the required amount of time? I expect in the worst case the seals would be
less than a month late.
-Josh Aas
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
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.
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
> &
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
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.
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
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
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
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:
Gaynor wrote:
> Hi Josh,
>
> Does Let's Encrypt plan to implement any systematic or programmatic fixes
> to ensure certificates are promptly revoked in the future?
>
> Did you perform a scan of all your issued certificates to see if any others
> were effected?
>
> Alex
&g
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.
these
certificates and notified the subscribers who requested them.
I would like to thank the community members that discovered this issue, as well
as the Let's Encrypt team that worked hard to resolve it quickly.
--
Josh Aas
Executive Director
Internet Security Research Group
Let's Encrypt
We had some trouble figuring out how to purchase a Chinese domain name before
we launched, so we didn't purchase it then. We've never talked to wosign about
this before, and we haven't seen the domain used for anything confusing so far.
This is our first interaction about it and we're happy to
On Wednesday, November 23, 2016 at 11:53:00 AM UTC-6, cda wrote:
> On Tuesday, November 22, 2016 at 9:16:43 PM UTC+1, jo...@letsencrypt.org
> wrote:
> > Issuance to gov.ir and gov.sy is not allowed as these entities are
> > sanctioned by the U.S. government and we are a U.S.-based organization.
Between 11:30am and 4pm Pacific on November 21, 2016, a problem with the Let’s
Encrypt issuance blocklist was identified, confirmed, and fixed.
The issue was initially identified by a Let’s Encrypt operations engineer
during routine maintenance. A script is used to assemble a final blocklist
On Friday, July 1, 2016 at 3:26:52 PM UTC-5, Nick Lamb wrote:
> ACME is a protocol intended to become an IETF Standards Track RFC. You are
> welcome to read the existing discussions of the protocol, or to participate
> (subject to usual IETF rules) https://www.ietf.org/mailman/listinfo/acme. As
comments on just this
> CPS document.
Hi Peter,
We've reviewed your feedback, much of it is helpful. Thanks. We'll work on
incorporating improvements based on it into the next revision of our CPS. We
don't believe any of these items need to block inclusion, however.
--
Josh Aas
Executive Direc
I would simply like to state that my views, and the views of Let's Encrypt, are
closely aligned with those already expressed here by Peter Bowen and Eric Mill.
I will add, since I don't think it has been made clear enough here already,
that violations of a CA's subscriber agreement can and
On Wednesday, April 20, 2016 at 4:57:36 PM UTC-5, Eric Mill wrote:
> One small thing I noticed - the CA Hierarchy diagram the bug links to is
> out of date:
> https://bugzilla.mozilla.org/attachment.cgi?id=8660928
>
> At a minimum, X3 and X4 now exist:
> https://letsencrypt.org/certificates/
An
Peter Bowen recently created a certlint tool [1] to check certificates for
CA/Browser Forum Baseline Requirements compliance. Thanks Peter!
Using this tool we uncovered a number of Let's Encrypt certificates that are
not compliant with RFC 5280. There were two issues:
1) Let's Encrypt was not
ISRG CPS Section 4.2.1: "The CA checks for relevant CAA records prior to
issuing certificates. The CA acts in accordance with CAA records if present."
At 9:45am U.S. Pacific time on December 7th, 2015, it was reported to us that
our Certificate Authority Authorization (CAA) record checks were
30 matches
Mail list logo
