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.
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.
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.
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.
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.
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).