FireFox - None of the "sha256" hashes in the integrity attribute match the content of the subresource

Asked 25/5, 2018 at 6:53 Answered 8/5, 2023 at 13:6

We created a web site that uses resources from cdnjs. This site has been live for a couple of months but we have sporadic issues with resources from this CDN and FireFox.

The error in the console for each script/style CDN resource is:

None of the "sha256" hashes in the integrity attribute match the content of the subresource.
The error message in the network tab for each resource is:

The connection used to fetch this resource was not secure

Resources that I have had issues with include these elements (as they appear in our web page):

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/bootstrap3-dialog/1.35.4/css/bootstrap-dialog.min.css" integrity="sha256-wstTM1F5dOf7cgnlRHIW3bmoRAAGh6jL7tMIvqTuFZE=" crossorigin="anonymous" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/bootstrap-datetimepicker/4.17.47/css/bootstrap-datetimepicker.min.css" integrity="sha256-yMjaV542P+q1RnH6XByCPDfUFhmOafWbeLPmqKh11zo=" crossorigin="anonymous" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/jqtree/1.4.4/jqtree.min.css" integrity="sha256-ymsp1QFcwiJbIgAoSOkMtqe4GFczZH1KjXLq6y5f+QY=" crossorigin="anonymous" />
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" integrity="sha384-wvfXpqpZZVQGK6TAh5PVlGOfQNHSoD2xbE+QkPxCAFlNEevoEH3Sl0sibVcOQVnN" crossorigin="anonymous" />
<script src="https://cdnjs.cloudflare.com/ajax/libs/bootstrap3-dialog/1.35.4/js/bootstrap-dialog.min.js" integrity="sha256-IpgnbT7iaNM6j9WjtXKI8VMJ272WM9VvFYkZdu1umOA=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.15.2/moment-with-locales.min.js" integrity="sha256-K+AZsAFjiBd4piqBmFzaxDsiQiHfREubm1ExNGW1JIA=" crossorigin="anonymous"></script>

Steps to reproduce

You can reproduce the problem with one of the above URLs and place it directly in the URL of the FireFox browser. The resource should load in the browser window but after pressing CTRL+F5 at least one time (could be up to 5 times) an error will appear. I can duplicate this from multiple PCs although we are located in the Netherlands so maybe a timing issue or something similar (beyond my expertise)?

This does not happen with any other resources from other CDNs that we are using like the following:

<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script>
<script src="https://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>

My environment:

Windows 10 Pro 64bit patched to latest
FireFox 60.0.1 (64-bit)

My question

Is this an issue that is specific to cdnjs and they must resolve this or is this an issue with FireFox or is this an issue with how we are requesting the resource?

As a side note we also regularly test our software on Google Chrome, MS Internet Explorer 11, MS Edge, and Opera and have never experienced this problem on these browsers (or any other for that matter).

I have already created a post on Mozilla's forum but the response was that this is out of scope with a recommendation to post it on SO or submit a bug on GitHub. I have not done the latter becomes I am not (yet) convinced this is a bug in FireFox. I have also submitted an issue on cdnjs's github repo.

Yare answered 25/5, 2018 at 6:53 Comment(4)

This is actually a Firefox bug, because the SRI matches. No other browser does this. – Replay 30/5, 2018 at 11:57

same is our case seems to be a FF bug, since we are using the integrity code from the CDN provider and it works for almost all the browsers except 1-2 FF browser instanes – Odelia 19/2, 2020 at 6:32

Yes, the question is old, but Firefox has this problem even now. This happen for me every time I simulate slow connections with the network throttling tool (GPRS and Regular 2G) – Mercator 1/5, 2020 at 13:51

I can confirm this behaviour on Firefox v75.0 too. – Culp 3/5, 2020 at 2:53

TL;DR: similar problem on Linux (RHEL 7.3) with Firefox 45.6.0 was solved by downloading 60.0.2 from getfirefox.com.

I'm afraid this is unlikely to solve @Igor's problem, but I had a very similar problem and solved it with a Firefox upgrade; perhaps this will help others.

In my case I was seeing the same

The connection used to fetch this resource was not secure

message in the web console's Network tab not only for Cloudflare but for several other sites:

Chromium, however, was unaffected (as were lynx and curl).

Given the error message for failures, I poked around in Preferences -> Advanced -> Certificates -> View Certificates and was immediately suspicious of all of the expired ones (since 2014!) in the Servers tab, including www.google.com. Attempts to delete them failed, however; they came back immediately after retesting any of the problematic sites in a new tab.

Every suggestion on the Mozilla help pages also failed: no proxy, no anti-virus, safe mode, refresh profile, switch to a brand-new profile (also got bogus 2014 certs, so clearly hard-coded), disable hardware acceleration, disable DNS prefetch, and several other about:config hacks. Reinstalling the existing Firefox version via yum also failed, as did manual deletion of all sqlite files and most of the relevant-looking sites under storage/default (all within $HOME/.mozilla/firefox/<profile>). Even Mozilla's own certutil failed to read the freshly minted cert8.db in the new, clean profile:

$ certutil -L
certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format.

I even tried to reload Firefox's root certificates via the Import option in the Advanced preferences page for 45.x, but the plain-text version I found on Mozilla's Mercurial repo apparently wasn't understood by Firefox's import button. (Or maybe it was; there was zero feedback. But the expired stuff on the Servers tab didn't go away.)

I mention everything that didn't work both because several of those actions did help others who reported similar problems, and also because running through all the possibilities (and several intervening discussions with colleagues) took a huge amount of time.

Ultimately, grabbing the latest Firefox binary via

and unpacking the tarball in a local directory worked fine, and it took all of two minutes to complete and verify. Both old and new profiles work fine with it. And lo and behold, the Servers tab is completely empty of all certificates, expired or not. In my case, I'm pretty sure that was the problem, and my inability to delete the bogus certs was a bug in 45.x.

Glenine answered 7/6, 2018 at 5:29 Comment(0)

This question is very old but if any one facing this problem please check the script attribute integrity

<script src="https://code.jquery.com/jquery-3.1.1.min.js"  integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo"   ></script>

Sulphuryl answered 10/12, 2019 at 6:22 Comment(0)

In case it helps anyone else, my Google Tag Manager script URL gives a few different variations in content, each with a different hash, so it's fairly hopeless trying to give it an integrity attribute.

curl -s 'https://www.googletagmanager.com/gtag/js?id=UA-9715943-1' | openssl dgst -sha256 -binary | openssl base64 -A

Resuscitate answered 8/5, 2023 at 13:6 Comment(0)

Steps to reproduce

My environment:

My question

Recommended topics

Hot tags