tripple

• uBlock Origin
• NoScript
• Bitwarden

--

I previously used Privacy Badger, but I block basically everything with NoScript anyway, so it was redundant. I also used HTTPS Everywhere but you can enable that in most (all?) browsers now anyway, so you don't need an extension any longer (the highest form of success for an extension). I also previously used LastPass, but I got out before they had their security issues, and importantly changed every password when I transitioned. On work computer I have the 1password extension.

There's a couple reasons. A practical one is that it makes it easiest to get a working setup when trying out the service. Otherwise you need to alter your DNS settings to connect to your site. Being able to run the Caddyfile in the docs to get a working site is (hopefully) a great first experience.

Sometimes you really want to test your HTTPS config, so HTTP doesn't help. Like if you are setting up an HTTPS reverse proxy or using Caddy's built-in automatic TLS feature. getlocalcert.net can allow you to use the same Caddyfile in production and testing (just use different config/credentials). Most web developers won't care about that distinction, but anyone Ops side will. Sometimes your clients aren't web browsers so the special treatment of localhost doesn't apply.

Very nicely ask for a draw.

Yes, there's two approaches I'm using currently. When you register a subdomain you can choose either localhostcert.net or localcert.net. The former has an A record in the public DNS that points to 127.0.0.1. The latter has no public A records so you need to manage them yourself, possibly with a local DNS resolver like unbound.