SEC_ERROR_UNKNOWN_ISSUER since updating to Firefox 65 due to avast
Categories
(Core :: Security: PSM, defect)
Tracking
()
People
(Reporter: moltres.facesits.justin.coolidge, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0
Steps to reproduce:
Let Firefox Update to 65.0
Open Firefox
Actual results:
Every website I try to visit no matter what website it is always gives "Your connection is not secure" "SEC_ERROR_UNKNOWN_ISSUER"
This happens on three different profiles and two different computers
Expected results:
I should be able to browse the web just like my wife can. My date and time are correct so this error message should not be present
Comment 1•5 years ago
|
||
This is unrelated to the local date and time. It's probably caused by your security software having an "HTTPS scanning" feature enabled, but not having its certificate in Firefox's trust store. The support article recommends reinstalling the software.
Comment 2•5 years ago
|
||
Can you please confirm if you are using an anti virus? Which one is it? (product name and version, SSL scanning enabled?)
Also can you please confirm if doing the following fixes the issue:
1 get to about:config in the URL bar
2 Lookup security.enterprise_roots.enabled and set it to true
3 reload the broken website
Updated•5 years ago
|
Comment 3•5 years ago
|
||
i'm gonna try tagging sumo questions that are likely related to this: https://support.mozilla.org/en-US/questions/firefox?owner=all&tagged=avast65&show=all
Comment 5•5 years ago
•
|
||
Can confirm that there is an issue present in this area.
While trying to reproduce we've come across a scenario that caused the same message to be displayed:
- latest version of Avast installed;
- updated Firefox from 65.0b(8) to 65.0;
- swapped from a Administrator to a normal account.
With the normal account any web-page displayed the "Your connection is not secure" "SEC_ERROR_UNKNOWN_ISSUER" messages until the security.enterprise_roots.enabled pref was set to true.
As a side note the Avast internet security addon was also installed and enabled.
The same STR where followed without encountering this issue for: Kaspsersky19.0.0.1 on Win10(both x32, x64); Eset Internet Security on Win 8.1x64.
Comment 6•5 years ago
|
||
Thanks Cristi
I assume you swap between 2 Windows accounts on the same machine where a single Firefox instance was installed for both accounts? One account is set as admin the other is not but does that mean there are 2 separate Firefox profiles?
Comment 7•5 years ago
|
||
Wanted to double check, but yes 2 separate profiles are generated. None of the profiles from the admin account where displayed in the laucher.
Adding another scenario while we're at it:
- Windows 10x32, with Avast installed;
- Firefox 65.0b(8)installed then updated to 65.0;
- Uninstalled;
- changed to normal account;
- changed back to admin acconut;
- Firefox 65.0b(8)installed then updated to 65.0;
- restarted Firefox.
Trying to access any page brings up the same message instead of content.
Oddly enough, while this is the case on the admin account the other has no issue.
Updated•5 years ago
|
Comment 9•5 years ago
|
||
Could you please validate if the issue also happens on Win7?
Reporter | ||
Comment 13•5 years ago
|
||
(In reply to Romain Testard [:RT] from comment #9)
Could you please validate if the issue also happens on Win7?
The affected machine when I reported this bug is Windows 7 x64
Comment 14•5 years ago
|
||
We DID upgrade sqlite in 65 (bug 1495238) but not during beta. If the AV is using their own copy of sqlite to modify our cert db it's possible they're writing out something we used to accept but now choke on. But if that's the case I would have expected all the profiles to be broken, not just some of them.
We also updated sqlite in 64 (bug 1491671) and again in 66 (bug 1511646).
Comment 15•5 years ago
|
||
Hi Lukas, our users updating to Firefox 65 with Avast & AVG installed have been encountering this error with regularity since we launched on Tuesday. We've temporarily halted all automatic updates on Windows to avoid further exacerbating the issue. Have you gotten reports on your end and if so, do you have any ideas what might be happening from your perspective?
Thanks!
Updated•5 years ago
|
Updated•5 years ago
|
Comment 18•5 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #15)
Hi Lukas, our users updating to Firefox 65 with Avast & AVG installed have been encountering this error with regularity since we launched on Tuesday. We've temporarily halted all automatic updates on Windows to avoid further exacerbating the issue. Have you gotten reports on your end and if so, do you have any ideas what might be happening from your perspective?
Thanks!
Hi Ryan, Firefox HTTPS filtering will be completely disabled by the new virus engine update (eta 2 hours from now) in avast/avg products. We are working on the proper fix. Thnx, David
Comment 19•5 years ago
|
||
(In reply to David Jursa from comment #18)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #15)
Hi Lukas, our users updating to Firefox 65 with Avast & AVG installed have been encountering this error with regularity since we launched on Tuesday. We've temporarily halted all automatic updates on Windows to avoid further exacerbating the issue. Have you gotten reports on your end and if so, do you have any ideas what might be happening from your perspective?
Thanks!
Hi Ryan, Firefox HTTPS filtering will be completely disabled by the new virus engine update (eta 2 hours from now) in avast/avg products. We are working on the proper fix. Thnx, David
Thanks for the update.
Can you please confirm this happened and approximately how long it takes for most users to receive the update?
Updated•5 years ago
|
Comment 20•5 years ago
|
||
The configuration update in both Avast and Avg (all editions) was published as "190201-06" aprox. 18:00 CET. No action from the user is required. No other browsers are affected, only https scanning in Firefox is disabled. The typical interval between virus database update checks is 4hrs.
Comment 22•5 years ago
|
||
(In reply to David Jursa from comment #18)
Hi Ryan, Firefox HTTPS filtering will be completely disabled by the new
virus engine update (eta 2 hours from now) in avast/avg products. We are
working on the proper fix. Thnx, David
Thanks for rolling that change out to your users. Our QA team was able to confirm it helping and the Telemetry data we're seeing on our end also corroborates that. Based on that, we've unthrottled updates on Windows.
Comment 23•5 years ago
|
||
Thank you for the confirmation and cooperation on this issue. I'd like to continue the discussion about the best way how AVs can participate in providing security to the users. Could anyone suggest a better channel than this BUG?
Here are some numbers to consider:
1.8 M blocked sites/day over HTTPS
~660,000 protected users/ day via HTTPS blocking
~550,000 distinct domains blocked/day via HTTPS blocking
(these are numbers just from Avast userbase, other AV vendors would add to the whole picture). My point is that while TLS, in general, is absolutely critical for the security on the Net, in itself it does not stop malware from spreading.
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Updated•5 years ago
|
Comment 26•5 years ago
|
||
My point is that while TLS, in general, is absolutely critical for the security
on the Net, in itself it does not stop malware from spreading.
Nobody is claiming that it does. We have mechanisms to allow for local traffic interception. Historically the intercepting root can be added to our cert database. It looks like your code attempted to do this but for some reason when we examined the cert database in an affected profile the root was added incorrectly (with no trust enabled). Is this something new that just happened to correspond with our update, or something that changed on your end? Our database schema has not changed so we're not sure how that happened if it was working in the past.
More recently we've added a feature on Windows where we check the Windows root store for added intercepting roots. This is off by default because we see it as an enterprise feature that most users don't need, but it would be appropriate in an antivirus case since AV is installed globally on the machine.
Comment 27•5 years ago
|
||
we have Sophos and this problem comes with FF 65.0 so for the meantime we downgraded to FF 60.5.0esr as we are not allowed to disable HTTPS scanning.
the problem happens accessing our Exchange web console internally. from outside, the same URL can be accessed fine. same certs.
Can you send me the files cert9.db and key4.db from an affected profile? (probably best not to post them in this bug since key4.db can contain sensitive information) (I suppose you could create a new profile that doesn't have any of your private keys to be safe)
Comment 29•5 years ago
|
||
Not sure we want to close this bug out pending whatever follow-up actions we want to take still, but the immediate issue was resolved by Avast at least.
I'm not sure there's anything else to be done in this bug - any actions we're taking in Firefox are happening in other bugs (e.g. bug 1529643).
Comment 32•4 years ago
|
||
(In reply to Romain Testard [:RT] from comment #2)
Can you please confirm if you are using an anti virus? Which one is it? (product name and version, SSL scanning enabled?)
Also can you please confirm if doing the following fixes the issue:
1 get to about:config in the URL bar
2 Lookup security.enterprise_roots.enabled and set it to true
3 reload the broken website
Oh yes, scanning was disabled that is why I had this problem. Now the problem is solved. Thank you.
Updated•4 years ago
|
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (spam) |
Updated•2 years ago
|
Updated•2 years ago
|
Description
•