Let's Encrypt is planning a 6-day TLS certificate for next year.

> Our longstanding offering won’t fundamentally change next year, but we
> are going to introduce a new offering that’s a big shift from anything
> we’ve done before - short-lived certificates. Specifically,
> certificates with a lifetime of six days. This is a big upgrade for
> the security of the TLS ecosystem because it minimizes exposure time
> during a key compromise event.

Source:
https://letsencrypt.org/2024/12/11/eoy-letter-2024/

On Wed, 11 Dec 2024 20:27:37 -0300, Salvador Mirzo <smirzo@example.com> wrote:
>Let's Encrypt is planning a 6-day TLS certificate for next year.
>> Our longstanding offering won't fundamentally change next year, but we
>> are going to introduce a new offering that's a big shift from anything
>> we've done before - short-lived certificates. Specifically,
>> certificates with a lifetime of six days. This is a big upgrade for
>> the security of the TLS ecosystem because it minimizes exposure time
>> during a key compromise event.
>Source:
>https://letsencrypt.org/2024/12/11/eoy-letter-2024/

seems like everyone is using tls . . . is there anyone "not" using it?

(using Tor Browser 14.0.3)
https://letsencrypt.org/
>Thousands of people around the world make our work possible. Donate today.
>...
>About Us
>https://letsencrypt.org/about/
>About Let's Encrypt
>Let's Encrypt is a free, automated, and open certificate authority (CA), run for
>the public's benefit. It is a service provided by the Internet Security Research
>Group (ISRG).
>We give people the digital certificates they need in order to enable HTTPS
>(SSL/TLS) for websites, for free, in the most user-friendly way we can. We do this
>because we want to create a more secure and privacy-respecting Web.
>You can read about our most recent year in review by downloading our annual report.
>The key principles behind Let's Encrypt are:
> Free: Anyone who owns a domain name can use Let's Encrypt to obtain a trusted
> certificate at zero cost.
> Automatic: Software running on a web server can interact with Let's Encrypt to
> painlessly obtain a certificate, securely configure it for use, and automatically
> take care of renewal.
> Secure: Let's Encrypt will serve as a platform for advancing TLS security best
> practices, both on the CA side and by helping site operators properly secure
> their servers.
> Transparent: All certificates issued or revoked will be publicly recorded and
> available for anyone to inspect.
> Open: The automatic issuance and renewal protocol is published as an open
> standard that others can adopt.
> Cooperative: Much like the underlying Internet protocols themselves, Let's
> Encrypt is a joint effort to benefit the community, beyond the control of any one
> organization.
>We have a page with more detailed information about how the Let's Encrypt CA works.
>Support a more secure and privacy-respecting Web.
>Donate
>Let's Encrypt is a free, automated, and open certificate authority brought to you
>by the nonprofit Internet Security Research Group (ISRG). Read all about our
>nonprofit work this year in our 2024 Annual Report.
>548 Market St, PMB 77519, San Francisco, CA 94104-5401, USA
>Send all mail or inquiries to:
>PO Box 18666, Minneapolis, MN 55418-0666, USA
> GitHub
> LinkedIn
> Mastodon
>View our privacy policy.
>View our trademark policy.
>Subscribe for email updates about Let's Encrypt and other ISRG projects
>(c) 2024 Internet Security Research Group
[end quoted plain text]

(using Tor Browser 14.0.3)
https://duckduckgo.com/?q=transport+layer+security+secure+sockets

D <noreply@mixmin.net> wrote:
> On Wed, 11 Dec 2024 20:27:37 -0300, Salvador Mirzo <smirzo@example.com> wrote:
>>Let's Encrypt is planning a 6-day TLS certificate for next year.
>>> Our longstanding offering won't fundamentally change next year, but we
>>> are going to introduce a new offering that's a big shift from anything
>>> we've done before - short-lived certificates. Specifically,
>>> certificates with a lifetime of six days. This is a big upgrade for
>>> the security of the TLS ecosystem because it minimizes exposure time
>>> during a key compromise event.
>>Source:
>>https://letsencrypt.org/2024/12/11/eoy-letter-2024/
>
> seems like everyone is using tls . . . is there anyone "not" using it?

Given Chrome's "insecure" branding in the URL bar from the "make
everything https" push some years back, there are far fewer who are not
using it.

But six day expiry dates, that just sounds insane.

