Apache comes with built-in ACME support. Just enable the mod_md module: https://httpd.apache.org/docs/2.4/mod/mod_md.html

But the requirements you listed aren't actually requirements of ACME, they're lazy choices you could make but they aren't necessary. Some clients do better.

For example the client needs a Certificate Signing Request, one way to achieve that is to either have the client choose the private keys or give it access to a chosen key, but the whole point of a CSR is that you don't need the private key, the CSR can be made by another system, including manually by a human and it can even be re-used repeatedly so that you don't need new ones until you decide to replace your keys.

Yes, if we look back at my hopes when Let's Encrypt launched we can be very disappointed that although this effort was a huge success almost all the server vendors continued to ship garbage designed for a long past era where HTTPS is a niche technology they barely support.

It's cheap. If the client was done today, it would be based on AI.

Copilot suggests:

    docker run --rm \
      -v /srv/mywebsite/certs:/acme.sh/certs \
      -v /srv/mywebsite/public/.well-known/acme- 
      challenge:/acme-challenge \
      neilpang/acme.sh --issue \
      --webroot /acme-challenge \
      -d yourdomain.com \
      --cert-file /acme.sh/certs/cert.pem \
      --key-file /acme.sh/certs/key.pem \
      --fullchain-file /acme.sh/certs/fullchain.pem

Our backgrounds sound similar. I just don’t sweat all those details when I set things up.

I’m not advocating for the use of cloud services necessarily, not saying we all need to allow someone else to abstract away everything. And I realize that someone on an ops team has to actually set that up at a low level at some point.

What I am saying is that there’s a lot of open source software that has already invented the wheel for you. You can run it easily and be reasonably assured that it’s safe enough to be exposed to the internet.

I gave the example of nginx proxy manager. It may be basic software but for a personal blog it’ll get the job done and you can set it up almost entirely in a GUI following a simple YouTube tutorial. It’ll get you an wildcard certificate automatically, and it’ll be secure enough.

The alternative of the article was ACME vs other ways of getting TLS certificates, not https vs http.

Of course plain http would be, generally, much more dangerous than a however complex encrypted connection

> Does anyone know why they never took off?

Browser vendors at some point claimed it confused users and removed the highlight (I think the same browser vendors who try to remove the "confusing" URL bar ...)

Aside from that EV certificates are slow to issue and phishers got similar enough EV certs making the whole thing moot.

Because they actively thwarted security.

https://arstechnica.com/information-technology/2017/12/nope-...

https://web.archive.org/web/20191220215533/https://stripe.ia...

> this site uses an EV certificate for "Stripe, Inc", that was legitimately issued by Comodo. However, when you hear "Stripe, Inc", you are probably thinking of the payment processor incorporated in Delaware. Here, though, you are talking to the "Stripe, Inc" incorporated in Kentucky.

There's a lot of validation that's difficult to get around in DV (Domain Validation) and in DNS generally. Unless you go to every legal jurisdiction in the world and open businesses and file and have granted trademarks, you _cannot_ guarantee that no other person will have the same visible EV identity as you.

It's up to visitors to know that apple.com is where you buy Apple stuff, while apple.net, applecart.com, 4ppl3.com, аррlе.сом, ., example.com/https://apple.com are not. But if they can manage that, they can trust apple.com more than they could any URL with an "Apple, Inc." EV certificate. When browsers show the URL bar tend to highlight the top-level domain prominently, and they reject DNS names with mixed script, to avoid scammers fooling you. It's working better than EV.

EV can't actually work. It was always about branding for the for-profit CAs so that they have a premium product which helps the line go up. Let me give you a brief history - you did ask.

In about 2005, the browser vendors and the Certificate Authorities began meeting to see if they could reach some agreement as neither had what they wanted and both might benefit from changes. This is the creation of the CA/Browser Forum aka CA/B Forum which still exists today.

From the dawn of SSL the CAs had been on a race to the bottom on quality and price.

Initially maybe somebody from a huge global audit firm that owns a CA turn up on a plane and talks to your VP of New Technology about this exciting new "World Wide Web" product, maybe somebody signs a $1M deal over ten years, and they issue a certificate for "Huge Corporation, Inc" with all the HQ address details, etc. and oh yeah, "www.hugecorp.example" should be on there because of that whole web thing, whatever that's about. Nerd stuff!

By 2005 your web designer clicks a web page owned by some bozo in a country you've never heard of, types in the company credit card details, company gets charged $15 because it's "on sale" for a 3 year cert for www.mycompany.example and mail.mycompany.com is thrown in for free, so that's nice. Is it secure? Maybe? I dunno, I think it checked my email address? Whatever. The "real world address" field in this certificate now says "Not verified / Not verified / None" which is weird, but maybe that's normal?

The CAs can see that if this keeps up in another decade they'll be charging $1 each for 10 year certificates, they need a better product and the browser vendors can make that happen.

On the other hand the browser vendors have noticed that whereas auditors arriving by aeroplane was a bit much, "Our software checked their email address matched in the From line" is kinda crap as an "assurance" of "identity".

So, the CA/B Baseline Requirements aka BRs are one result. Every CA agreed they'd do at least what the "baseline" required and in practice that's basically all they do because it'd cost extra to do more so why bother. The BRs started out pretty modest - but it's amazing what you find people were doing when you begin writing down the basics of what obviously they shouldn't do.

For example, how about "No issuing certificates for names which don't exist" ? Sounds easy enough right? When "something.example" first comes into existence there shouldn't already be certificates for "something.example" because it didn't exist... right? Oops, lots of CAs had been issuing those certificates, reasoning that it's probably fine and hey, free money.

Gradually the BRs got stricter, improving the quality of this baseline product in both terms of the technology and the business processes, this has been an enormous boon, because it's an agreement for the industry this ratchets things for everybody, so there's no race to the bottom on quality because your competitors aren't allowed to do worse than the baseline. On price, the same can't be said, zero cost certificates are what Let's Encrypt is most famous for after all.

The other side of the deal is what the CAs wanted, they wanted UI for their new premium product. That's EV. Unlike many of the baseline requirements, this is very product focused (although to avoid being an illegal cartel it is forbidden for CA/B Forum to discuss products, pricing etc.) and so it doesn't make much technical sense.

The EV documents basically say you get all of the Baseline, plus we're going to check the name of your business - here's how we'll check - and then the web browser is going to display that name. It's implied that these extra checks cost more money (they do, and so this product is much more expensive). So improvements to that baseline do help still, but they also help everybody who didn't buy the premium EV product.

Now, why doesn't this work in practice? The DNS name or IP address in an "ordinary" certificate can be compared to reality automatically by the web browser. This site says it is news.ycombinator.com, it has a certificate for news.ycombinator.com, that's the same OK. Your browser performs this check, automatically and seamlessly, for every single HTTP transaction. Here on HN that's per page load, but on many sites you're doing transactions as you click UI or scroll the page, each is checked.

With EV the checks must be done by a human, is this site really "Bob's Burgers" ? Actually wait, is it really "Bob's Burgers of Ohio, US" ? Worse, probably although you know them as Bob's Burgers, legally, as you'd see on their papers of incorporation they are "Smith Restaurant Holdings Inc." and they're registered in Delaware because of course they are.

So now you're staring at the formal company name of a busines and trying to guess whether that's legitimate or a scam. But remember you can't just do this check once, scammers might find a way to redirect some traffic and so you need to check every individual transaction like your web browser does. Of course it's a tireless machine and you are not.

So in practice this isn't effective.

Phishers also got EV certs.

The big problem with PKI is that there are known bad (or at least sketchy) actors on the big CA lists that realistically can't be taken off that list.