In this page of the documentation Certificates for localhost - Let's Encrypt there are 2 sections. One about localhost access for development and one about localhost access for apps.
The second part about app usages describes that using a LE certificate on a localhost hostname is a bad idea. I fully agree about this statement for this kind of use case.
The first part about local development simply says that "the best option" is to go self signed.
I strongly disagree with this because I consider adding a self signed root certificate a serious reduction of security of the system/browser. Any developer accessing their bank information using this same system/browser now has to trust the management of this root certificate is secure enough to do this. I assume it isn't in many development situations so I oppose this solution.
I have done some experimenting and the localhost.example.com setup mentioned in the app part is in my opinion a much better solution for the local development situation.
Put the certificate and key on a company internal server
Use some tooling/scripting to automate the local development to periodically fetch the latest certificate from the company internal server
Configure the local development configs to use the fetched certificate.
Reading through other discussions: This is ONLY for internal distribution WITHIN a company. I.e. NOT public.
The effects:
Any developer can run software in their local IDE (and do debugging and such) and open it in their browser using a valid HTTPS certificate (i.e. all cookies and script behave correctly)
There is no need to reduce the security of the local system/browser to allow self signed certificates.
There is no MITM risk because this is only used for development purposes.
My questions
WHY is selfsigned considered to be the "best option"?
What are the downsides tot the localhost.example.com direction for local development.
And that's because it requires distributing the private key to every device that service is supposed to be on.
Yes, so... don't. I don't know if firefox profiles have a separate trust store, but that could be an option, or a different OS user account, or any of the many chromium based browsers to only be used for development work.
Because you can issue for whatever FQDN you want and rewrite via /etc/hosts, replacing the website for yourself and yourself alone.
B/c you probably shouldn't be accessing your banks website while at work? You can always check the certificate chain in the browser to see if it's a valid chain or a chain up to the private CA.
Plenty of employers where employees are allowed use their work laptop for things like that.
Also; checking the certificate chain is something "nobody" does in real life.
I see there are specific use cases where self-signed is the only option.
The mentioned article describes 2 use cases (local development and apps) and 2 solution directions (self-signed and localhost.example.com). For the apps it describes the pros and cons of both solutions. For the local development it only states "use self-signed" and does not say anything about the localhost.example.com model.
My question is why the generic statement is made that self-signed is the "best option" (something I currently disagree on) without explaining the pros and cons in comparison with the other option mentioned in the same article.
They call it TLS inspection and if you do it on a network you don't own it's a crime (and sometimes even if you own the network).
They are pretty similar to those in the app case. And moreover you have to renew certificates that are used for local development. Minica and picoca are very powerful for doing this. Pebble, even.
Because every time we see either 127.0.0.0/8 or ::1 in global dns we see it as a threat or possible threat. If you really want to use it, at least use /etc/hosts.
Specifically for local development the main risk in using a localhost-resolving-FQDN would probably be a similar MITM concern to the native app use case. If you're proposing to have a single keypair and certificate used by all developers within a company, the private key will have to be relatively accessible and will end up in lots of places which risks compromise. Just because it's a development environment doesn't mean there isn't sensitive information/intellectual property/secrets involved. Compromise of a dev environment will hopefully have less impact than a compromise of production, but less may not equal zero.
While I can understand the concern with adding a self-signed CA to all developer devices, the concerns about compromise of non-development traffic all seem to assume that there would be a single self-signed CA in use across an entire organisation, which is not the only option!
Development tools such as Laravel Valet will generate their own self-signed CA per machine, which massively reduces the scope of risks. If an adversary has access to a machine to obtain the CA's private key in order to sign a certificate for bank.example.com, they're likely going to be able to install their own CA to the trust store anyway, and even then only that machine is compromised. A central self-signed CA is open to many more risks.
Yes, that makes sense in the generic situations seen in companies. In my rulebook a development/testing environment should never have any sensitive data. Yet reality is different in many places.
You can always check the certificate chain in the browser to see if it's a valid chain or a chain up to the private CA.