On Dec 11, 2024 at 7:28:38 PM EST, "Rich" <rich@example.invalid> wrote:

> D <noreply@mixmin.net> wrote:
>> On Wed, 11 Dec 2024 20:27:37 -0300, Salvador Mirzo <smirzo@example.com> wrote:
>>> Let's Encrypt is planning a 6-day TLS certificate for next year.
>>>> Our longstanding offering won't fundamentally change next year, but we
>>>> are going to introduce a new offering that's a big shift from anything
>>>> we've done before - short-lived certificates. Specifically,
>>>> certificates with a lifetime of six days. This is a big upgrade for
>>>> the security of the TLS ecosystem because it minimizes exposure time
>>>> during a key compromise event.
>>> Source:
>>> https://letsencrypt.org/2024/12/11/eoy-letter-2024/
>>
>> seems like everyone is using tls . . . is there anyone "not" using it?
>
> Given Chrome's "insecure" branding in the URL bar from the "make
> everything https" push some years back, there are far fewer who are not
> using it.
>
> But six day expiry dates, that just sounds insane.

I have been running 2-day TTL certs for some services I run. It is not bad at
all with ACME since things just renew in the background; and it really helps
cut down on the possbile impact of a compromised cert.

Without ACME though, no way it would be possible XD

On Thu, 12 Dec 2024 00:12:23 +0000, D wrote:

> seems like everyone is using tls . . . is there anyone "not" using it?

The idea is to make it so commonplace, that you no longer stand out like a
sore thumb for using it. So those under certain regimes that fear their
citizenry cannot surveil everybody they might suspect of hiding something
from them -- safety in numbers, in short.

On Thu, 12 Dec 2024 00:28:38 -0000 (UTC), Rich <rich@example.invalid> wrote:
>D <noreply@mixmin.net> wrote:
>> On Wed, 11 Dec 2024 20:27:37 -0300, Salvador Mirzo <smirzo@example.com> wrote:
>>>Let's Encrypt is planning a 6-day TLS certificate for next year.
>>>> Our longstanding offering won't fundamentally change next year, but we
>>>> are going to introduce a new offering that's a big shift from anything
>>>> we've done before - short-lived certificates. Specifically,
>>>> certificates with a lifetime of six days. This is a big upgrade for
>>>> the security of the TLS ecosystem because it minimizes exposure time
>>>> during a key compromise event.
>>>Source:
>>>https://letsencrypt.org/2024/12/11/eoy-letter-2024/
>>
>> seems like everyone is using tls . . . is there anyone "not" using it?
>
>Given Chrome's "insecure" branding in the URL bar from the "make
>everything https" push some years back, there are far fewer who are not
>using it.
>But six day expiry dates, that just sounds insane.

i really don't know enough about this subject to comment . . . but i have
been using anonymous remailers since 1997 ("replay"... before "dizum" etc.)
and lately i've noticed yamn key updates (e.g. mixmin.net/yamn/pubring.mix)
do seem to be occurring more frequently within the past month or so, to wit:

(using Tor Browser 14.0.3)
https://www.mixmin.net/yamn/pubring.mix
>frell nyam@remailer.frell.eu.org 45424f73fca08073b697ee69737da3dd 4:0.2c E 2024-12-10 2024-12-24
>gronk yamn@gronk.ch e90a004308d8ceecb3e3f469d34ca2b9 4:0.2.6 M 2024-12-08 2024-12-22
>lorem yamn@eocto.net f8ec1c45316ca426b2452b5a716d05d5 4:0.2.6 M 2024-12-07 2024-12-21
>middleman yamn@middleman.remailer.online 6a1f4c71bafd3dac9fc2808c7011ca8d 4:0.2.6 M 2024-12-06 2024-12-20
>milton yamn@milton.redmv.net 41415e5f27dc27160d7d6f54238dd385 4:0.2.6 M 2024-12-10 2024-12-24
>paranoyamn yamn@yamn.paranoici.org 403977616c0c5497b1736efe10c91c03 4:0.2c E 2024-12-06 2024-12-20
>shalo yamn@shalo.ca a1b7038c154cc3e3cfa4bf2ee3c6e385 4:0.2.6 M 2024-12-05 2024-12-19
>tncmm yamn@tnetconsulting.net 3d82ae32b0e692914fa84b8b994187c2 4:0.2c M 2024-12-04 2024-12-18
>victor yamn@virebent.art 3be2e6fb18b7e5e00eb2a95deb9bc2c1 4:0.2c M 2024-12-08 2024-12-22
>yamn yamn@mixmin.net 0bb6ccac8db394739840bc586e8d425d 4:0.2.6 E 2024-12-08 2024-12-13
>yamn2 yamn2@mixmin.net 6266507f5503fd11cbd22351f2b9c3b0 4:0.2.6 E 2024-12-09 2024-12-14
>yamn3 yamn3@mixmin.net ef6361bd9b6489f5d2a4f3d542afbed1 4:0.2.6 E 2024-12-11 2024-12-16
>yamn4 yamn4@mixmin.net 5d704a802745539fe58b80528fd7e596 4:0.2.6 M 2024-12-10 2024-12-24
[end quoted plain text]

