New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
If we are being specific, not all of those are using LetsEncrypt either anymore.
Yes, but you do know that the reputation of paid certs is generally piss poor (understatement) compared to LE, right?
"Do you really need a service? It's a 3-line shell script."
I disagree. "This'll get you started" would fit that line a lot better than what you initially said.
from nsa.gov:
stackoverflow.com:
etc.
Dude, you buy SSL certs from someone else instead of running your own CA? Mickey Mouse, man. Mickey Mouse…
Is it possible to auto-renew via script even without email notification?
Not all of those are using LetsEncrypt.
Stanford definitely don't use LE. Neither do Reuters or NBA. Etc.
> > #!/bin/bash > > > > for site in lowendtalk.com lowendbox.com ; do > > echo "${site} $(curl -vI --insecure https://${site} 2>&1 | grep "expire date" | sed 's/^.*expire date: //')" > > done > >Why re-invent the wheel within the script, cron can email you the output.
> > > #!/bin/bash > > > > > > for site in lowendtalk.com lowendbox.com ; do > > > echo "${site} $(curl -vI --insecure https://${site} 2>&1 | grep "expire date" | sed 's/^.*expire date: //')" > > > done > > >The guy has been using proper monitoring services and wants to continue to do so. And the responses are to keep making more and more custom changes he has no experience with.
Oh, I see the confusion. You incorrectly think LE certs are self-signed. They are not.
Only private IPs and hosts are self-signed, because they're not for public access.
Always fun to come up with alternate ways of doing things, but yeah I just went with another monitoring solution. Uptime Kuma (open source monitoring). It has cert expiration notification built-in (and lots more!)
I'll just note that this is not among the reasons LE gives for the decision (see the original post).
I really wish people would stop with (any variation of) the "email is too hard" FUD.
However silly/unfit-for-the-stated-purpose most of the SPF/DKIM/DMARC/whatever standards the big ESP bullies require these days are, they are certainly not "challenging" to set up and maintain, let alone for an organization like Let's Encrypt.
You're right that for them, it's not about difficulty per se. Even so, it's about cost and complexity. Their four official reasons are:
(From https://letsencrypt.org/2025/01/22/ending-expiration-emails/ )
>
Not likely. Google is actually one of the biggest sponsors and also one of the founders behind Lets Encrypt. If LE wants to send lots of emails, Google will help them, not stop them.
People seem to forget that LE is not some hobbyist homegrown project, it is actually a coalition of some of the biggest tech companies in the world. It may run as a non-profit but it is still backed by Google, AWS, Cisco etc.
Wow But why
E-mail at scale is not easy.
When you send at real scale, you can't just fire & forget. This is what LE means by complexity and cost. Even with perfectly acquired double opt-in lists (and LE is only single opt-in, which makes it harder for them), it is still painful to send large quantities of legitimate e-mail.
Example: E-mail recipient loses their Google account. For a little while, Google will send bounces. After that, it may get silently converted to a honeytrap address -- e-mailing it will silently work, but it gives you a reputation penalty. Of course, if you're not sending mail to the user every month (especially relevant in LE's case), you won't ever know.
Example: You get de-repped for sending to users who don't open your mail. You don't know this unless you've implemented an analytics system and are carefully tracking open rates and prune out old mails (this is why you sometimes get those annoying "Do you still want to receive our messages?" on some newsletters you legitimately signed up for. If you don't interact with the mail by opening/clicking, google punishes the sender).
Example: each provider has different bounce messages -- not always in English or using standard codes. And sometimes the messages change... or just lies!
In summary -- it's not simple. Real hours go into building, tuning & maintaining these systems. So when LE says it costs them lots of money, I believe them.
Mail system have codes, they don't rely on message format never changing. Or shouldn't, anyway.
If your system doesn't handle bounces, and either report for you to take action or automatically remove from your list, you're doing it wrong.
When anti-spam laws went into place years and years ago, major software that do campaigns all had to have this capability. How do you NOT have it in 2025?
It's much harder running an email service with many unknown users than sending emails from one domain/entity.