Lcl.host: fast, easy HTTPS in your local dev environment

i.e. I don't think that the authors of this tool wanted to have developers be forced to use the latest version of their tool.

It's probably that they didn't think about it when they wrote the code, but now they know and hopefully this gets fixed in the next release?

Also, I echo the other people saying that the typeface you chose for the website is very difficult to read.

Mozilla bricked SSL certificates that are mandatory for everything, including Browser Extensions.

There is a flag for about:config to unbrick it. Problem is though, that this lasts less than a second because of the remote settings service running in a loop. If you block that services domain with a host firewall (like opensnitch), Firefox will do an endless for loop using 100% CPU load trying to request the shavar and other services domains.

So, effectively, you cannot run an old Firefox version, and especially not a version that uses the old bundled mozilla certificate (which is all provided download variants).

That's what the previous commenter was (likely) referring to.

With chrome, that's something like:

    google-chrome
        --user-data-dir="${HOME}/.config/ourlocaldev/google-chrome"
        --install-autogenerated-theme=85,63,9
        --host-rules="MAP * 127.0.0.1, EXCLUDE localhost, EXCLUDE fonts.googleapis.com, EXCLUDE fonts.gstatic.com"
        --ignore-certificate-errors-spki-list="0oKw9nasIS7qRQD1CYXe5bmi22/mnHjZP++f6G+VM88="
        "https://my.dev.thing"

The danger if someone got their hands on my local key/cert is basically nil. They would only be able to MITM connections from this one specific browser window to localhost. And that browser is incapable of connecting to anything besides localhost. I can never accidentally open my banking site in there. Also fresh profile so no saved passwords, credit cards, or anything else.

(As an added benefit, I don't really need to worry about reconfiguring URLs for projects. If I open "testing.mysite.com" in that browser, it will force the connection to localhost, so I can just run my services at our test URLs and steal configs as-is from the testing environment. Taking it further, I then have a controller set up in k3s/Rancher Desktop that rewrites the service on all annotated ingresses to point to its own service, which runs nginx, which the controller then configures to proxy the requests on to the local service or the actual upstream testing service depending on whether the local container is running. It also configures CoreDNS to point the upstream URLs at the same proxy. End result is that from the browser or anything running in k3s you can hit our testing URLs and it will hit your local container if it's running or fall back to the testing environment if not.)

If you want to try the browser thing, you can generate the fingerprint for a certificate with:

    echo "" |
    openssl s_client -connect 127.0.0.1:443 -prexit 2>/dev/null |
    openssl x509 -pubkey -noout -in /dev/stdin |
    openssl pkey -pubin -outform der |
    openssl dgst -sha256 -binary |
    openssl enc -base64

It'd be annoying if you need to make a new localhost certificate, but totally manageable.

If you have appropriate permissions on the private keys, it would require the same level of access to read the private key as it would for the attacker to create their own CA and install it on your PC.

My general rule of thumb is to use private certificates unless a) users interact with it directly, cuz they won't install my cert, or b) financial or other highly sensitive data flows through it. I'm not convinced that commercial CAs are more secure, but for the price of an SSL cert, it's worth it to have it not be my fault if something happens.

I use traefik to serve my apps in dev, which generates self-signed certs by default if you don't hook it up to ACME. Slightly more cumbersome because it means clicking through a warning screen and disabling verification in CLI tools (actually those are where I do drop to plain http). I'm sure this lcl.host product smooths this process considerably, but when it comes to local dev tools, I have an absolute requirement that they actually run locally and don't tether me to some cloud service, so I'll be sticking with traefik regardless for now.

Were you using the package manager packages? I'm a little surprised if the distro packages don't configure Firefox to use the OS trust store. I would not be surprised if the binaries Firefox provides directly don't trust the OS package store. They probably shouldn't, given that the path to the OS trust store is configurable. I think Ubuntu and Fedora use slightly different paths.

Seems like a security nightmare to try guessing at what directory has the OS trust store. Better to leave it to the package maintainers to specifically customize it for their distro's patterns.