jaas

No worries

Yeah, thanks

Since Let's Encrypt wasn't down most of the day if would be helpful if you could update the title to reflect that.

Mostly 90 days, and we recommend renewing at 60 days for 90 day certs. That gives more than four weeks of leeway.

If you're one of the few early adopters of short-lived (6-day) certs you should renew at 3 days, giving you 3 days for a successful renewal. A 90 minute outage, even if it was a full outage, would not interfere with a successful renewal.

It would not have been sticky for the entire day. If it was sticky at all, it would have been only during the 90 minute period I referenced. It's most likely that there is some other issue with how you're requesting the cert. Folks can help debug at: https://community.letsencrypt.org/

> That explains why one of my IoT vendors is using an expired certificate.

I don't think so. There was a dip in success rates for 90 minutes today, but nobody should be renewing their certificate within 90 minutes of expiration. If you're at that point, something went wrong weeks ago.

Let's Encrypt has been working normally for most of the day. There was a ~90 minute period during which some of our users would have received a higher error rate due to upstream networking issues, but the majority of requests were successful even during that period.

It seems our status.io notes are being misinterpreted as much more severe than they were intended to reflect.

Edit: Note that this was written in response to a previous submission title implying that Let's Encrypt was entirely down most of the day.

I'm not sure if you're talking generally about sanctions or specifically about Let's Encrypt, but to avoid any doubt: citizens of Crimea are free to use Let's Encrypt. We do not, however, serve government entities in occupied Crimea.

I was referring to the requirements imposed on us. When it comes to sanctions, we do not block anything more than what is required by law.

Let's Encrypt continues to be available to almost every vulnerable population in the world, including those that need it most. I say almost as I'm hesitant to speak in absolutes regarding a topic as complex as this.

Most of our sanctions-related blocks apply only to the governments of certain sanctioned countries, not their general population.

This subscriber agreement update was intended to better reflect our legal requirements. It does not reflect a major change in the service we provide. Our compliance program does evolve over time, and part of that is communicating about it better in our terms of service. It's clear from some of the comments here that we have more work to do to make that text more understandable, we'll work on that.

> That said, pretty sure this is stems from the insane US legal requirement to not export SSL technology to enemy countries. I'm sure some of y'all are old enough to remember when web browsers came in "international friendly" versions that supported 40 bit encryption, or "fancy secure" versions with 128 bit encryption.

It doesn't.

Sanctions compliance is unfortunately fairly complex.

Let's Encrypt can issue certificates for non-government entities in Iran and Russia due to statutory exemptions protecting personal communications, alongside specific Office of Foreign Assets Control (OFAC) authorizations designed to promote Internet freedom and human rights.

We will look into whether we can make things more easily understandable in the subscriber agreement.

Let's Encrypt certificates continue to be available in both Iran and Russia, just not for the Iranian and Russian governments.

The terms of service update to clarify what we have always done, comply with relevant law, has not changed the situation for either country.

In that sense, prepare yourself to be bored.

Stopping all issuance is an pretty standard response if a CA thinks what they are issuing might be non-compliant in any way. It's an action we're required to take. It's not necessarily a sign of a more dramatic failure mode or key compromise. That said, the impact is the same for as long as the downtime lasts so it is unfortunate and we're sorry for the disruption.

I don't think the premise behind short lived (six day) certificates being viable is that CA issuance never goes down. Sure, the runway is shorter, but not that short. Most down time is a few hours or less, which is not a problem for six day certificates that should be renewed every three days.

Short lived certificates are optional though, so if it's not worth it to you there are longer lifetime options.

This is a compliance incident, we should be issuing again shortly.

Update: Issuance is back up.

Update: Preliminary incident report:

https://bugzilla.mozilla.org/show_bug.cgi?id=2038351

Seat heat is one click in my 2022 Volvo. Or as others have noted, you can use your voice.

It’s hard to be ready for a world you do not understand, and the world is a lot more than engineering or any other single subject.

Their networking is awful in my experience. The WiFi chip is cheap crap, extremely sensitive, cuts out a lot, and doesn’t support WPA3.

I had to set up a dedicated Nanit-only AP in my house in order to stabilize the connection. It would not work any other way, tried many different configurations, even other APs.

I know lots of parents in NYC (where I live with multiple kids) and their lives have not “broken down.” What an absurd statement/generalization.

Rust is generally a much better tool for building software than C. When your software is built with better tools, you will most likely get better software (at least eventually / long term, sometimes a transition period can be temporarily worse or at least not better).

If you are using Nginx, then likely yes.

We buy them because our experience is that they are extremely reliable and their iDrac management system is better than the alternatives, which saves us time (thus money). Maybe they aren’t the cheapest at initial purchase, but less maintenance and the ease of administration makes up for it.

Section 3.2.2.9 of this document:

https://cabforum.org/working-groups/server/baseline-requirem...

You can also just search the document for the word "Perspective" to find most references to it.

Go has a big, high quality standard library with most of what one might need. Means you have to bring in and manage (and trust) far fewer third party dependencies, and you can work faster because you’re not spending a bunch of time figuring out what the crate of the week is for basic functionality.

The idea is that some people don’t click - that refers mainly to people using a mouse, and many people are not using a mouse. So it is overstating information about what to do.

It's not just about the money:

"Providing expiration notification emails means that we have to retain millions of email addresses connected to issuance records. As an organization that values privacy, removing this requirement is important to us."

A check to cover the cost of the system would not solve this part of the problem.

A free account for sending emails would not have changed the decision because it doesn't solve this:

"Providing expiration notification emails means that we have to retain millions of email addresses connected to issuance records. As an organization that values privacy, removing this requirement is important to us."

Now there is no contact information associated with issuance records.

We (Let's Encrypt) are getting rid of subject common names and moving to just using subject alternative names.

This change has been made in short-lived (6 day) certificate profiles. It has not been made for the "classic" profile (90 day).

It will work for both.

Let’s Encrypt has already started issuing a limited number of 6-day certs and they will be generally available later this year.

(90 days will remain the default though)