When a user visits an https site, and gets an invalid certs, and an exception for this site already exists, but the cert now being served by the server does not match the cert that is already captured in the exception, the error page shown to the user should be more dire than the usual invalid cert page. It should NOT appear to the user to be just another case of encountering a cert that cannot be validated, but should call attention to the fact that it is not the cert that the user himself has previously accepted. This is a fundamental tenet of KCM. In KCM, the most eggregious form of error, and the error most worthy of complaining to the user, is that the site is now apparently serving a different public key (different cert in https) than before.

Should this bug be driven by browser UI developers? nsICertOverrideService::getValidityOverride could be used to distinguish the reported error from the stored override. Or should the PSM backend produce a different error message?

Isn't this a dupe of bug 399914?

I guess this bug asks for a better display in the error page, bug 399914 asks for a better feedback in the add-exception dialog. I think it makes sense to combine both bugs, and whenever we work on a fix, both places must be updated.

Yeah, the difference between these two bugs is the dialog/page in which they happen, and the products in which they happen. This bug applies only to the browser. Bug 399914 also applies to Thunderbird.

(In reply to comment #4) > This bug applies only to the browser. Not strictly. The error page contains a string which is the "meat" of the error page, and this meat will be shown in any products where it's not possible to show the error as a page. In those products it will be shown as an error dialog.

reassign bug owner. mass-update-kaie-20120918