it used to be that at least one or two of these yamn keys would be expired
for maybe a day or two before being updated . . . maybe this "six day" tls
business has something to do with it? (this may have been discussed in the
news:alt.privacy.anon-server newsgroup, but if so i probably missed it)...

if updating public keys, certificates, etc., more frequently helps to keep
everything current, maybe this "six day" trend is something more permanent

On Thu, 12 Dec 2024 01:05:24 +0000, Broseki wrote:

> I have been running 2-day TTL certs for some services I run. It is not
> bad at all with ACME since things just renew in the background; and it
> really helps cut down on the possbile impact of a compromised cert.
>
> Without ACME though, no way it would be possible XD

If the Let’s Encrypt folks have no trouble with the server load, then I
guess I have no objection either.

When I started using Let’s Encrypt, I found the default setting for Debian
was to check for renewals twice a day. That shocked me a bit, but I assume
they knew what they were doing.

Rich <rich@example.invalid> writes:
> Given Chrome's "insecure" branding in the URL bar from the "make
> everything https" push some years back, there are far fewer who are
> not using it.
>
> But six day expiry dates, that just sounds insane.

I suspect six days is chosen to be one day shorter than the one-week
OCSP timeout they quote in their blog post about revocation[1]. So, they
can sunset OCSP support and at the same time improve revocation
performance and effectiveness (it fails open, so it doesn’t work against
a well-positioned attacker).

[1] https://letsencrypt.org/2022/09/07/new-life-for-crls/

--
https://www.greenend.org.uk/rjk/

On Dec 12, 2024 at 1:07:53 AM EST, "Lawrence D'Oliveiro" <ldo@nz.invalid>
wrote:

> On Thu, 12 Dec 2024 01:05:24 +0000, Broseki wrote:
>
>> I have been running 2-day TTL certs for some services I run. It is not
>> bad at all with ACME since things just renew in the background; and it
>> really helps cut down on the possbile impact of a compromised cert.
>>
>> Without ACME though, no way it would be possible XD
>
> If the Let’s Encrypt folks have no trouble with the server load, then I
> guess I have no objection either.
>
> When I started using Let’s Encrypt, I found the default setting for Debian
> was to check for renewals twice a day. That shocked me a bit, but I assume
> they knew what they were doing.

That is an interesting point; I wonder how much load they are really seeing;
the certs I have set to 2 days are all for corporate internal CAs using ACME
not Let's Encrypt, my LE certs are still the default (30 days now?). I also
wonder if they have any sort of crypto acceleration going on in the backend to
make what I assume to be massive amounts of requests flow smoothly. I'd say
probably 80%+ of websites I see now use Let's Encrypt certs, and crypto stuff
is all pretty compute intensive.

It is crazy the service is free. It was not long ago when certs were super
expensive (especially for things like personal websites and projects).

Broseki <broseki@whitetail.is> writes:
> That is an interesting point; I wonder how much load they are really
> seeing; the certs I have set to 2 days are all for corporate internal
> CAs using ACME not Let's Encrypt, my LE certs are still the default
> (30 days now?). I also wonder if they have any sort of crypto
> acceleration going on in the backend to make what I assume to be
> massive amounts of requests flow smoothly.

They are using donated Hardware Security Modules (or were in 2021).

https://letsencrypt.org/2021/02/10/200m-certs-24hrs/#hsm-performance

