Are SAN IP addresses / DNS names useless in self signed certificates by untrusted CAs?

Question

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).

Answer 1

If you make an explicit exception to bypass a a certificate warning this exception is only valid for this specific certificate on this specific domain. It does not matter what domains are mentioned in the certificate, the exception is only added for the current domain. Thus, even if you accept a certificate which contains a SAN of paypal.com on your testsite.example.org this certificate will only be trusted for testsite.example.org and this trust can not be used to silently MITM access to paypal.com.

In other words: the specific content of the certificate (CN, SAN, expiration ...) and also the issuer (self-signed, signed by untrusted CA) are irrelevant when adding an explicit exception.

Answer 2

If certificate chain is not trusted, there are no much reasons to validate other fields, like names, time validity, etc. The fact that Edge complains about invalid name (along with untrusted CA) means that Edge performs additional checks and returns a cumulative list of all issues. Other browsers may not bother with additional checks and fail on first error. Both behaviors are acceptable from security perspective.

The "Untrusted CA" error means that the certificate was generated by someone we don't know and whatever is written in the certificate is literally a junk and browsers may save your time by skipping other (including SAN) content validation.