41–50 of 305 posts
The web today is a rotting carcass with various middlemen maggots crawling all over it and gorging themselves on the decay. The only real discussion to be had is what to replace it with and how to design the new protocols to avoid the same issues.
I've spent 15+ minutes searching, and the digicert (linked to in the article), and other cert providers all reference a vote on "Multi-Perspective Issuance Corroboration (MPIC)". Everywhere I've read, one "must validate domain control using multiple independent network perspectives". EG, multiple points on the internet, for DNS validation. Yet there is not one place I can find a very specific "this is what this means…
Section 3.2.2.9 of this document: https://cabforum.org/working-groups/server/baseline-requirem... You can also just search the document for the word "Perspective" to find most references to it.
"Effective December 15, 2026, the CA MUST implement Multi-Perspective Issuance Corroboration using at least five (5) remote Network Perspectives. The CA MUST ensure that [...] the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries."
"Network Perspectives are considered distinct when the straight-line distance between them is at least 500 km."
The decreasing validity time pushes for the process to be automated, and automation reduces the possible human errors. Many things need to be run and automated when running stuff, I don't understand what makes SSL certificates special in this. For a hobbyist, setting up certbot or acme.sh is pretty much fire and forget. For more complex settings well… you already have this complexity to manage and therefore the peopl…
One of the arguments to be made is that while " automation reduces the possible human errors." it also reduces the amount of human oversight as well.
For new certificate you can keep the existing amount of human oversight in place so nothing changes on that front.
I think a large enough org that needs many different certificates should have an internally-trusted CA. That would then allow the org to decide their own policy for all their internal facing certificates. Then you only have to follow the stricter rules for only the public facing certs.
https://github.com/linsomniac/lessencrypt
I've toyed with the idea of adding the ability for the server component to request certs from LetsEncrypt via DNS validation. Acting as a clearing house so that individual internal hosts don't need a DNS secret to get certs. However, we also put IP addresses and localhost on our internal certs, so we'd ahve to stop doing that to be able to get them from LetsEncrypt.
Software didn't have that sort of "ticking time bomb" element before, I think?
I think I understand why it's necessary: we have a single, globally shared public namespace of domain names, which we accept will turn over their ownership over the long run, just like real estate changes hands. So we need expiration dates to invalidate "stale" records.
We've already switched over everything to Let's Encrypt. But I don't think anyone should be under the delusion that automation / ACME is failproof:
https://github.com/certbot/certbot/issues?q=is%3Aissue%20ren...
https://github.com/cert-manager/cert-manager/issues?q=is%3Ai...
https://github.com/caddyserver/caddy/issues?q=is%3Aissue%20A...
(These are generally not issues with the software per se, but misconfiguration, third-party DNS API weirdness, IPv6, rate limits, or other weird edge cases.)
Anyway, a gentle reminder that Let's Encrypt suggests monitoring your SSL certificates may be "helpful": https://letsencrypt.org/docs/monitoring-options/ (Full disclosure: I wrote the most recent addition to that list, with the "self-hosted scripts".)
I understand OP's frustration, but the alternate view is that mandating better practices is a forcing function for businesses that otherwise don't give a shit about users or their privacy or security. For all the annoyance of SOC2 audits, it sure does make my manager actually spend time and money on following the rules. Without any kind of external pressure I (as a security-minded engineer) would struggle to convince…
Why is a month's expiration better than a year or two years? Why wouldn't you go with a week or a day? isn't that better than a whole month? Why isn't it instead just a minute? or a few seconds? Wouldn't that be better? Why not have certificates dynamically generated constantly and have it so every single request is serviced by a new one and then destroyed after the session is over? Maybe the problem isn't that certi…
Then if your CA went down for an hour, you would go down too. With 47 days, there's plenty of time for the CA to fix the outage and issue you a new cert before your current one expires.
Since the advent of LetsEncrypt, ACME, and Caddy I haven't thought about SSL/TLS for more than about an hour per year, and that's only because I forget the steps required to setup auto-renewal. I pay nothing, I spend a tiny amount of time dealing with it, and it works brilliantly. I'm not sure why many people are still dealing with legacy manual certificate renewal. Maybe some regulatory requirements? I even have a w…
> I am responsible for approving SSL certificates for my company.
And that is exactly what the requirements are intending to prevent. Automation is the way.
The system is working!
I've spent 15+ minutes searching, and the digicert (linked to in the article), and other cert providers all reference a vote on "Multi-Perspective Issuance Corroboration (MPIC)". Everywhere I've read, one "must validate domain control using multiple independent network perspectives". EG, multiple points on the internet, for DNS validation. Yet there is not one place I can find a very specific "this is what this means…
I understand OP's frustration, but the alternate view is that mandating better practices is a forcing function for businesses that otherwise don't give a shit about users or their privacy or security. For all the annoyance of SOC2 audits, it sure does make my manager actually spend time and money on following the rules. Without any kind of external pressure I (as a security-minded engineer) would struggle to convince…
Why is a month's expiration better than a year or two years? Why wouldn't you go with a week or a day? isn't that better than a whole month? Why isn't it instead just a minute? or a few seconds? Wouldn't that be better? Why not have certificates dynamically generated constantly and have it so every single request is serviced by a new one and then destroyed after the session is over? Maybe the problem isn't that certi…
He said six figures for the price would be fine. This is an instance where business needs and technology have gotten really out of alignment.