Let's Encrypt is adding two additional remote perspectives for domain validation

Without DV certs, much of the web might not be encrypted at all.

I think few independent site owners would go through the more costly and complicated EV process.

Without major cross-national legal changes, OV/EV certificates on the open web are pointless at best and misleading to the point of being dangerous at worst. They remain quite useful in specific scenarios outside of normal web browsing, but that's not the issue at hand.

I liked the idea conceptually of CAA record only allowing DNS validation. Then use DNSSEC.

I say “conceptually” since I know: 1. Actual attacks found with CT have used compromised TLDs, which kills the whole thing anyway, and 2. I haven’t really seen where the hosting company’s infrastructure (BGP ads and internal routing) is what’s compromised. Well certainly in the latter case they can probably also get in to the hosting machines directly.

> For DV, if you can successfully MitM every connection to a destination, then you _do_ own the domain.

That's a policy, not an inherent consequence of DV certs.

If every verification method other than DNS was shut off, it would still be DV, but with care it could be immune to MitM. I'm not advocating for that, but it's an option.

I went through the standard validation many times and the entire process felt like a security theater. For example, I had to upload a scan of my ID, but I know for a fact that in my jurisdiction no private entity can access government databases to validate that it is a genuine ID and not a photoshopped image. The government provides a SSO that third parties can use, but none of the main cert issuers implemented it, even for EV certs. They just trusted a JPEG.

It's like those arcane verification checks used by US-based services that ask for utility bills, as if they had any way of verifying an invoice issued by a small utility provider in rural Finland.

Arguably in the extremely early days of SSL this is how it works, because the Certificate Authorities have never done this before and so sure, we fly our account excecutive out to your New York HQ and they sign (with a pen) a contract for $5000. Those early certificates are, by modern standards, worthless garbage, Chat GPT can probably teach you how to forge one though it might be too expensive for an amateur to do at home - but they do have street addresses and so on if you cared to read them. A web browser of course did not read those street addresses, and it has even less idea than you do whether the details correspond to reality.

Within a few years at most the Race to the Bottom is well underway - if I spent $10 on my "streamlined" process to offer 1000 certificates for $10 each I make more money than a rival spending $1000 to offer 100 certificates for $100 each. As a result "Domain Verification" is normal by the turn of the century. If you weren't here for the Dotcom boom, you have never seen any of this. If you bought books on this stuff on Amazon, or worse you've never read any books about it because it was all online, you arrived after DV was everywhere.

A peer mentions EV, that and OV are actually newcomers, the CAs realised that customers don't want to pay $100 for a "better" certificate when customers can't tell the difference so there began a meeting, the CA/Browser Forum sometimes just referred to as "cab" or "cabf". This meeting had two initial outputs. One of them endures to this day and only got stronger:

1. Certificate Authorities must meet at least certain Baseline Requirements (the "CA/BF BRs") for all certificates. You can't issue certificates which do not meet these requirements, putting a floor on how terrible your verifications can be.

2. Browser Vendors will add shiny UI for a new "Enhanced" verification certificate so that customers can see it's better and that's a new sales opportunity for CAs.

In practice after some years (2) stopped making sense. A shiny UI works on a desktop PC but there's no room on an early smartphone, so you just don't add this. Soon enough you make Desktop browsers look the same as your smartphone product and all the time your UX experts are telling you users do not undertand this UI (no surprise it was just a sales gimmick) and Safety experts are telling you that it's a net negative for user safety. So, bye bye EV UI in browsers.

But the other side of the bargain went very well. The BRs were a ratchet. In 2012 a ten year certificate issued based on some sales guy who met the director of a company at lunch was fine. By 2016 even five years is clearly too long and we should check some actual official records or have some kind of formal process. In 2012 it's fine to issue for mysql.test.internal because that's not a public name right? By 2016 uh, no, that's why it's not OK to issue that certificate, nobody could possibly own that name, do not issue bogus certificates, this is Serious Business. The BRs are how, gradually, we got where we are today.

I.e.:

