Comment 4 for bug 239360

We have decided (somewhere else) that we no longer want to import server certs and assign trust to them. Because when a user enters an override, it should be limited to the current hostname (and ideally port). However, the cert could carry hostnames that would allow it to become valid for additional hostnames. This is an unwanted side effect of "importing and trusting a cert".

Therefore I propose we no longer import the cert with general trust added, because it's not necessary.

The new code I'm adding in bug 327181 uses a dynamic approach. It stores {hostname,port,cert-fingerprint} together with the allowed override. At the time we open a connection, the list of overrides is checked against the cert presented by the peer server. If all hostname, port and cert-fingerprint matches with our override entry, the cert will be allowed.

However, the above is not sufficient to display a full cert in cert manager's "web site tab".

Maybe, in addition to the list of triples described above, should we import the server cert without any trust? Hmm, but in order to allow for finding the real cert based on the trip, we might need to store the issuer+serial-number in the override list as well.