I'm not sure I understand this post. Is this talking about self hosting Caddy in a home lab setting or just static web hosting on a VPS?
The details remind me more of the Bluesky PDS though. It's nodejs-based and the only officially supported way to run it is via a largely self-contained docker container.
I just wish nginx / caddy / etc had better out-of-the-box support for letsencrypt. It would be way easier to set up if it was just built in to nginx. Let me specify my domain in my nginx config, and just make it work.
AFAU Let's Encrypt gets its money from Google. There are other minor providers of similar services over the ACME protocol, but this does not change the fact that they issue the the majority of the free TLS certificates.
We already had one centralized domain name system managed by the US Government that we have to hop through before publishing our content online for everyone.
Now, we silently and tacitly added another US-based one.
Here's how it could work: First, you generate a tls signing certificate. The signing cert gets stored in DNS. When anyone makes a DNS query, the response contains your root certificate's signature (HMAC). When you initiate a TLS connection, you check the root certificate in the cert chain against the signature provided over DNS.
The dns response would also need to be cryptographically signed by the dns provider. Instead of operating systems shipping trust roots of TLS cert providers, we ship the root certificates of DNS registrars. Eg, .com, .com.au, etc would each publish one or more root certificates that would get distributed with operating systems.
Trust already depends on dns (since that’s how you prove who you are to letsencrypt). So the whole system would rely on fewer trusted entities - which would hopefully make it more secure. It would be simpler to run - less organisations needing to do anything. And simpler to make use of, since you wouldn’t need programs like certbot to keep your tls certs up to date. This would also prevent the danger of malicious TLS providers being involved in MITM attacks on TLS.
That is, if they inject JS or modify the data in any way, they are liable for the content, otherwise not.
Computers are fast now. We should just encrypt everything that gets sent over the open internet.
The IETF put out a statement about this a few years ago. I agree with their stance.
> The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations, and to make them encrypted by default. We similarly encourage network and service operators to deploy encryption where it is not yet deployed, and we urge firewall policy administrators to permit encrypted traffic.
https://datatracker.ietf.org/doc/statement-iab-statement-on-...
An art professor I knew used to say about overwrought paintings "too much sugar for a dime". Technical people are often prone to this as well.