I want to generate a self signed certificate for temporary local testing of a web service via HTTPS. I don't want to install the CA though, because the self signed certificate is generated on the fly with each start of the web service and I'd have to install the new CA each time. I'm fine with clicking "Advanced -> Proceed (unsafe)" each time.
So when thinking about which IP addresses and DNS names to add to the SAN, I tried out using invalid and empty DNS names, but Firefox and Chrome didn't complain about mismatching hostnames at all. They only complain about the untrusted CA. Edge on the other hand complains about the mismatching hostname and only when including the host that's used for accessing the web service is used as IP address / DNS name in the SAN it complains about the untrusted CA.
I was expecting to be warned about both issues in all browsers: The untrusted CA and the mismatching hostnames. Because let's say I temporarily trust ("Advanced -> Proceed (unsafe)") self signed certificates based on what Firefox lists under "The certificate is only valid for the following names:", I still want to be protected from Man-in-the-Middle attacks, no?
Currently, if I generate a self signed certificate with SAN IP address "127.0.0.1", "192.168.178.123" (LAN IP address) and DNS names "localhost", "alice" (hostname) and "alice.local" and I temporarily trust the CA, an attacker could now redirect the traffic via his machine with the DNS name "eve.local" and generate a new self signed certificate with "alice.local" etc. (but without "eve.local") and I as the user would only be warned about the untrusted CA.
If this behavior is intended (by the browsers), why bother setting a SAN at all? Just setting "" as DNS name seems to have the same effect (at least when the CA is not installed).