Ending Support for Expiration Notification Emails
letsencrypt.org
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.

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. As an organization that values privacy, removing this requirement is important to us.
  • Providing expiration notifications costs Let’s Encrypt tens of thousands of dollars per year, money that we believe can be better spent on other aspects of our infrastructure.
  • Providing expiration notifications adds complexity to our infrastructure, which takes time and attention to manage and increases the likelihood of mistakes being made. Over the long term, particularly as we add support for new service components, we need to manage overall complexity by phasing out system components that can no longer be justified.
  • inclementimmigrant@lemmy.worldEnglish
    9·
    16 hours ago

    Well that kind of sucks. I wish they had more tutorials about how to automate then because if you’re not using http-01 via certbot due to port 80 being blocked, which if you’re on a residential line it’s pretty common, so then you have to use dns-01 and manual hooks which isn’t exactly clear for and documented well.

    • diamond@lemmy.blahaj.zoneEnglish
      2·
      12 hours ago

      If you use Caddy with ACME DNS, all of this can be automated.

      If you also use Cloudflare, you can do that + traffic routing with cloudflared without any need for port forwarding .

      • inclementimmigrant@lemmy.worldEnglish
        1·
        2 hours ago

        Using nginx with certbot and duck DNS and I ended up using the manual option with a authentication, clean up, and post bash scripts and then final script that I called from chron job that called the scripts every three months.

        Just from a beginning user of let’s encrypt, and while a software developer I’m not versed in backend development, and I found the documentation to be a bit hit or miss, understandable with a plethora of open source projects. Using certbot, because that’s the rabbit hole let’s encrypt first send you down, the documentation while available isn’t easy to navigate in my opinion and it took me a while to track down the variables used to pass down the text and the bulk examples found were all using http-01.

        I just think that if your not someone with a background in tech, just wanting to get a server to and running with ssl following a bunch of other tutorials and guides, it could be a bit better to get adoption.