> An Extended Validation (EV) Certificate is a certificate conforming to X.509 that proves the legal entity of the owner and is signed by a certificate authority key that can issue EV certificates. EV certificates can be used in the same manner as any other X.509 certificates, including securing web communications with HTTPS and signing software and documents. Unlike domain-validated certificates and organization-validation certificates, EV certificates can be issued only by a subset of certificate authorities (CAs) and require verification of the requesting entity's legal identity before certificate issuance.

* https://en.wikipedia.org/wiki/Extended_Validation_Certificat...

> http-01

Good point, I forgot about that! But then CAA record might help, I guess, if you specify your accounturi?

http-01 seems absolutely unreliable, any hosting provider or any government can issue fake certificates using it. What a garbage technology.

I don't see how you can have actual "proof of domain ownership" without secure DNS, or some kind of similar PKI. Right now they don't check for proof of domain ownership at all, just whether you have temporary, de facto control of the DNS record or the network it points at. This usually works well enough, but won't do anything if a MITM attack occurs on the server side rather than the client side.

Become your own root CA for that system

Traefik does HTTPS almost as seamlessly as Caddy and is geared more for production and enterprise

I did the same. I found the same about it predating Snowden, but I also found this quote from J Alex Halderman in a remembrance of Peter Eckersley.

> That summer, Edward Snowden came forward with chilling revelations about NSA mass surveillance, and the need for ubiquitous encryption became clearer than ever.

It’s not a claim that it was the instigator, but it seems like it was heavily on their minds.

> There was already talk of needing HTTPS everywhere. Snowden's release got more support behind it, and brought the timeline forward.

Google made HTTPS default-on in 2010, but there was a toggle so that you could disable the forced use:

* https://workspaceupdates.googleblog.com/2010/01/default-http...

In 2014 the toggle was removed and all connections were forced to HTTPS.

The Snowden revelations occurred in 2013:

* https://en.wikipedia.org/wiki/Snowden_disclosures

That only applies when you're replying to someone. It doesn't apply to new conversations or adding someone new to an existing conversation.

Let's Encrypt has always had short-lived certificates, long before they were mandated by the CAB. They've been pushing the cutting edge here

And at how many days or minutes does it turn from security into security theater?

If we follow this line of thought it would be more secure to only serve sites to consumers through a few "trusted" third parties right?

Certificate revocation applies to all uses of PKI, not just web browsers. In fact, it is an even bigger problem with email, because there are so many more email addresses than web sites.

But you can't re-use the private key, and you can't keep the same one around for very long. In a thread about "why can't we do Let's Encrypt but for email", surely we must start by accepting one of the most important lessons of the modern WebPKI era, which is that CRLs and OCSP do not work at the scale involved here, which has led to keys and thus certificates being constantly rotated.

Somebody else already said "key management is the hardest problem" and I wholeheartedly agree.

The short lifespans are to encourage people to actually automate, not just say they want to.

If the cert lifetime is 5 years, Bill installs "just the first one" manually, solemnly swearing they will automate next time, and in five years nobody even knows who Bill was, Bill left three years ago. How do we replace the certificate?

If the cert lifetime is 2 years. Bill is still there or maybe somebody on the team still knows Bill's email address, but most likely the decision is taken to "just do it manually once because it's urgent" and we just recurse. This would have been the "obvious" choice when ISRG lit up Let's Encrypt.

But because the cert lifetime was 90 days, Bill gets told it's expiring at about the same time he's about to shove that "Actually automate certificates" work onto the back burner. Oh yeah, right, we should actually do that.

Now, it may be that at a startup that "Automation" is initially "Put it on Natalie the intern's TODO list every Monday" but by week six Natalie has learned about cron, or Windows event scheduling, or a dozen other ways to make stuff you always do regularly happen without actual work. Today I expect her LLM will tell her how to do it.

And Natalie is going to discover that some "permanent" solutions are more permanent than others, that you want monitoring and so on. But because Let's Encrypt is so popular unless you're doing something pretty esoteric you won't even be the first person to ask about it this month.

You wouldn't. Let's Encrypt doesn't verify anything more than that the requestor of the HTTPS certificate currently has control over the domain. The equivalent would verify nothing more than that the requestor of the S/MIME certificate currently has control over the email address. This part is actually a fairly standard procedure already, as a lot of websites will send verification emails to fully activate new account signups.

Persona?