Since its inception, Let’s Encrypt has been sending expiration notification emails to subscribers that have provided an email address to us. We will be ending this service on June 4, 2025. The decision to end this service is the result of the following factors:
Over the past 10 years more and more of our subscribers have been able to put reliable automation into place for certificate renewal.
Providing expiration notification emails means that we have to retain millions of email addresses connected to issuance records.
I think it’s a good idea, everyone should be automating this anyway.
Honestly in rare situations that a device like that needs to be accessible from the wild Internet I think it’d be mad to expose it directly, especially if it’s not manageable as you suggest. At the very least, I’d be leaning on a reverse proxy.
That implies though I don’t want valid certificates in my environment. I still want to make sure even on my private network I’m using valid certs. A lot of security departments require that too even if the device isn’t public facing.
Valid certificate is anything you trust. Any CA which you can trust is no more or less secure than the one you get from LE, so for the private network you can just happily sign your own certificates and just distribute the CA to your devices.
True. And there’s also a ton of devices around which don’t trust LetsEncrypt either. There’s always edge cases. For example, take a bit older photocopier and it’s more than likely that it doesn’t trust on anything on this planet anymore and there’s no easy way to update CA lists even if the hardware itself is still perfectly functional.
That doesn’t mean that your self-signed CA, in itself, would be technically any less secure than the most expensive Verisign certificate you can find. And yes, there’s a ton of details and nuances here and there, but I’m not going to go trough every technical detail about how certificates work. I’m not an expert on that field by any stretch even if I do know a thing or two and there’s plenty of material online to dig deep into the topic if you want to.
still want to make sure even on my private network I’m using valid certs. A lot of security departments require that too even if the device isn’t public facing.
Is there a hard source with evidence that this is at all needed? Because there are a lot of things that “security departments” do that amount to security theater. Like forcing arbitrary password changes org wide.
Regardless of “hard evidence” it’s still the company policy. How well does it go over if you try to say “well acktuslly…” when it comes to password changes.
How well does it go over if you try to say “well acktuslly…” when it comes to password changes.
Well, it went over easy, but I also gained the authority to implement or toss such policies when I took my job LMAO
In any case, I was referring to the “my environment” part since it implied you had such authority and were just choosing to emulate policies of others, ofc I don’t mean to make decisions you don’t have the authority to. Hard evidence is hard evidence though, it does give you a leg to stand on should you propose such changes
Then swap you nameservers to a DNS provider that allows that?
There are a lot of embedded systems that do not offer API support to swap out certificates. Things like switches, dvr, nas devices, etc.
Honestly in rare situations that a device like that needs to be accessible from the wild Internet I think it’d be mad to expose it directly, especially if it’s not manageable as you suggest. At the very least, I’d be leaning on a reverse proxy.
That implies though I don’t want valid certificates in my environment. I still want to make sure even on my private network I’m using valid certs. A lot of security departments require that too even if the device isn’t public facing.
Valid certificate is anything you trust. Any CA which you can trust is no more or less secure than the one you get from LE, so for the private network you can just happily sign your own certificates and just distribute the CA to your devices.
But then you have to distribute CAs to all the devices that will reach this service, and not all devices allow that.
True. And there’s also a ton of devices around which don’t trust LetsEncrypt either. There’s always edge cases. For example, take a bit older photocopier and it’s more than likely that it doesn’t trust on anything on this planet anymore and there’s no easy way to update CA lists even if the hardware itself is still perfectly functional.
That doesn’t mean that your self-signed CA, in itself, would be technically any less secure than the most expensive Verisign certificate you can find. And yes, there’s a ton of details and nuances here and there, but I’m not going to go trough every technical detail about how certificates work. I’m not an expert on that field by any stretch even if I do know a thing or two and there’s plenty of material online to dig deep into the topic if you want to.
I’m good. I know very well there are uses cases for a self signed cert. LE is still far more practical for 99% of use cases, even internally.
I’m with you, but that’s why I’m automating certificate expiry checking somewhere else (in my home assistant install to be exact).
Is there a hard source with evidence that this is at all needed? Because there are a lot of things that “security departments” do that amount to security theater. Like forcing arbitrary password changes org wide.
Regardless of “hard evidence” it’s still the company policy. How well does it go over if you try to say “well acktuslly…” when it comes to password changes.
Well, it went over easy, but I also gained the authority to implement or toss such policies when I took my job LMAO
In any case, I was referring to the “my environment” part since it implied you had such authority and were just choosing to emulate policies of others, ofc I don’t mean to make decisions you don’t have the authority to. Hard evidence is hard evidence though, it does give you a leg to stand on should you propose such changes