5.5.1 TLS errors
This section covers TLS-related error conditions, and maps them to the classes of error handling interactions (see 6.4 Error handling and signalling) that are used when these conditions arise.
If multiple error conditions apply, the most severe signalling level currently known MUST be used, as defined in 6.4 Error handling and signalling.
When, for a TLS-protected HTTP connection, the certificate chain presented by the server does not lead to a trusted root certificate, and the certificate chain presented was not pinned to the destination at hand, the following applies to user agents that are capable of storing the state of certificates that were previously encountered:
- If a validated certificate (including an augmented assurance certificate) was previously presented by the same destination, then error signalling of class danger (6.4.4 Danger Messages) MUST be used.
- If a different certificate was previously pinned to the same destination, then error signalling of class warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages) MUST be used. User agents MAY offer the possibility to pin the newly encountered certificate to the destination at hand. Note that this newly pinned certificate could be the basis for a spoofing attack, or it could represent a refresh of an Self Signed Certificate.
- Otherwise, user agents MAY use error signalling of class notification (6.4.2 Notifications and Status Indicators ) to offer pinning a given certificate, consistent with 5.1.5 Self-signed Certificates and Untrusted Root Certificates.
- Otherwise, user agents SHOULD use error signalling of class warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages).
For user agents that are not capable of storing the state of certificates that were previously encountered, the following applies:
Error signalling of class warning or above MUST be used to signal the error condition.
User agents MAY offer the possibility to pin the newly encountered certificate to the destination at hand. Note that this newly pinned certificate could be the basis for a spoofing attack, or it could represent a refresh of an Self Signed Certificate.
User agents SHOULD store the state of certificates that were previously encountered (specifically, whether or not a site previously presented a validated certificate). Historical TLS information stored for the purposes of evaluating security relevant changes of behavior MAY be expunged from the user agent on the same schedule as other browsing history information. Historical TLS information MUST NOT be expunged prior to other browsing history information. For purposes of this requirement, browsing history information includes visit logs, bookmarks, and information stored in a user agent cache.
When certificate information is presented in these interactions, human-readable information derived from the certificates (e.g., Common Name or Organization attributes) in question MUST NOT be presented as trustworthy.
When certificate information is presented in these interactions, web user agents MUST NOT display identity information from a self signed or untrusted certificate in a warning or error message. Web user agents MAY display this information in a dialog or other secondary chrome reachable through the warning or error message or dialog.
When, for a TLS-protected HTTP connection, the certificate presented is found to have been revoked, error signalling of class danger (6.4.4 Danger Messages) MUST be used.
When, for a TLS-protected HTTP connection, the certificate presented is found to have been expired, error signalling of class danger (6.4.4 Danger Messages) MUST be used. Note that user agents that apply Relaxed Path Validation to non-AA certificates will never detect this error condition for such certificates.
When the URL corresponding to the transaction at hand does not match the certificate presented, and a validated certificate is used, then error signalling of level danger(6.4.4 Danger Messages) MUST be used.
If TLS negotiation otherwise fails, error signalling of level danger (6.4.4 Danger Messages) MUST be used.
<deleted past paragraph>