Error handling in display of security context information is problematic. Users should only be should errors and asked to do something about such errors when 1) they can understand the error and any risk, or 2) the action they are asked to take is clearly stated and easily followed. Otherwise, 3) the action should be taken for them, or 4) they should not be told about the error (security indicators should instead be alterred to reflect that reliable security information is not available to the user). Any error text or explanation displayed should match the user's model of what they did and what is happening.
It is a particularly bad idea to issue an error or warning in a situation where it is uncalled for, as it trains the user that security errors are spurious. Error dialogs that the user disables are a symptom of this problem.
Security context information that relates the lack of security, the lack of security context, or the lack of security context that the user expects, is not an error. It is security context information, and is to be handled as such. The model for displaying security context indications must deal with the potential of internal inconsistencies, and present to the user the conclusion the user may usefully draw (with the more detailed inconsistency information available as an option). For example, the SSL/TLS protocol with an expired certificate is in a sense inconsistent, in that the protocol itself is (attempting to) provide a certain set of security guarantees, but with a certificate that does not provide base security guarantees.
Lack of security context information and negative security context information may be two different states. For example, no SSL/TLS may be represented differently from an explicit request for SSL/TLS (or an implicit request for security through inputting information) when the security is not provided by the server. Another potential example would be the lack of certificate revocation information (no OCSP) vs. the certificate being revoked. These are only potential examples; the user model for security context information will determine which items are reflected at the highest level, and which are available on inquiry. That model will have to deal with the possibility that security context inputs may be unreliable (not always available).
Different users, and different organizations, may want different defaults in what set of security context indicators map to particular higher level display states. User agents will user the configuration facilities available in other contexts to allow for customization of that information. They may also have a small number of preset defaults to choose from, reflecting various levels of concern or strictness in security policy.
Redirecting users is common practice on the web, in order to allow a number of differently typed URLs to take the user to the same web site. In the case of redirection of an https: URL to an SSL authenticated web site, RFC 2818 requires the user agent to check the certificate of the site being redirected to against the site the user typed in. If the site the user typed in does not match the certificate, RFC 2818 requires that the user agent warn the user, or terminate the connection. It is an anti-pattern for a conforming site to be configured so that the user is in this error state when they typed a URL that can be legitimately redirected from. The site must use a certificate that contains the hostname of all sites that can lead to the redirected to site, either by extensions, or wildcards.
User agents should not issue an error or warning in this case, since it is confusing and unactionable to the user. The displayed security indicator should make clear to the user where they are, and what the actual security is. This may mean not indicating server authentication or identity, if it cannot be reliably and usefully conveyed.