HSMs do often include some kind of crypto accelerator rather than using
their main CPU. However the need for an HSM in this particular context
is not about performance as such (although of course they do need to
satisfy the service’s performance requirements); it’s about protecting
the signing key. See s6.2.7 of:
https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.1.1.pdf

The analysis in the blog post is about the cost of re-signing everything
during disaster recovery. If the 200M total certificates figure is
still approximately right then renewing every 6 days is under 400TPS.
Even with 100%+ growth in the intervening years a single HSM is not
going to much trouble keeping up.

--
https://www.greenend.org.uk/rjk/

On Thu, 12 Dec 2024 22:28:30 +0000, Broseki wrote:

> On Dec 12, 2024 at 1:07:53 AM EST, "Lawrence D'Oliveiro"
> <ldo@nz.invalid> wrote:
>
>> When I started using Let’s Encrypt, I found the default setting for
>> Debian was to check for renewals twice a day. That shocked me a bit,
>> but I assume they knew what they were doing.
>
> That is an interesting point; I wonder how much load they are really
> seeing; the certs I have set to 2 days are all for corporate internal
> CAs using ACME not Let's Encrypt, my LE certs are still the default (30
> days now?).

All the certs I have any responsibility for are valid for 90 days.

> I also wonder if they have any sort of crypto acceleration
> going on in the backend to make what I assume to be massive amounts of
> requests flow smoothly.

I imagine that checking for the validity of a cert itself can be done
using some less-security-sensitive database without resort to the HSM, so
having to do it 180 times before a renewal is probably not considered
excessive.

Rich <rich@example.invalid> wrote:
> D <noreply@mixmin.net> wrote:
> > On Wed, 11 Dec 2024 20:27:37 -0300, Salvador Mirzo <smirzo@example.com> wrote:
> >>Let's Encrypt is planning a 6-day TLS certificate for next year.
> >>> Our longstanding offering won't fundamentally change next year, but we
> >>> are going to introduce a new offering that's a big shift from anything
> >>> we've done before - short-lived certificates. Specifically,
> >>> certificates with a lifetime of six days. This is a big upgrade for
> >>> the security of the TLS ecosystem because it minimizes exposure time
> >>> during a key compromise event.
> >>Source:
> >>https://letsencrypt.org/2024/12/11/eoy-letter-2024/
> >
> > seems like everyone is using tls . . . is there anyone "not" using it?
>
> Given Chrome's "insecure" branding in the URL bar from the "make
> everything https" push some years back, there are far fewer who are not
> using it.
>
> But six day expiry dates, that just sounds insane.

It sounds quite handy to me. One of the problems with Let's Encrypt is that
you set up your server, you get a LE certificate, you set up a cron job for
renewal. And then 90 days later you find out that your cron job didn't work
for $reasons and the cert expired. Making this timeout 6 days means that
you find this bug much quicker - if it's still working after a couple of
weeks then things are good.

I might not want to use them in production unless I had a specific concern
over revocation, but being able to use a 6 day cert for the initial
bringup and then move to a 90 day cert once things are stable could be
handy.

Theo

On 13 Dec 2024 18:22:25 +0000 (GMT), Theo wrote:

> One of the problems with Let's Encrypt is
> that you set up your server, you get a LE certificate, you set up a cron
> job for renewal. And then 90 days later you find out that your cron job
> didn't work for $reasons and the cert expired.

Debian provides a systemd timer definition to take care of this for you as
a standard part of its certbot package. By default the timer task runs
twice a day.

If you want to handcraft your own solution, have it run at a similar
frequency, at least to start with, to ensure it works properly. You can
also test out dummy renewals as part of that process.

In comp.misc, Theo <theom+news@chiark.greenend.org.uk> wrote:
> It sounds quite handy to me. One of the problems with Let's Encrypt is that
> you set up your server, you get a LE certificate, you set up a cron job for
> renewal. And then 90 days later you find out that your cron job didn't work
> for $reasons and the cert expired. Making this timeout 6 days means that
> you find this bug much quicker - if it's still working after a couple of
> weeks then things are good.

When I have problems, I get mail from Let's Encrypt saying things like
"your cert is expiring in two weeks, did you know that?". That's why you
give them an email address during setup.

In my case, it's usually not because there is an issue with cron, but
because I have N names in one cert and I deleted the DNS record for one
of those and didn't update the LE config. They, quite rightly, don't
like to give out certs for names that don't resolve.

Elijah
------
sometimes uses wildcard certs