The CA/Browser Forum (a group that includes those entities that issue
you with attested SSL/TLS certificates) has voted to severely shorten
the valid duration of its certificates from one year to just 47 days <https://www.computerworld.com/article/3960658/vendors-vote-to-radically-slash-website-certificate-duration.html>.
Some see this as a revenue grab. Yes, it may be, but there are also
good security reasons for doing so.
The revenue-grab reason may backfire. For most purposes, a free cert
service like Let’s Encrypt is quite sufficient, and it’s easy enough
to set your system to run a cron task (or systemd timer) to
auto-renew. This already happens by default on a Debian installation,
for example.
It’s not a revenue grab. It IS yet another of the methods THEY are employing to make it impossible to use the Internet with old, backdoor
-free computers.
The CA/Browser Forum (a group that includes those entities that issue
you with attested SSL/TLS certificates) has voted to severely shorten
the valid duration of its certificates from one year to just 47 days <https://www.computerworld.com/article/3960658/vendors-vote-to-radically-slash-website-certificate-duration.html>.
Some see this as a revenue grab. Yes, it may be, but there are also
good security reasons for doing so.
The revenue-grab reason may backfire. For most purposes, a free cert
service like Let’s Encrypt is quite sufficient, and it’s easy enough
to set your system to run a cron task (or systemd timer) to
auto-renew. This already happens by default on a Debian installation,
for example.
Right, the organizations who will have a real problem are those still renewing certificates manually. They have a choice between spending a
bit more on their own staffing, or automating renewal (probably cutting
their overall costs in the long run).
The CA/Browser Forum (a group that includes those entities that issue
you with attested SSL/TLS certificates) has voted to severely shorten
the valid duration of its certificates from one year to just 47 days <https://www.computerworld.com/article/3960658/vendors-vote-to-radically-slash-website-certificate-duration.html>.
Some see this as a revenue grab. Yes, it may be, but there are also
good security reasons for doing so.
The revenue-grab reason may backfire. For most purposes, a free cert
service like Let’s Encrypt is quite sufficient, and it’s easy enough
to set your system to run a cron task (or systemd timer) to
auto-renew. This already happens by default on a Debian installation,
for example.
Much networking gear, for example, has a web interface for uploading a certificate, but not an automated flow for doing so.
If that gear is also not able to reach the internet it can't do any kind
of 'well-known' challenges.
I'm sure there are workarounds, but they won't necessarily apply to
what's already out there.
Plus include the fact that google and friends are trying to block
'http' (no s) static sites, seems it is a continuation of a war on
General Computing.
Richard Kettlewell <invalid@invalid.invalid> wrote:
Right, the organizations who will have a real problem are those still
renewing certificates manually. They have a choice between spending a
bit more on their own staffing, or automating renewal (probably
cutting their overall costs in the long run).
I can see this being a big pain for private infrastructure. Much
networking gear, for example, has a web interface for uploading a certificate, but not an automated flow for doing so. If that gear is
also not able to reach the internet it can't do any kind of
'well-known' challenges.
The revenue-grab reason may backfire. For most purposes, a free cert
service like Let’s Encrypt is quite sufficient, and it’s easy enough
to set your system to run a cron task (or systemd timer) to
auto-renew. This already happens by default on a Debian installation,
for example.
On Sat, 12 Apr 2025 14:06:58 -0000 (UTC), John McCue wrote:
Plus include the fact that google and friends are trying to block
'http' (no s) static sites, seems it is a continuation of a war on
General Computing.
I don’t know why you think general-purpose computers are incapable of secure communication through the Internet. Where do you think such secure communication got invented?
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sat, 12 Apr 2025 14:06:58 -0000 (UTC), John McCue wrote:
Plus include the fact that google and friends are trying to block
'http' (no s) static sites, seems it is a continuation of a war on
General Computing.
I don’t know why you think general-purpose computers are incapable of
secure communication through the Internet. Where do you think such
secure communication got invented?
Of course they can connect right now, but as time goes on
I am sure at some point, general purpose computers will start
being blocked. Google no longer returns non-secure sites.
Firefox blocks ftp sites and I believe http pages unless you
go looking for options to set.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
The revenue-grab reason may backfire. For most purposes, a free cert
service like Let’s Encrypt is quite sufficient, and it’s easy enough to >> set your system to run a cron task (or systemd timer) to auto-renew.
This already happens by default on a Debian installation, for example.
What about the increased load on the servers of all the extra renewals?
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sat, 12 Apr 2025 14:06:58 -0000 (UTC), John McCue wrote:
Plus include the fact that google and friends are trying to block
'http' (no s) static sites, seems it is a continuation of a war on
General Computing.
I don’t know why you think general-purpose computers are incapable of
secure communication through the Internet. Where do you think such
secure communication got invented?
Of course they can connect right now, but as time goes on I am sure at
some point, general purpose computers will start being blocked.
For most purposes, a free cert service like Let’s Encrypt is quite sufficient ...
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 481 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 15:17:52 |
| Calls: | 9,540 |
| Files: | 13,653 |
| Messages: | 6,139,700 |