A sign-in problem needs a narrower description than “the browser rejected the site.” In its March 7, 2017 Firefox 52 release notes, Mozilla said non-HTTPS pages displayed a connection warning when a user clicked a username or password field. For this March 19 retrospective, the useful first record is the page address, the field clicked and the warning actually seen. That is a proposed diagnostic step, not a test carried out here. A login-field warning alone does not establish which certificate rule, if any, affected a connection. [firefox52]

Cookie handling belongs on a different line of that record. Mozilla said Firefox 52 implemented Strict Secure Cookies: an insecure HTTP site could not set a cookie carrying the secure attribute. Do not turn that specific restriction into a claim that every cookie is protected, or infer that a missing sign-in state was caused by it without observing the case. Record the page protocol and the cookie operation separately from the login-field warning; the notes describe a rule, not the cause of an individual failed login. [firefox52]

For a SHA-1 certificate warning, note where the chain ends. Firefox 52’s notes described an untrusted-connection error for SHA-1 certificates leading to a root in Mozilla’s CA program, while continuing to permit chains to manually imported roots. The error was overridable; that is a limit on what the release note proves, not advice to override it. Root origin therefore belongs in a proposed diagnostic record alongside the browser and version. The notes do not show how any particular installation responded. [firefox52]

The browser name cannot be dropped from that record. Google’s November 16, 2016 Chrome notice described SHA-1 removal as a change moving through release channels rather than a switch triggered by a calendar date. It also described an enterprise policy for certificates leading to locally installed trust anchors, but warned that a host cryptographic library rejecting SHA-1 could make that option ineffective. These were Chrome-specific policy statements in an earlier announcement—not evidence that Chrome and Firefox had identical exceptions, or that a machine had reached a particular release by March 19. [sha-1-certificates-in-chrome]

A useful handoff can leave the observed result blank while still identifying what is missing: browser and version, page protocol, the warning or cookie operation, root origin where relevant, and the host-library question raised by Google’s notice. Add the actual observation rather than copying an announced policy into the result column. Google urged enterprises to migrate away from SHA-1 and consult their security teams before enabling its policy; this worksheet proposes no policy change. Mozilla and Google describe their own products here. Their documents supply separate branches of the investigation, not an independently tested diagnosis. [firefox52][sha-1-certificates-in-chrome]

Source documents

  1. Firefox 52.0 release noteshttps://www.firefox.com/en-US/firefox/52.0/releasenotes/?redirect_source=mozilla-org
  2. SHA-1 Certificates in Chromehttps://security.googleblog.com/2016/11/sha-1-certificates-in-chrome.html