Open Bug 435013 Opened 16 years ago Updated 3 months ago

Cert error "sec_error_reused_issuer_and_serial" (e.g. for Linksys devices) cannot be overridden

Categories

(Core :: Security: PSM, defect, P5)

Product:
Core
Component:
Security: PSM
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox37 --- ?

People

(Reporter: xenoterracide, Unassigned)

References

Details

(Keywords: parity-chrome, parity-ie, Whiteboard: [[psm-cert-duplicates] [no simple solution possible, fundamental NSS design issue])

Attachments

(3 files)

firefox screenshot.
88.11 KB, image/png
Details
Screenshot: Certificate Viewer, "General" tab
82.54 KB, image/png
Details
SSL cert in D-Link DGS-1210-24
692 bytes, text/plain
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008051801 (Gentoo) Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008051801 (Gentoo) Firefox/3.0

Secure Connection Failed
       
An error occurred during a connection to 192.168.0.1.

You have received an invalid certificate.  Please contact the server administrator or email correspondent and give them the following information:

Your certificate contains the same serial number as another certificate issued by the certificate authority.  Please get a new certificate containing a unique serial number.

(Error code: sec_error_reused_issuer_and_serial)

The page you are trying to view can not be shown because the authenticity of the received data could not be verified.

    * Please contact the web site owners to inform them of this problem.

This is my LinkSys WRT54G router that I'm trying to access. The only way to access it is with another Browser (e.g. opera). I wouldn't mind seeing pages like this but I can't find a way to override the setting. I'm certainly not going to go to the trouble of fixng the cert on the router.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
You should be able to add an exception...
Attached image firefox screenshot. — 
I don't see any way of adding one here. I found it for bugs.freedesktop.org (relatively easily). But after poking my nose around on this again I still can't find it.
Ah, I see.  You will probably want to check to see if there's a newer firmware available to fix the problem.

As for the error itself, the reason why an exception cannot be made for it is found in bug 312732.  Also see bug 410622 comment 43 for a possible workaround, though please don't comment in that bug.
Summary: ssl security too strong - no obvious override → sec_error_reused_issuer_and_serial with certs for the LinkSys WRT54G
Version: unspecified → Trunk
*sigh* I'm not even going to argue.
Also see bug 435778
I'm having this problem w/ a WRTg54G v2.0. 

If you can't get to the router, you can't update the firmware!

I checked the Linksys site for the WRT54G and there appear to be no firmware updates later than 4/10/08, which means that they have probably not addressed the problem.

Face it, there are a ton of legacy devices out there - routers, access points, network drives, etc - that generate their own self-signed SSL certs.  There is often no way to force the deveice to regenerate the SSL cert.  No one is going to buy a new device because FF will not work with it.

I'm also a web developer who uses self-signed SSL certs on internal and non-public sites since I do not see the need for verification of resources that I own and implicitly trust.

FF3 is a great product. I do understand the need for security precautions like this, but even the folks at M$FT have designed a workaround for cases like this.  Please do the same.


Maybe Firefox shouldn't warn about "sec_error_reused_issuer_and_serial" at all.  It's screwy that you can get an error due to visiting two web sites, but not by visiting only one.  Does the reuse of serial numbers impact security in any way?
Assignee: nobody → kaie
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm
This is a problem for me too.  I don't think Linksys will be supplying new firmware for the older wifi routers, so please make a workaround available in Firefox 3.
i have to connect to about 15 different wrt54g routers at different sites every day.. and having to close firefox, reopen and delete certificates is such a pain... i really REALLY want to avoid using IE.

a fix would be great
i am using firefox 3.0.3 and even after deleting the certificate of my linksys router from "server certificates" i keep getting this error message, so i can't log in.
even after deleting the certificate, it won't let me add an exception for the (same) router.
the only workaround that i found is to use another browser.
Today I've learned we have bug 460829, which might make your situation slightly worse, but only in the following scneario:

- you had added an override for your router
- the override you added was temporary (not permanent)

In this case, we'd (incorrectly) import the cert for the site to the permanent storage (but without any trust or override action flags).

This means, if you had added a temporary override once, you'd always get this conflict, even after you restart Firefox, even after you go the cert manager and delete your overrides.

In order to clean up completely, you'd have to go to cert manager's "Others" tab (number 5) and delete your matching cert there.
Thanks for posting the info in this topic also, but I am sure that I am dealing with something else:

> In order to clean up completely, you'd have to go to cert manager's "Others"
> tab (number 5) and delete your matching cert there.

If I go to the cert managers 5th tab, then I see nothing, the list is completely empty, so there is nothing to delete.
And I still get the same error message, and am still unable to log into the router.
This bug was opened 8 months ago, last activity was 3 months, and it is still "unconfirmed"?  Add me as one more confirmation.  The bug is real.

I understand why FF throws the error, but whaty I don't understand is why there isn't a way to acknowledge and over-ride it, as can be done with other security exceptions.

Like others in this thread, I have my linksys set up to only allow wired connections and https to get to the admin console on the router.  FF would not even let me view the certificate it said had the duplicate serial number, much less over-ride the error.  I couldn't even look up the solution online because the whole reason I needed to get into admin was to fix my network.  :-/

I'm sorry to say, I had to use IE to get into the control panel to work around this problem.  Now online again, I found this, and many other bugs about this exact topic.  just google for:

   sec_error_reused_issuer_and_serial linksys

And I think you'll be able to at least change this bugs status from "unconfirmed" to something else.  I share the other posters frustration that the firefox devs seem unwilling to add a simple over-ride option for this problem which seems to be effecting lots of people.
Same issue here.  The problem is that:

a) the situation is not fixable on the router end (sucks but that's life)
b) Firefox does not offer any way via the GUI to fix the problem
c) no temporary bypass is provided for cases where the user knows what they are doing (i.e. trying to configure / access their router on their local LAN)

So far the only work around is to exit the browser and then manually delete the certificate db file which is pretty obnoxious.

I would be inclined to suggest that at the very least, this "Firefox developers think you are too stupid to be trusted on your own machine" restriction be loosened for non-routable IPs which appears to the most common case where this problem occurs.

=)

Cheers
Flags: blocking1.9.1?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.1? → blocking1.9.1-
This issue also affects FF 3.0.6 on Windows XP SP 3.  Where is the file I have to delete?  Does deleting this file also remove client certs (PKI) for legit sites?

FF is the only browser I have run across with this issue, and the fact that there is no way out through normal procedures (i.e. the GUI) is inexcusable.  There is no reason why FF 2 should work with these routers and FF 3 does not.

I have never imported this router's cert permanently, knowing it would change.  Now I can't access it through FF.  Thankfully IE still works for this solution.
Go to tools/options/Advanced/Encryption//view certificates and delete you router override in the servers Tab AND in in the Authorities Tab.
If you permanently add an exception (which is the default if you override) you will also import it.

>There is no reason why FF 2 should work with these routers and FF 3 does not.
There is no reason to improve security ? The issue itself is a bug in the device but I agree that this should be easier to fix for a user.
The router's certificate _does not exist_ in _any_ of the tabs.  I cannot delete it.  That is a bug in FF.  How do I remove this certificate without removing my PKI?  How is it that FF is remembering something I never told it to.  Because I know that the device generates its server certs, I always accept them _temporarily_.

As to my comment, I still stand by it.  Your comment does not help, and represents a very sanctimonious attitude.  Here is what should be done any time there is a problem with the certificate:

1) Always -- always -- show the certificate that causes the issue.  How can anyone fix a problem when they don't know what it is?

2) Provide a way out.  If the old stored certificate is the problem, provide a way to delete the old certificate on the error screen.

Finally, put yourself in my shoes.  I paid good money for the router, I know it doesn't do SSL 100% right.  But you are saying I should toss out the equipment and lose functionality.  How am I supposed to know if a new router fixes the problem?  My guess is that even the newer ones have the same exact problem.  It is a bug in FF that you cannot get past the issue--particularly if there is no certificate listed in any tab that belongs to Lynksis (I used IE to look at the cert).  Now what do I do?

FF is broken from my perspective.  Increase security, but don't remove functionality.
>The router's certificate _does not exist_ in _any_ of the tabs.
It must be there or I can't reproduce your issue. Per comment#12 it should be listed under others.

>Your comment does not help, and represents a very sanctimonious attitude. 
Bugzilla is not there to help with issues. For help use http://support.mozilla.com. 
That your paid router is broken is not our problem, don't complain here, complain at linksys and you have the choice with other firmwares with the Wrt54g.
I'm using openwrt with http interface.

final note: I don't decide if this error will be changed to a non fatal error or not. I agree that the situation should be better handled and things should be improved with bug 460829.
Matthias, in my case (Firefox 3.0.6 under Kubuntu) there are no certificates associated with the router under any tab.  The *only* way to fix this problem is to manually track down the certificate db file, delete it and then restart Firefox.  Bug 460829 is obviously related but the certificate does not end up on any tab in preferences which is part of why this bug is so aggravating.
Confirmed (Firefox 3.0.9 / Windows XP SP3).
The router certificate is not under *any* tab and still have this problem.
Exactly the same result, by the way, when you would try to add an exception for it under the Servers tab.
So, I guess it IS a problem of the DB of certificates!
(IE works, but hate it.  http config in router would work, but find it not secure enough)
Also another situation.

Connect to the linksys router with https, ack the exception but don't store it permanently. Reboot the linksys. Now you get an error that you can't connect. 

Restarting Firefox (3.5beta) is required to be able to connect again.
I reported this bug in #6 above.

This bug was fixed as of 3.0.13, maybe earlier - It was working yesterday, when I used FF instead of the usual IE just for giggles.

Then I "upgraded" to 3.5.2.  Now it is broken again, same behavior.

Is the dev team doing any regression testing?

Please fix AGAIN!
I have the same problem with my Linksys Router.

I discovered this behavoir:

1.connect to the router, store the cert
2. make what your want there
3. close your browser and try to reconnect to your router
4. get the "sec_error_reused_issuer_and_serial" error

to fix it:

go into the cert manager from firefox on the servers tab and look for Cisco-Linksys, LCC -> Linksys entry and delete them.
i forget to say, that I can provide the address to my router, that the devs can reproduce it on there browsers

and also I forgot, that the previous described behavior repeat, every time, your close your browser and reconnect again.
My problem was, that the Linksys certificate did not show up on any of the tabs of Certificate Manager.

As a last resort, I deleted the files cert8.db and cert_override.txt form the directory ~/.mozilla/firefox/[user_profile_dir]/ (Under Linux of course. The Windows equivalent should be C:/Documents and Settings/[username]/Application Data/Mozilla/Firefox/Profiles/[user_profile_dir]/ )

This at enabled me (at least temporarily) to connect to the router again and presented me with the well known question wether I want to save the certificate or only use it temporarily.
(In reply to comment #27)
> This at enabled me (at least temporarily) to connect to the router again and
> presented me with the well known question wether I want to save the certificate
> or only use it temporarily.

But then if the router reboot before you restart Firefox, you end up back with the problem. Happened to me, the choice was 1. restart firefox and loose most of the session because I actually didn't have internet access (that's why I wanted to connect to the router) or 2. use another browser to configure the router, which is not always possible.
can somebody change the title to "sec_error_reused_issuer_and_serial with certs from linksys devices", because it is not limited to WRT54G devices, thanks
Summary: sec_error_reused_issuer_and_serial with certs for the LinkSys WRT54G → sec_error_reused_issuer_and_serial with certs for Linksys devices
(In reply to comment #25)
> I have the same problem with my Linksys Router.
> 
> I discovered this behavoir:
> 
> 1.connect to the router, store the cert
> 2. make what your want there
> 3. close your browser and try to reconnect to your router
> 4. get the "sec_error_reused_issuer_and_serial" error
> 
> to fix it:
> 
> go into the cert manager from firefox on the servers tab and look for
> Cisco-Linksys, LCC -> Linksys entry and delete them.
Are you sure that entry is not needed for liknsys website(s)?
anyway, tried it, doesn't work for me, alas :-(
Why not just rename it to "sec_error_reused_issuer_and_serial has no FF workaround". I have this exact same issue with HP iLO, Linksys, as well as my websites that I access from both inside and outside my network. At the moment, I have to do all my work with Opera to get around this.
Summary: sec_error_reused_issuer_and_serial with certs for Linksys devices → Cert error "sec_error_reused_issuer_and_serial" (e.g. for Linksys devices) cannot be overridden
I'm hitting "sec_error_reused_issuer_and_serial" accessing https://www.github.com/ ...

It's not as though Github is an obscure piece of random firmware; what's the workaround?  Can I disable this broken check in about:config by some means?
Bug #410622 appears to be a dup of this.
Bug #312732 is mostly discussing lack of a workaround for this too.
Paul:
The check isn't broken, it's a broken webpage.
You can either remove the imported certificate with the Firefox certificate manager or remove the certificate files in the profile.

And bug #410622 is not a dupe, this bug is limited to linksys WRT54G devices with the embedded webserver.
Matthias:  (a) It is not possible to add an exception for github.com because the 'sec_error' modal dialogue is presented beforehand, thereby disabling and greying out the rest of the "Add Exception..." dialogue.  (b) there is _no_ certificate for "github.com" shown in the Certificate manager.  (c) there is _no_ indication given in the modal dialogue of which (non-github.com) certificate the collision might be with.

Ideas for debugging this would be appreciated;  if I could get some idea of /which/ the colliding certificates might are, I can run those through openssl to ensure that they really do have an identical tuple as the key---the frequency with which this bug is being reported on the web and the bug tracker makes me wonder otherwise.
For the absolute avoidance of doubt, "github.com" does _not_ appear to be mentioned in any key management/crypto related profile objects:

(cd ~/.mozilla/firefox/*.default/ ; grep -alr github . ) | grep -v Cache
./formhistory.sqlite
./sessionstore.js
./places.sqlite
./content-prefs.sqlite
./cookies.sqlite
./cookies.sqlite-journal
Apparently Godaddy issued the same serial number twice - at least that's the claim of NSS here.
Eddy: is this (a) the Godaddy root-certificate with a duplicated serial number, or (b) the Github one with a duplicated serial number.

In either case, /what/ certificate is causing the duplicate ("it takes two to tango"...); and what commands or actions do I need to take to find out which certificate is the other half of the identified duplicate?
Eddy: could you provide a little more details about how to continue NSS debugging for the claimed the Godaddy/Github really do have a duplicate serial number?
Assignee: kaie → nobody
Whiteboard: [psm-cert-duplicates]
I see that this is now over two years old and you still can't even be bothered to fix it.  Sure it would be great if all hardware vendors shipped everything with full compliance to standards, but those of us who live in the real world realize that good software will accommodate the sloppy work of others.  So sure have FF scream all it wants to about the invalid certificate but allow your users to use it anyway with the click of a button.
(In reply to comment #41)
> I see that this is now over two years old and you still can't even be bothered
> to fix it.  Sure it would be great if all hardware vendors shipped everything
> with full compliance to standards, but those of us who live in the real world
> realize that good software will accommodate the sloppy work of others.  So sure
> have FF scream all it wants to about the invalid certificate but allow your
> users to use it anyway with the click of a button.

Edit to add seeing in FF 3.6.13 on OS X 10.6.5 while attempting to connect to my Linksys WRT150N router.
IIRC, serial number uniqueness is used for revocation checking and for mitigate collision attacks against certs signed with weak hash functions. 

By far the best solution for users to work around this problem for the home router users is to enable non-HTTPS mode on the router and connect the PC directly to the router over ethernet, when doing router administration. Even if we fix this bug, the whole way SSL is used on (most of) these types of devices looks to be bogus to the extreme (see below). Do not rely on the SSL implementation of these devices for any security benefit unless/until you have positive confirmation from the vendor that they do not have a bogus SSL implementation. A solution (on the vendors' parts) for fixing all this SSL brokenness would fix the serial number reuse issue too. If these cracked devices' certs were properly revoked as they should be, then even if we fixed this bug, how many devices would actually work as users expect?

http://it.slashdot.org/story/10/12/20/1414210/Database-of-Private-SSL-Keys-Published

From http://www.devttys0.com/2010/12/breaking-ssl-on-embedded-devices/:

> Currently LittleBlackBox has over 2,000 unique
> private SSL keys and growing, primarily
> belonging to routers and VPNs. Although at the
> moment the vast majority of the keys belong to
> various DD-WRT firmware, there are keys from
> Cisco, Linksys, D-Link and Netgear as well.
> By far the best solution for users to work around this problem for the home
> router users is to enable non-HTTPS mode on the router and connect the PC
> directly to the router over ethernet, when doing router administration.

While there is no argument that a determined attacker has a good chance of compromising your SSL session, having no security at all is a pretty poor alternative.  At the very least having SSL enabled on the router will stop trivial packet sniffing of plain text HTTP connections which is likely enough to stop one's network qualifying as low hanging fruit.
(In reply to comment #44)
> > By far the best solution for users to work around this problem for the home
> > router users is to enable non-HTTPS mode on the router and connect the PC
> > directly to the router over ethernet, when doing router administration.
> 
> While there is no argument that a determined attacker has a good chance of
> compromising your SSL session, having no security at all is a pretty poor
> alternative.  At the very least having SSL enabled on the router will stop
> trivial packet sniffing of plain text HTTP connections which is likely enough
> to stop one's network qualifying as low hanging fruit.

If you do what I suggest (directly connecting the PC to the router), you will have a better level of security as there is no physical way for anybody to sniff the traffic between the router and the PC, as long as the router functions as a switch and not a hub.
This is a **very real bug** and at the same time a very real **security** issue, since it prevents you from accessing your router to setup your network security!! - not nice!!

So far the only solution is to NOT USE FF!!  You have to use IE, Chrome, Safari or Opera...
Voting for this one.  I have a self-signed certificate I use on my application server that raises a Firefox warning for "sec_error_ca_cert_invalid".  Unlike some SSL certificate problems, however, the dialog has no "Proceed anyway" option.  Both IE and Chrome allow me to "Proceed anyway" because I know the certificate is a self-signed POS.  Using Firefox 5 here.

I would like an about:config option that allows me to make the "Proceed anyway" button -always- available when an SSL certificate warning is displayed.
This is still an issue for FireFox 5.

It constantly prevents access to HP ILO servers.
The bug also interferes with connecting to my HP OfficeJet L7580.
(In reply to Brian Smith (:bsmith) from comment #45)
> (In reply to comment #44)
> > > By far the best solution for users to work around this problem for the home
> > > router users is to enable non-HTTPS mode on the router and connect the PC
> > > directly to the router over ethernet, when doing router administration.
> > 
> > While there is no argument that a determined attacker has a good chance of
> > compromising your SSL session, having no security at all is a pretty poor
> > alternative.  At the very least having SSL enabled on the router will stop
> > trivial packet sniffing of plain text HTTP connections which is likely enough
> > to stop one's network qualifying as low hanging fruit.
> 
> If you do what I suggest (directly connecting the PC to the router), you
> will have a better level of security as there is no physical way for anybody
> to sniff the traffic between the router and the PC, as long as the router
> functions as a switch and not a hub.

This is often not practical or even possible in some business environments, where there are switches and access points throughout the buildings or accro\ss town.  Your point about bogus SSL implementation may be correct but I don't believe that it excuses a browser from not letting a user do what they need to do.  It should be the user of the tool and not the tool itself that makes any final decision concerning security.  (We're not talking chainsaws here, ha!) The warnings and the extra required steps to bypass any potentially negative experiences are a great help and very much appreciated.  I believe that should be the proper, considerate and well mannered response from any browser.  All the other browsers allow a workaround. Why can't Firefox?
There REALLY should be (native) a workaround! 

Meanwhile, you can use a add-on like "MiTM Me (Cert Error Bypass)" by andras.tim. It works for me. See: http://andras-tim.github.com/mitm-me/
Running Firefox 6.0 on Mac, I ran into this issue accessing my "HP Officejet pro 8500 A910" AIO print/fax/scan device. 

Problem is that for certain configuration options the page redirects from http:// to https:// ! However due to this bug I can't access those configuration options.

There has to be a way to override this error message.
This is the screenshot of the certificate viewer when accessing HP Officejet Pro 8500 A910 for the first time after
- I closed FF6
- deleted "cert8.db" and
- restarted FF6

The second time I access the AOI printer/fax device  (e.g. by reloading the page), I get the error code: "sec_error_reused_issuer_and_serial" page.

In the first place, I don't know why Firefox does not tell me that "This Connection is Untrusted" and asks me to "add exception". Instead, Firefox accepts this HTTPS connection although the site's identity can't be verified..
Still the same problem with FF8 and the new DELL iDRACs...
(In reply to Brian Smith (:bsmith) from comment #45)
> If you do what I suggest (directly connecting the PC to the router), you
> will have a better level of security as there is no physical way for anybody
> to sniff the traffic between the router and the PC, as long as the router
> functions as a switch and not a hub.

You can't be sure the router's switching backplane is immune to arp spoofing.
Please provide a way to override this security "feature". It's really annoying if you have to work with certain hardware. Thanks.
It is also an issue if you want to manage serveral netapps. These have all the serial number "0" in the certificate :(
How about a simple "override" option for users using hardware with same serials. The scenario of getting hardware vendors to update their certs doesn't match whats going on with the backbones that run the Internet.   This flaw has been around for months yet we just ignore it.  I dont care if the page is big flashing red dont do this, as long as I can continue working.
Or even an option in about:config to enable the override warning. It is really sad that one needs to use different browser for administrating those boxes.
Is this bug already addressed by bug #404486?
This bug relates to a serious (blocker) issue where users are displayed an error related to a certificate serial number and can not view the content of the desired website.

In contrast, bug #404486 appears to be a UI issue in an old beta where the message "The certificate is not trusted because it is self signed" is displayed and no option to add an exception is present when certain settings are configured.
Firefox 12.0 on Fedora 16:
This bug just got more annoying - I used to delete the exception and the cert authority of my D-Link DNS-320 NAS whenever I got the sec_error_reused... (which was every time I restarted the NAS!) and go through the process of adding the security exception again. However, I can't do this anymore; when I open the "add exception" dialog, I have to click "Get certificate" button to review the cert before confirming the exception - but now there is a message "Attempting to identify the site..." which just hangs forever. As the button to add the exception stays grayed-out, I'm locked out of my device. The workaround is to use the IP address intead of the hostname of the NAS - in spite of the hostname resolving instantly using "host", "dig" or "nslookup" and being present in /etc/hosts.
Whiteboard: [psm-cert-duplicates] → [psm-cert-duplicates] [no simple solution possible, fundamental NSS design issue]
Voting for this as well. I can't get into Dell iDRAC management interfaces with Firefox because of this bug. I have to use Safari instead.

This "Mozilla knows best! YOU CAN'T DO THIS" attitude needs to stop. Another example is not being able to override autofill=no -- Stop being like Apple and forcing things on users, especially highly technical users who make up a large percentage of Firefox' user base.
Sorry but this is not going to change. It hasn't changed in 4 years and won't change in another 4 years. Firefox developers believe they know best and that the users are idiots that must be protected against their own stupidity. When ever other browser has developed clear and easy error messages Firefox implements confusing and convoluted messages because "making the error hard to bypass is a security feature"

Try a better browser like Google Chrome, Microsoft Internet Explorer, etc to resolve this issue.
[Please don't put words in other people's mouths and stay technical. This is not a discussion forum about general disagreement with developers' decisions but a bugtracker. Thanks.]

As written by Kai here before: "no simple solution possible, fundamental NSS design issue". Everybody is welcome to volunteer to work on a proper solution.
Oh, gimme a break! This issue has been ignored in every sense by Mozilla for 4 years, 'cause it does not fit their narrow little picture of "security, our way or the highway", and you're woundering that after said 4 words someone dares to speak non-asskissing words?! This is not a "fundamental NSS design issue", it's a political issue, Firefox is ACTIVLY refusing to let people access their network equipment.

Nerds might be inclined to agree that "some people have to be forced to do the right thing as defined by us", in the real world, it's not gonna work this way, this issue is the reason Firefox has been removed from >10'0000 Desktops at a large multinational carrier - no fuss, done, IE and every other browser BESIDE Firefox let's us access all pages, even one's that don't meet the security criteria of the Supreme Mozilla Security Council.

As Andreas wrote, this is something i expect from Apple, not from Mozilla. Fu****g with the technicians that NEED to access stuff like iLO, iDARC and other, NO MATTER IF MOZILLA HAS GOTTEN TO THE REALLITY OF PRE-INSTALLED CERTIFICATES, is about the dumbest thing you can do, said technicians where the one that -somethimes with a lot of personal entusiasm- introduced Firefox to the company's. Now, it was decided by NON-TECHNICIANS that it's gone again, and SAFARI from the leader in user-restrictions, is a viable alternative.
(In reply to Andre Klapper from comment #65)
> [Please don't put words in other people's mouths and stay technical. This is
> not a discussion forum about general disagreement with developers' decisions
> but a bugtracker. Thanks.]
> 
> As written by Kai here before: "no simple solution possible, fundamental NSS
> design issue". Everybody is welcome to volunteer to work on a proper
> solution.

Andre (and Kai), didn't it used to work fine? I never had a problem accessing my routers before.  That means someone had to have changed the code to make it not work.  Now I have to use either Chrome or IE.  Since this programmed change, done by one or more volunteers, I've now started to use Chrome instead of Firefox.

It only seems fair that whoever broke it should fix it!  Or do you think I'm wrong about that?  And why do you think I'm wrong about that...

I think that's why people are getting so upset about it.
Andre in this case please review the bug report from 2008 when this "feature" was implemented and tell me it is not appropriate to put words in other people's mouths. Take a look at the self signed certificate situation and you will see it is the same deal there as well.

The Firefox developers think the users of their software are fundamentally stupid. The developers believe the user's hand needs to be helped and they should not be given any choice, because they are going to choose the wrong thing, give away all their money to phishing sites and if you tell them a virus is bad they will go and intentionally try to find one.

Here's how it SHOULD be:

The user should be presented with a clear warning. For example look at the eye catching "something is seriously wrong here" messages in Google Chrome.

The user should then be prompted in the most simple manner for how to proceed. "Yes continue to the unsafe site" or "Protect me and take me out of here" 

These options presented on the same screen and outcome determined by a SINGLE click. This is how the entire browser industry is doing the SSL warnings these days. EXCEPT FOR FIREFOX. 

Firefox believes that since their users are idiots, they will see the red warning screen alerting them that something is wrong and informing them that "no legitimate site" will have self-signed SSL. Firefox developers believe that the user will read the warning and fully understand it, but then "instinctively click" on the continue button and loose all their life savings by giving some Chinese botnet their bank account number.
blocking-kilimanjaro: --- → ?
Flags: blocking1.9.1-
Kai,

In an earlier post you mention:
Kai Engert (:kaie) 2012-05-07 10:57:44 PDT
CC: rrelyea@redhat.com
Whiteboard: [psm-cert-duplicates] → [psm-cert-duplicates] [no simple solution possible, fundamental NSS design issue]

Do you remember which version of NSS this was changed in? I'm assuming from the dates on theses posts that it started with NSS Version 3.12.  So I'm gussing that the "fundamental NSS design issue" was "designed" for version 3.12.  We're still in version 3.12.4.

Is there some way to branch off of 3.11 and try to re-incorporate the 3.12 updates but allowing user intervention?  I think you'll end up losing important user base if someone doesn't do something.

I'm currently using Firefox 3.6.28.  I will not upgrade until this is resolved.  And since 3.6.28 is getting a little long in the tooth, I've started using Chrome and even IE instead...
Jeff it that were to happen the developers would say "a fundamental security flaw would be reintroduced. This is a bug in the router that needs to be fixed by the router." Or to put it more bluntly: THIS IS NEVER GETTING FIXED. NO WAY NO HOW.
(In reply to moron from comment #15)
> Same issue here.  The problem is that:
> 
> a) the situation is not fixable on the router end (sucks but that's life)
> b) Firefox does not offer any way via the GUI to fix the problem
> c) no temporary bypass is provided for cases where the user knows what they
> are doing (i.e. trying to configure / access their router on their local LAN)
> 
> So far the only work around is to exit the browser and then manually delete
> the certificate db file which is pretty obnoxious.
> 
> I would be inclined to suggest that at the very least, this "Firefox
> developers think you are too stupid to be trusted on your own machine"
> restriction be loosened for non-routable IPs which appears to the most
> common case where this problem occurs.
> 
> =)
> 
> Cheers

The only real work around is to use Chrome, IE, Safari or some other browser.  Anything but Firefox works fine.
This is more than a Router issue.  It applies to any secured hardware device like Printers or older NAS hardware.  And it applies to website developers who have self-signed certs on their test servers.

Like I said Firefox will eventually lose a lot of their more technical user base.  It will probably turn into just another IE alternative instead of being the browser of choice for all techies like it used to be.  IE has already passed it as a more technically inclined browser.  I never thought I'd see the day...
(In reply to Andreas van dem Helge from comment #70)
> Jeff it that were to happen the developers would say "a fundamental security
> flaw would be reintroduced. This is a bug in the router that needs to be
> fixed by the router." Or to put it more bluntly: THIS IS NEVER GETTING
> FIXED. NO WAY NO HOW.

Good luck in getting the router fixed. For so many reasons.
Some devices like HP iLO default to or require HTTPS and have these self signed certificates. Over a VPN or local LAN SSL isn't really required but it's there and sometimes forced.

Internet Explorer F12 developer tools is really nice... meanwhile Firefox makes view source buried 4 levels of menus deep. But it's cute the submenu is called "Web Developer." 



But seriously back on topic: How can we know there isn't some undue influence upon Firefox for this "valid" SSL? What if e.g. Verisign or some other entity that stands something to gain for it has contributed money to Mozilla for this attitude to exist?
Expect nothing when you pay nothing.

Since it is *OBVIOUS* that the Mozilla developer community chooses to ignore this problem, and the problem is causing real and continuing issues for us techies, why don't we quit complaining and go somewhere else.  Our flaming can be put to much better use elsewhere.  Let 'em fade into irrelevance, since they are trying so hard.
There is at least a workaround for this.

Remove the CA from the list of certification authorities.
And if you have many "problemdevices" and know what you are doing, install the "MitM Me" extension.
I don't believe MitM Me solves this particular bug. The bug it does solve.... well it's still less clicks to view the same page in Apple Safari, Opera, Google Chrome and Microsoft Internet Explorer... and those out of the box, without any changed settings or added plugins as is required in Firefox.

I have already ensured to disable automatic Firefox on all my machines. I don't want to be counted in download statistics, and I don't want to wake up to any surprise "new enhanced security features"
According to  http://www.tolaris.com/2010/07/16/firefox-extension-new-mitm-me/
the extension exactly solves the issues this bug report aims at.
Quote:"These devices usually have self-signed certificates ... This wasn’t a problem when all I had to do was bypass one error dialog. But then Firefox replaced this dialog with an extremely annoying 5-step dance. I’m tired of it."
Daniel actually that is not correct. Because this bug relates to the error message "sec_error_reused_issuer_and_serial" displayed WITHOUT any option to bypass the error and "add exception."

The issue that MitM Me extension resolves is that some webpages use an SSL certificate that was not purchased from one of Mozilla's approved vendors. When that happens WITHOUT a "sec_error_reused_issuer_and_serial" error the user is required to make about 6 clicks of the mouse to bypass the error (whereas every other browser requires 1 click in this instance.) However, when the user installs the MitM Me extension the 5 click process is reduced to 2 clicks. The MitM Me extension does not add any new options or create any additional elements in the user interface. Therefore, if the user has not been granted the option to "add exception" when viewing a page with an "SSL error" then the MitM Me extension will not help to solve the problem.
Sorry for that. Your explanation is very much welcome. Thanks for clarifying this.
I've honestly given up and moved on to Chrome. But I would like to encourage everyone to vote for a fix to this issue (top of the page). It might make a difference.
(In reply to Andreas van dem Helge from comment #79)

The MitM Me extension helps, if you first remove the CA. So for example, remove the DELL CA. So you explicitly don't trust it.
What happens if you use Chrome on Linux?
I suspect that will give you the same bug, because Chrome on Linux uses the NSS library, too.
(In reply to jeff from comment #69)
> Do you remember which version of NSS this was changed in? I'm assuming from
> the dates on theses posts that it started with NSS Version 3.12.  So I'm
> gussing that the "fundamental NSS design issue" was "designed" for version
> 3.12.  We're still in version 3.12.4.

I'd say it's likely to have been in place least since 3.11.x, because NSS 3.12 was released in 2009, and this bug got filed in 2008.

I don't think it's a new behaviour introduced in some recent version.
I found that this behaviour was deliberately introduced in bug 172247.
George: If you remove the CA then the site will work without the MitM Extension as well. So I think "MitM" isn't too relevant or helpful in this case.

Kai: I can test it out. Do you have an example to reproduce the reused error on a virgin browser?

Does anyone have reference to the "meeting" where this bug was introduced?

Nelson Bolyard (seldom reads bugmail) 2002-10-02 18:20:04 PDT

In today's meeting, we agreed that this bug should be P1 for NSS 3.7.
(In reply to Kai Engert (:kaie) from comment #83)
> What happens if you use Chrome on Linux?
> I suspect that will give you the same bug, because Chrome on Linux uses the
> NSS library, too.

Chrome on Linux pops up a red menacing page saying something like "Click here to run away" and "Click here to proceed with full consent and knowledge that this site may bugger up your computer". I can get into my iLO & DRAC interfaces and all my routers with maybe an extra click. In short, I can actually get my work done with Chrome.
(In reply to Bobbie from comment #87)
> (In reply to Kai Engert (:kaie) from comment #83)
> > What happens if you use Chrome on Linux?
> > I suspect that will give you the same bug, because Chrome on Linux uses the
> > NSS library, too.
> 
> Chrome on Linux pops up a red menacing page saying something like "Click
> here to run away" and "Click here to proceed with full consent and knowledge
> that this site may bugger up your computer". I can get into my iLO & DRAC
> interfaces and all my routers with maybe an extra click. In short, I can
> actually get my work done with Chrome.

That sounds like there's hope!  The issue may not actually be internal to the NSS Library.
Either that or Chrome maybe had to find some long drawn out work-around...
I just setup a test case on my server.

https://kuix.de:8446 and https://kuix.de:8447
use such conflicting certificates.

If I use Chromium on Linux to connect to the first link, then click proceed anyway, then attempt to visit the second link, I get an "unknwon error" (and the console prints out NSS error code -8054, which is the numeric code for reused_issuer_and_serial.

After a browser restart it is possible to use Chromium with the second link. The reason is that Chromium doesn't permanently import the certificate when you say "proceed anyway".

If you use Firefox, connect to the first site, and when you add the override, make sure you DISABLE the checkbox that says "permanently store", then you'll get the same behaviour - after a restart you can visit the second link (without having to delete a certificate in cert manager).

In case you don't want to go through the multi-click excercise to create a temporary workaround, you could use my "SSL Hazard Extension" from http://kuix.de/sslhazard/sslhazard.php
It will give you a skull in the addon bar. If you double click the skull, it will create a temporary exception and reload the page. After a browser restart, you should be able to connect to a different router (or the second link from the test links above).
(In reply to jeff from comment #88)
> That sounds like there's hope!  The issue may not actually be internal to
> the NSS Library.

No, according to my testing (comment 90) Chromium on Linux has the same issue.

If you always use "temporary" overrides for you routers in Firefox, and restart Firefox when you get the error, you should be able to connect after the restart.

Combined with the skull-addon described in comment 90, that should give you a workaround for those routers.

Unfortunately I don't have a better solution.

Another idea that came to mind, you could run "stunnel" locally on your machine. Setup stunnel to connect to the SSL port of the router. In Firefox, use http://localhost:<local-stunnel-port>
Bug 99422 has additional background about the risks and decisions
Based on Bug 99422 can we reach a compromise to implement temporary exceptions and a more intuitive/user-friendly interface for the same when the SSL certificate encountered is issued by an entity that is not affiliated with Mozilla?
(In reply to Andreas van dem Helge from comment #74)
> Some devices like HP iLO default to or require HTTPS and have these self
> signed certificates. Over a VPN or local LAN SSL isn't really required but
> it's there and sometimes forced.

Let's use bug 385471 to track the specific case of the HP iLO. Please see bug 385471 comment 7 for more information, workarounds, and a request for information from end-users affected by this problem for that product.

It seems to me that it is VERY EASY for the server-side products that generate these certificates to more-or-less fix the problem in updated firmware with very little effort. Even simply randomizing the serial numbers in the certs, they would nearly completely eliminate the problem, AFAICT. In fact, it is worth making sure that the affected server-side hardware has up-to-date firmware, because some vendors might have already fixed it on their end already.

Also, in many cases (e.g. the HP iLOM), the users can work around the problem by reconfiguring the server, in a pretty straightforward way (as far as certificate configuration in general goes).

So far, here is a list of affected devices:

  HP OfficeJet L7580 (and other devices)
  Linksys WRT54g
  DELL iDRACs
  Some NetApp devices
  HP iLO / iLOM2

Are all of these errors caused by self-signed certificates with no intermediates? If so, perhaps it would not be too much work to modify NSS to allow it to parse and return temporary (not permanent) self-signed certificates, without the isCA bit set, with duplicate serial numbers. It would be a very high-risk change, though.
blocking-kilimanjaro: ? → ---
Depends on: 733232
OS: Linux → All
Hardware: x86 → All
See Also: → 99422
(In reply to Andreas van dem Helge from comment #86)
> George: If you remove the CA then the site will work without the MitM
> Extension as well. So I think "MitM" isn't too relevant or helpful in this
> case.

You're right. I think the extension in this case only helps, that the invalid cert will not get stored permanently. If you click it manually, you have the choice to add it manually.
(In reply to Brian Smith (:bsmith) from comment #94)

> It seems to me that it is VERY EASY for the server-side products that
> generate these certificates to more-or-less fix the problem in updated
> firmware with very little effort. Even simply randomizing the serial numbers
> in the certs, they would nearly completely eliminate the problem, AFAICT. In
> fact, it is worth making sure that the affected server-side hardware has
> up-to-date firmware, because some vendors might have already fixed it on
> their end already.


Please join us in the real world, where it is much easier to fix Firefox to add a "Add security exception" to this error, that it would be to get 57 different hardware vendors to all fix their not-quite-compliant firmware implementations.

Firefox needs to stop trying to hard to protect users from themselves. It's insulting. At the very least there should be an about:config tweak to fix this for those of us who know what we are doing.
It seems firefox blocks access to the second and subsequent sites that are using duplicate serial numbers, but not the first. If this is implement for "security" then should not every site, including the first seen, with the duplicate serial numbers be blocked from access. That is, if a site has a "compromise" certificate and firefox sees both of them it should not allow access to any site using the "compromised" certificate?
If you use Eset Smart Security, uninstall it (eset uinstaller http://kb.eset.com/esetkb/index?page=content&id=SOLN2289&viewlocale=en_US&actp=LIST) and install the program again.
After reinstalling DO NOT SWITCH ON "encrypted pages to scan SSL / HTTPS"
For me the problem no longer occurs.
"No obligation. "Open Source" is not the same as "the developers must do my bidding." Everyone here wants to help, but no one else has any obligation to fix the bugs you want fixed. Therefore, you should not act as if you expect someone to fix a bug by a particular date or release. Aggressive or repeated demands will not be received well and will almost certainly diminish the impact and interest in your suggestions."
(from https://bugzilla.mozilla.org/page.cgi?id=etiquette.html )

Please keep that in mind when commenting. Plus every comment creates bugmail.
Andre,

So if I create a patch that will correct this issue and unblock the sites currently blocked for viewing in Firefox it will be included?

I hate to sound as such a pessimist, but I seriously highly doubt any fix for this issue will be included even if someone put forth the effort to resolve it.
At least I would highly appreciate such efforts :)
I guess it might have chances to be included if you patch might be enalbed via about:config.
For a simple (nontechie) user, would someone provide in plain English an explanation why this problem exists four years after the first bug report?  I'm not trying to be cute here.  I just can't understand the process.  Midori does not have this problem; Firefox does.  Can't Firefox just adopt Midori's approach?
(In reply to John Deal from comment #105)
> For a simple (nontechie) user, would someone provide in plain English an
> explanation why this problem exists four years after the first bug report? 

Because nobody has donated sufficient money to pay engineers to rewrite the software and make this problem go away.
I prefer using Firefox for several applications since it can be significatly faster.  I ran into this problem with using Firefox for remote control sessions to a blade in a HP bladecenter.  Both the blade center and the remote control session use the same certificate.  I was able to get around it by turning off validation.  It still prompts intially that it's an untrusted certificate, but stops complaining after you add the exception.

Go to Options, Advanced, Encryption, Validation, then remove the check for "Use the Online Certificate Status Protocol...".
Kai. I am going to have to respectfully disagree. Chrome uses the same engine and avoids this bug by not forcing the user to click 12 times and create a permanent exception for the certificate. Instead when a Chrome user encounters a self-signed certificate they are presented with a clear screen as to why the certificate is not accepted by default and they are allowed to accept it temporarily with a single click. In this instance Chrome technically is susceptible to this bug the simple work-around it to exit and re-launch the browser. We can argue all day long on the merits of this behvaiour, but at the end of the day Firefox's implementation is designed with the thought that the user needs protection from themselves. As you can see the current Firefox implementation causes issues with certain systems and further leads users such as JNetz to configure the browser in far more harmful ways than the perceived harm the current system was implemented to combat.
If you indeed cannot see the problem reported in this bug in the Chrome browser on Linux, then it might be because Chrome uses a different approach for implementing the user interface.

Just dumping some thoughts and facts... Technical implementation details...

One problem is caused by the following facts and interdepencencies:
- Mozilla's user interface is implemented using JavaScript
- JavaScript uses lazy allocation and lazy cleanup
- the user interface uses variables that keep strong pointers to the underlying
  NSS C data structures

Even after the user hast stopped using the first site, and starts visiting the second site, the JavaScript engine might still reference the old objects - which still has a strong reference to the old conflicting certificate.

So, after Chrome navigates to a different page, Chrome is probably able to do a full cleanup of the resources that were related to different pages. This means that NSS can immediately forget the certificate that was related to the previous page. And that is probably why you don't run into that conflicting scenario with Chrome.

Here is an idea on how to solve the problem in Mozilla

The nsNSSCertificate/nsIX509Certificate C++ implementation could be changed to not hold a strong reference to CERTCertificate*. Instead, it could memorize key attributes, which can be used to retrieve the certificate whenever needed, and releasing certificate references immediately after each operation.
I also often get this bug when working with HP iLO and Dell iDRAC as they are embedded devices using a SSL cert embedded in their flash ROM. A way to ignore this and continue would let me continue to use firefox instead of having to revert to less desierable software. I dont mind getting the error, it is nice to be told something is amis, but not being able to continue anyway is a breaker, and in my experiance not the mozilla way.
still same issue on idrac's ffx 24.0 osx 10.8. A workaround is to try to find the certificate in the certificate viewer and delete it or to create an exception but I can't find the ip in the list of servers nor can I download the certificate from the IP to make an exception. Works fine in safari though with just a warning.
Standing problem on dell idrac6, I've been battling this for weeks finally gave up and went to IE for the dracs.

Removed cert_override.txt from the profile directory, removed the offending item from the Servers List under View Certificates, restarted, same error. Finally managed to get it to work again by removing cert8.db from the profile directory as well.

The error really if nothing else should report the names of the conflicting certificates that need removed... currently it tells nothing in firefox but the error, which is useful since the TOP google result for 'firefox sec_' is the answer, but not a real solution... especially for a problem that has existed for 6+ years through many iterations of firefox.
This is a total blocker for people using older Network Appliance filers. No, a firmware update is not an option. This _MUST_ have an option to ignore this "error" for legacy hardware. Hundreds of thousands of dollars worth of hardware, and I have to install Chrome just to manage it. Not clever, Mozilla, not smart.

https://bugzilla.mozilla.org/show_bug.cgi?id=973904
"nobody has donated sufficient money to pay engineers to rewrite the software and make this problem go away."

This problem shouldn't have passed technical review and been accepted in the browser in the first place. It is completely unacceptable to block a user from a website unconditionally. Make them wait 10 seconds before accepting the certificate, put a big red bar across the top of the browser, I don't care. But this isn't a "minor problem". It's a huge problem. And it's not the only huge problem that Mozilla has left floating for years, for example:

https://bugzilla.mozilla.org/show_bug.cgi?id=237623
The fact is, there are legitimate situations where a user may encounter a certificate with a duplicate serial number that do NOT involve an attack. In fact, for the vast majority of people who encounter this error, it will be due to dealing with a self-signed certificate or hardware device, and NOT due to an actual attack. 

The real problem is, Firefox default behavior when encountering this situation is irrational, disruptive, and presents a truly awful user experience. 

The error message is cryptic, and provides no real help.
There's no simple way to correct the issue in the user interface
Those who encounter the problem end up having to find the solution by searching the web. 
Even a simple note added to the error message providing a link to a document explaining how to resolve the issue would be better than the brick-wall we have now.
I confirm what is written above: HP iLO automatically creates self-signed certificates all with the same subject and the same serial number.

I think that a very good solution in Firefox would be to provide a tool for quick search of the problematic certificate. As far as I know currently when the error message appears there is no way how to show the subject and serial number of the problematic certificate without using additional tools.
I have this problem constantly, and usually I am getting on an iLO in a critical situation, chrome dosent hard block on this issue.

+1 for allowing this warning to be overridden.
I also have this problem constantly due to a security feature of our network.  This has forced me into using chrome as it doesn't throw this warning.

This warning needs to be overridden and/or exceptions need to be implemented.
got same problem today for the first time with Nightly, also using linksys WRT54GL v1.1, can't add any exceptions
To whom this might concern,

When receiving this error message in respect of certificate handling for my Cisco-Linksys WRT54GS router:

"An error occurred during a connection to 192.168.0.2.

You have received an invalid certificate.  Please contact the server administrator or email correspondent and give them the following information:

Your certificate contains the same serial number as another certificate issued by the certificate authority.  Please get a new certificate containing a unique serial number.

(Error code: sec_error_reused_issuer_and_serial)"

I used to be able to delete the 'offending' certificate from within Firefox and then simply accept the freshly issued one as a direct replacement.  Unfortunately, there is no such certificate showing as available for deletion, ergo I cannot log in to my router via Firefox and have to return to Chrome.  

There is also, as far as I can tell, no way of entering an exception to achieve the same goal either.

Please advise / sort out - certificate control has been a convoluted PITA since I started using Firefox many, MANY aeons ago!  It's just not ergonomic in the way Firefox tends to be.  C'mon guys, you used to lead the way...
Update:

I was able to work around the aforementioned issue by adding the following line to my hosts file located here: 

C:\Windows\System32\drivers\etc\hosts :

192.168.x.y    linksys

where the IP address "192.168.x.y" is replaced by the actual address of YOUR router (it might be of the form "10.0.x.y", etc. and not "192.168.x.y").

You can then enter a security exception in Firefox and request an associated certificate be issued (I do NOT store this certificate as a permanent exception) by typing the following into the relevant field:

https://192.168.0.2/

under:

Options -> Certificates -> View Certificates -> <Add Exception>

and then requesting a certificate be issued and subsequently clicking on <Confirm Security Exception> to store it, deselecting the tick-box concerning permanency if desired.

Hope this helps...
Got the same problem with FortiNet firewall.

One old one and one brand new.

The old one cannot be accessed through firefox after visiting the new one.

I agree with others here, there MUST be a better solution than the current one, especially since it seems no router/firewall vendor adheres to the strict SSL cert principles FireFox demands.

Give us some way to circumvent this warning, anything, it can require editing a file or about:config.

Most of us would be able to handle that and an user that requires the protection would probably not ;)
(In reply to Steve Crane from comment #130)
.... snip ......
> 
> I used to be able to delete the 'offending' certificate from within Firefox
> and then simply accept the freshly issued one as a direct replacement. 
> Unfortunately, there is no such certificate showing as available for
> deletion, ergo I cannot log in to my router via Firefox and have to return
> to Chrome.  
> 
......... snip .............


I think this should be entered as a new bug.  I've never had a problem before finding and deleting the offending certificates in Firefox, and I stopped storing the certificates for my Linksys WRT54GL router as a permanent except a long time ago when I realized that not storing would avoid the duplicate certificate problem.  But now, suddenly, I'm unable to access my Linksys router from Firefox 31 on a Windows 8 machine and a Mac, and I have the same problem in Internet Explorer on the Windows machine.  I can access it from Safari on the Mac, but now I'm afraid to disconnect from the router, for fear that I won't be able to reconnect and will have to hard reset the router and start from scratch.
If you want me to open a new bug I will....

FF 33.0 is reporting "Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number. (Error code: sec_error_reused_issuer_and_serial)" for 2 brand new TP-Link TL-WR841N wireless routers both running OpenWRT BARRIER BREAKER (14.07, r42625).

AND FF does NOT offer me any choices to "override" this as it does other certificate "issues".

Procedure to reproduce:

1. On a brand new TL-WR841N wireless router install the latest OpenWRT (14.07).
2. Configure https (I can supply details if requested)
3. The router will produce the SSL cert at the end of the config change.
4. reboot the router.
5. Using FF access the router at https://192.168.1.1
6. FF questions the self-signed cert and asked if one wants to accept it and record the exception. I accept the exception.
7. Take router #2 and perform the same steps 1-5.
8. FF reports the aforementioned Error code: sec_error_reused_issuer_and_serial and offers no corrective or exception options.

It appears that everyone using contemporary OpenWRT, which is very popular and growing, on any router old or new will now face this awful and NEEDLESS FF problem.

I have to access both of these 2 routers all the time. I cannot continuously delete certs and other insane workarounds. AND I fear that my router count will soon increase making this unbearable.

As so many other people have reported for 9 years, FF needs to offer us a USABLE way to get past this.

We are ALL sick of switching to IE because of FF shortcomings and FF developers refusing to deal with this problem.

Give us an exception handling dialog box like the other exceptions!
Rich Painter: It's apparent to me that this is a bug in openwrt and you have the luck that this can be fixed much easier with openwrt because it's opensource. Did you file a bug at the openwrt bug database ?
btw: I use Openwrt BB on my main router.
You could be right but it still does not obviate the FF need to provide users with an exception dialog to manage the exception. I can report bugs all day to various software developers and if they behave like FF developers, users can never get them resolved. My case in point is how long this FF bug (since ver 3 I think) has been outstanding.

Even if openwrt can fix this (and who knows when) it does not help the many others who have reported this from "other sources".

For the record I will file a bug with openwrt.

FF users STILL NEED AN EXCEPTION HANDLING SOLUTION!
^

I'd like to echo this comment - what this comes down to is that there are a lot of people in enterprise environments who simply can't use Firefox due to this bug. There is a lot of badly-written gear out there that generates identical certificates. While it would be nice if every OEM in the world would pull their heads out and stop doing that, that is not a realistic solution.

What *is* realistic is asking if anyone who knows how the browser works could add a "continue anyway" button to the error page, like the ones that exist for every other class of cert error. That's literally all that's being asked for, here.
Also worth mentioning is that in every case listed on this bug, from what I can see, all LAN devices (routers, firewalls, hardware management interfaces, NAS storage and so on - things that generally aren't touched available over the WAN).

Such a fix could be restricted to the RFC1918 address space and probably resolve most of the concerns here without reducing security for the average user.

..though whether a user should ever be prevented from visiting a website with zero opportunity for override is apparently a larger question :)
I get bogus security errors like this from Firefox on all kinds of legacy network gear, gear that will never be updated until it's replaced, some of which is no longer supported by the vendor but which I have to support. I like Firefox. I prefer to use Firefox. I can't use Firefox on an increasing number of servers and embedded controllers because of this incomprehensible decision not to allow the user to override "quality" tests like this.

Restricting it to RFC1918 space is a nice thought, but not adequate, there are still a lot of networks using public network addresses internally and while renumbering would be the right thing to do it's not something that can be done casually. It would be better to have some kind of "about:config" setting. Maybe make it require familiarity with the Jargon File to make sure that only qualified BOFHs can use it. But do something. The current situation is intolerable.

"For the love of god, Mozilla. For the love of god."
same problem here, its a huge bug, now I need to have a very old and unsecure firefox 32 if i need to access webmin or IDRAC, i dont want an unsecure firefox to access sensitive stuff like IDRAC for managing dedicated servers, ALLOW us to setup an exception for those "default IDRAC certificate" or "default webmin certificate" blocking it like that is MORE unsecure than allowing the user to choose !
Still no one at Mozilla cares about a 6 year old bug. Don't we have a way to escalate that, so that someone who is able to help will see that?
more and more people have to leave firefox everyday 
more or less this 6 year old bug means "**** you sysadmins, go use chromium or konqueror if you want to be secure"
ok i could generate  a different cert for each of my webmin installs, but i cant do that for IDRAC, and the datacenter wont do it
Guys, I know I'm doing the same right now, but for good reason:


Could you please stop that spamming? Mozilla made quite clear, simply by the age of that bug, that it's not going to fix this issue. Neither would this be the only bug/feature request that would be easy to solve, where many users would benefit, but which Mozilla blocks for whichever evil reasons (search for MNG, JPEG2000 or some security bugs e.g. I've reported and you find many of these).

Even if it's absolutely ridiculous that such issue isn't fixed, and while I can understand your grief, ... it just annoys your fellow victims of this issue, if everyone who is fed up with the situation says "here, me too".

Vote for the bug, or switch the browser - the later is actually the only thing which gives pressure on Mozilla, since it's money that rules nowadays.
well fellow victims are possibly happy to see the bug is still active .. . and you could remove yourself from the CC list if you re not interested . . . but ok, anyway i wont post here anymore
Well I didn't say that you weren't allowed to post here anymore...
just that it's useless if people only post "I have this bug too, and it sucks".

And of course I could unsubscribe from it, but that would also mean that I miss it, in case Mozilla should ever get sane again, and actually do something about issues. ;-)
Guys, deleting cert8.db and cert_override.txt from C:\Documents and Settings\<userAccount>\Application Data\Mozilla\Firefox\Profiles\<userProfile>\ or /Users/useraccount/Library/Application Support/Firefox/Profiles/<userProfile> on Mac OS X and it works!
Seems like when you add an exception of a certificate vs ip or domain, and later you change that certificate, firefox doesn't recognize anymore or let you choose. If there at least would be a way to remove these exceptions in the cert manager but there isn't. The only way is to delete those files, which contains all the exceptions. You will lose all of your exceptions though. Someone could come up with an extension that would be able to manage these certs exceptions, since mozilla is not willing to fix this DESIGN BUG.

Don't forget to close the browser before deleting the files.

Not ideal, but works for me.
Simply posting here that you also have the same issue does not have any impact on the priority of this bug, but VOTING for this bug might possibly help. However given that most people who've commented have also already voted for it, the best way to get attention to the issue would be to have more people vote.
true, deleting cert8.db works, but doing that 10 times a day is . . . meh
also deleting it all the time doesnt make you very secure on the internet . . .
What a big D1SGR4CE this has became browser.
What use is a browser to a systems administrator, if he cannot ever change a certificate on a server ?

TOTALLY USELESS

If you work with network administration, support, GIVE UP THIS BROWSER, do like I did.
Or be ready to delete all of you bookmarks, settings and everytyhing everytime you change a certificate in one of your systems.

Do like someone above said, USE ANOTHER BROWSER, becuase F*CK1NG mozilla thiks this bug is not important and wont´t get any fix, because they think ssl certificates should not be reissued, and what if you are a systems of network administrator ? Screw you!! It is your problem!
So now you know mozilla doesn´t give a **** to professional like us, just do your self a favor and don´t waste time like me, coming back to check if they have fixed it, because they won´t.
Apparently mozilla thinks that some router vendors that reissues certificates with same serial numbers, is a **** big security hole that is worth to disable reimport another certificate with another one. Apparently for mozilla, only stupid people and limited users user their browser, yeah I am feeling stupid now, using a browser that does whatever it thinks is best for my security, including getting in the way of getting my job done.

So just use ANOTHER BROWSER which lets you manage your imported certificates FOR REAL.

Mozilla doesn't listen to us anyway, only think they care is market share, so just change browser, like this you will do your part.
status-firefox37: --- → ?
Since upgrade to firefox 37.   It's happened agin.   
Out company  inner site  with slef certy CA , cannot be open . and It's error code is sec_error_ca_cert_invalid
afaik that have never been fixed, just a silly and unsecure workaround:  everytime that happens you have to delete your cert8.db file so that it works until the next time. #sillyfirefox #badforsysadmins
Hehehe, on Bug 1147202 they said this is another bug I mentioned, but hey, that's from 2008 with a "NEW" status :)
This is a really good reason to change my primary browser to something else... so I decided...

Ok, that was just a goodbye message, officially I only confirm that the bug is still here.
firefox 41.0.2
same issue; must switch to chrome sadly.
Firefox 42.0
Same Issue.  There has to be a solution for this.   On two Mac Book Pros , on one first time I accessed my firewall, I added an exception, and I can access the firewall every time.  On the other MBP, same 10.11.1 OS X, Firefox 42.0,  I can not add an exception. It is greyed out.  They are not identical MBP's, but they are both late 2012, same ram, same SDD HD.  THey are physically different machines, but configured identically.

I don't have an option of moving to Chrome.  Safari is like IE.  Chrome is Google. I have reason to not trust Google anything.    What ever happened to "Firefox was created to be the best browser to avoid the flaws of IE"?  Where do I go to avoid the flaws in Firefox?
Firefox 42.0: Firefox does not even show me the certificate so it is not easy to determine if I have a duplicate installed (can this be fixed?!). I deleted one that I thought might be (this is for a DELL CMC for a Blade Chassis) under Servers, but I still had the error after refreshing the page with the F5 key. I then started writing this message and thought, OK, I'll just try a Shift-click on the Refresh button and see if that helps, and the message changed and I could add an exception.
TI have now been working on this for several days.  The Full error is odd, because there is no certificate with the same serial number!!  It appears this error tracks all the way back to Firefox 34!!
I am so happy that I can't get to any of my SSL based home devices.. FIrewalls, WIFI, my CIsco 3064 switch (just to view graphs otherwise I use SSH to configure the switch. (like my son will hack my telnet session and change my CIsco switch configuration. :)  Been using Firefox for so long, and never ran in to this problem.  (on my other Mac running Firefox 42, I get a "No certificate, however you added an exception", and no problem accessing SSL devices.  Sadly, I need a new browser.  How can you trust a browser that has never ending certificate problems??  I can't.  Here is the entire error:


An error occurred during a connection to 192.168.1.1. You have received an invalid certificate. Please contact the server administrator or email correspondent and give them the following information: Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number. (Error code: sec_error_reused_issuer_and_serial)

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
You might try Pale Moon Browser plus Pale Moon Commander add-on. I no longer have Linksys devices on my network so cannot test this.
This affects other firewalls to, like Fortigate and the problem does not seem to go away.

I know FF does this in an effort to increase security but when you constantly have to circumvent the security to do your work you end up with less security than before.

Some way to add multiple exceptions for the same certificate would be help full or an option to override the warning and continue like other browsers offer.
Commenting doesn't do any good, if you have not already voted for it, you need to vote for this bug. 

Unfortunately, it's clear at this point that more effort has been spent arguing about why this is not a problem and explaining why it's too dangerous to fix than it would have actually taken to fix it. Clunky workarounds involving deleting certificates manually are as good as it's ever going to get with Firefox.
Thanks @Bmercer for reminding us of the obvious. I had not voted for the bug. Done, Dusted.

This is hardly any fix, but I installed a new Mozilla from scratch on a VM under Virtualbox.
I than browsed to all my local systems I was getting this error.  On connecting from the new Window3s sytem running on VM to each local IP, I received the warning, and created the exception.

I than went in to Preferences>Advanced, and Exported all the certificates to a share on one of my NAS units.

I proceeded back to the broken Mozilla running on my Mac OS X 10.11.1, and I Imported all the certificates.  I then restarted FF, and connected to each device I was getting the error on, and I received the "This is an untrusted connection, Get me out of here, or would you like to create an exception." YES!!  I created the exception, and finally I could get to my firewalls, and all other local devices.

It certainly is not a fix, but it is easy enough to do for a relatively non-technical user that don't understand certificates, etc.   It worked twice across a MAC running OS X 10.11.1, and a Windows 7 system running FF,  so I am confident it will work for others.  I hope this helps a few following this bug.
It won't be easy selecting another or moving to a new browser, as I have been using FF from the epoch.
(In reply to Mark D from comment #163)

@MarkD Certificates are stored in the Firefox profile so for your workaround you do not need to install a new instance of Firefox and a new operating system just create a new profile:

1. Run: firefox --no-remote --ProfileManager
2. Create a new profile there.
3. Open a new instance of Firefox using the new profile. To run Firefox with the profile you can use the command from 1. or: firefox --no-remote -P profile_name
4. Do the actions there as if it was a separate installation of Firefox.

------
BTW I am not sure why your procedure should help as this bug report describes a situation where Firefox refuses to establish a connection to a site (device) which uses a copy of the same certificate as a different site (trusted by an exception).

------
Another workaround with profiles would be to use a different profile for every site (device) which is presenting a copy of the same certificate.

------
I really do not understand why an educated Firefox user cannot make an exception in such cases. There are many devices which do not allow replacement of their fixed pre-generated certificate.
@Vaclav

I am aware of what the bug is.  Specifically inability to connect to a local site, and the inability to create an exception with an error of (Error code: sec_error_reused_issuer_and_serial)".

Creating a new profile DOES NOT WORK. I already tried that.  Loading a new Mozilla on another OS, or using another OS where you can access the RFC1918 device, exporting that certificate.  Moving the cert back to the Firefox that is reporting the "sec_error_reused_issuer_and_serial", and refuses to connect, refuses to allow an exception to be added, I have resolved the inability to access on a MAC OS X 10.1.11 system and a Windows 7 system.  

Importing the certificate for the RFC1918 device you can not reach, than restarting FF, attempting to connect to the RFC1918 device, you will get the normal "Site Untrusted, Do you want to add an exception" message, and if you say "Yes add the exception", you will be able to now reach the device.

Oh, BTW, the RFC1918 devices I am accessing are NOT presenting a certificate. (including a Zywall USB50 Firewall, A CIsco ASA5005, a Dlink DIR655 WAP", present no certificates, and a Juniper 5GS Firewall that does present a certificate.

So I tested what I stated and it works.  I tested what your listed solution days ago and it does NOT work.  You have many "I am not sure why this bug describes your situation", which clearly implies that you have not read my first post, which specifically noted the "sec_error_reused_issuer_and_serial" error.

You also suggest "another workaround: after your first. Did you test any of your suggestions?  Because I would not have gone through the trouble of loading FF on a completely different system, creating the certificates by Exception, Export all the certificates, etc, etc. as noted in the work-around I recommended if your simpler suggestion of simply creating a new profile had worked.  As an Engineer, It is second nature for me to always perform due-diligence before I post a solution.  It worked on a Mac Book Pro running OSX 10.11.1 and a Windows 7 system that both could not access the same devices.

I hope Mozilla fixes the problem.  But I have a work-around for now that works.  I do hope the process I recommended does work for those with the older devices not presenting certs as it did with mine.  Since I have a work-around, voted on the bug. There is nothing more for me here. I will hence unsubscribe.  Cheers all.
This is absolute freaking insanity, currently I have to choose between working kerberos authentication (Firefox) or the ability to manage network devices (Chrome) due to this goddamn issue. How hard is it to add a command line flag, setting, or something else that puts this in the hands of the person who is using the product? Bury it if you need to, but for the love of all that is holy stop dictating what we can and can't do.
Can't believe this hasn't been fixed; it's been like eight years now that this has been broken.

I moved away from Firefox a few years ago due to issues like this and some of its design choices. It makes me sad that the ship hasn't been steered in a better direction in the years since. :(
Is there any way to clear or bypass this error? I've created my own CA in a test environment and we can rebuild it on command. This resets serial numbers and I can't seem to get past the error message now!
afaik the only way is to manually delete :

rm -f cert8.db cert_override.txt 

everytime . . . and yes its silly and even more unsecure
(In reply to Scott Helme from comment #170)
> Is there any way to clear or bypass this error? I've created my own CA in a
> test environment and we can rebuild it on command. This resets serial
> numbers and I can't seem to get past the error message now!

You can't fight a bug with a bug: Certificate serial numbers should never repeat for a CA, and different certificates should have different serial numbers. Current recommendation is that "serial numbers" should be more like random numbers rather tan being sequential numbers (as openssl implementations prefer).
Would there be any standard which actually forbids that behaviour?
And even if there was, reality is that serial number duplicates occur quite frequently in several areas, so there should be a way to make an exception (except using a browser where upstream also fixes issues that do not just increase market share).
Can we PLEASE stop making the asinine argument that since a standard exists that describes how certificates should work, therefore it must be IMPOSSIBLE to work with any certificates that do not meet the standard? Exceptions exist. Real world. Important. Exceptions.
(In reply to bmercer from comment #174)
> Can we PLEASE stop making the asinine argument that since a standard exists
> that describes how certificates should work, therefore it must be IMPOSSIBLE
> to work with any certificates that do not meet the standard? Exceptions
> exist. Real world. Important. Exceptions.

For a long time now, Mozilla has claimed its products are standards-compliant.  Reversing that position to work-around a discrepancy introduced by another company -- Linksys embedding non-compliant certificates in its routers -- is not acceptable.  

What is needed here is the implementation of an option for the end-user to accept ALL risks of overriding the error.  Such an implementation should not persist beyond each instance of the error.  Thus, users would have to select that option each time they wish to access their Linksys routers.  Allowing the option to persist could too easily introduce a severe security vulnerability.
* its not just linksys, its thousands of brands and datacenter tools like iDRAC, possibly millions of network equipments.
* its not "a discrepancy introduced by another company" its always been like that.
* it just makes firefox mostly useless for sysadmins.
* rm -f cert8.db cert_override.txt is even worst than setting an exception
(In reply to David E. Ross from comment #175)
[...]
> What is needed here is the implementation of an option for the end-user to
> accept ALL risks of overriding the error.  Such an implementation should not
> persist beyond each instance of the error.  (...)

Actually I could imagine a variant: You could define exceptions per URI (instead of globally). Then you could decide whether the exception is per session or persistent.

(It's off-topic, but we had a case where Firefox refused to connect to a weak cipher, and the suggested solution (not by me!) was to GLOBALLY weaken the security requirements in Firefox. With a specific override, I'd feel safer...)
(In reply to Neo Futur from comment #176)
> * its not just linksys, its thousands of brands and datacenter tools like
> iDRAC, possibly millions of network equipments.

Can you prove your claim? Most vendors have fixed their code meanwhile. Or are you running extremely old firmware for remote management? If so, you have a bigger problem that the Firefox one.

> * its not "a discrepancy introduced by another company" its always been like
> that.

Specific mistakes are no invariants. Maybe the problem is that there are too many bad examples around and people copy mistakes without understanding.
(In reply to Ulrich Windl from comment #178)
> Can you prove your claim? Most vendors have fixed their code meanwhile. Or
> are you running extremely old firmware for remote management? If so, you
> have a bigger problem that the Firefox one.

Replace hundreds of thousand dollars worth of rack-mount servers, or switch to Chrome? Not even a tough choice. You should be glad that people have enough affinity for Firefox to even keep pushing for these long standing Firefox bugs to be fixed. These are loyal users *and* they tend to be users who influence software policy at big companies.

Yeh, old firmware isn't ideal, but you should already have the management network locked down anyway.

There's a whole bunch of related bugs where Firefox is being obstinate about dodgy certificates in management firmware that's only a few years old in some cases. It's WAY premature to sit down and defend the purity of Firefox's bodily fluids.

Put it in "about.config" and call it the "horribly.insecure.hugo.award.mode".
9 days from now marks the 8 year anniversary of this ticket being raised.  If you're not going to fix the bug, can you please make a statement saying so, close this ticket, and let people who need the functionality look elsewhere?

We've moved on to Chromium a long time ago since this was raised with their developer tools built in and, you know, actually WORKING when needed. 

I'd strongly recommend anyone else tempted to reply to this thread or attempt reasoning with the Firefox developers to just move on and find a new browser. They have spoken, and they have absolutely zero interest in helping you.
(In reply to Ulrich Windl from comment #178)
> (In reply to Neo Futur from comment #176)
> > * its not just linksys, its thousands of brands and datacenter tools like
> > iDRAC, possibly millions of network equipments.
> 
> Can you prove your claim? Most vendors have fixed their code meanwhile. Or
> are you running extremely old firmware for remote management? If so, you
> have a bigger problem that the Firefox one.

Can you prove *this* claim 'If [you running extremely old firmware for remote management], you have a bigger problem that the Firefox one.'?
Running old firmware for remote management does not cause any problems other than trying to connect with new browsers. Remote management usualy happens over a trusted network, so even using encryption at all should really just be an optional extra for most people. And, in 10+ years, I have never seen a vulnerability posted for Dell (i)DRAC software, with 1 exception to do with IPMI, which can easily be switched off. So really, all this *paranoia* about security is just FUD. As you actually mentionned, it should be possible to set variables in about:config to lower the security on specific sites. This would have been useful for SSLv3 too (which is needed to connect to older Dell DRACs), but it's a bit late for that now I suppose since it has been removed from the code base.
Guys, the fact is:
SysAdmins need to connect to devices that might have duplicated serial
numbers and or invalid certificate chains overtime, this is our job,
is what we do, we set up and test those things.

SysAdmins have a LEGIT use case, BUT, the software provider, mozilla,
is not willing to fix this, at all. They chose the benefits of
restricting your connection over making a browser that can be
used by a network administrator.

So all of you SysAdmins, SWITCH to chromium, or any other browser you
like. because Mozilla, WON'T FIX IT.

Please just close this bug as won't fix.

What a shame.
(In reply to Israel Nogueira Miranda from comment #182)
> So all of you SysAdmins, SWITCH to chromium, or any other browser you
> like. because Mozilla, WON'T FIX IT.

The problem is that the major browsers have this one-upmanship going on, so if they see other browsers doing something that they think is better (e.g. more secure), they'll do the same thing. This seems to be particular true of Firefox where the developers are continually comparing Firefox to Chrome. So switching browsers may only be a short term fix (which is why it should be resisted). Chrome has now got into the sillyness of not working (or getting updates) on Windows XP SP3, and even more silly - not working (or getting updates) on Windows Vista. They claim that Vista is no longer supported by Microsoft in their blog post, but that is patently untrue according to Microsoft, and there are also XP-like O/Ss that are still supported by Microsoft as they were released in 2009 that presumably Chrome won't now run under either. So what I ask you is more secure? Not being able to update your browser because some misinformed company or developer decided you should upgrade your O/S (which may or may not happen), or said company or developer continuing to support your O/S? It's another example of FUD.
(In reply to Ulrich Windl from comment #178)
> (In reply to Neo Futur from comment #176)
> > * its not just linksys, its thousands of brands and datacenter tools like
> > iDRAC, possibly millions of network equipments.
> 
> Can you prove your claim? 
The fact that you think this claim needs to be "proven" shows out completely out of touch you are with real-world system administration. This is general common knowledge, it doesn't need to be proven. 

> 
> > * its not "a discrepancy introduced by another company" its always been like
> > that.
> 
> Specific mistakes are no invariants. Maybe the problem is that there are too
> many bad examples around and people copy mistakes without understanding.
No, it's not a matter of something being copied. It's a matter of an exception being needed for legitimate reasons, and Mozilla refusing to do so for ideological reasons. 

It's not always practical to throw expensive working equipment into the garbage just because of old firmware. Let's not even mention the fact that you can't UPGRADE firmware without first being able to CONNECT to the device in question, which of course is impossible with Firefox. 

The specific reasons why this is a real problem have been described extensively over and over again, and the arguments against it are consistently weak and dumb. 

It is somehow a huge security risk to the entire internet if someone like me accesses an insecure device on my own LAN. 

Having an obscure config setting for this would immediately jeopardize the security of millions. 

Implementing such a setting is a herculean effort, far beyond the capabilities of mere mortals to understand. 

Standards compliance means 100% absolute compliance in every aspect at every second for ever and ever, and zero tolerance for any exceptions is ever permitted, because STANDARDS! Never mind the fact that Firefox doesn't actually support all standards.
(In reply to bmercer from comment #184)
> (In reply to Ulrich Windl from comment #178)
[...]
> > Specific mistakes are no invariants. Maybe the problem is that there are too
> > many bad examples around and people copy mistakes without understanding.
> No, it's not a matter of something being copied. It's a matter of an
> exception being needed for legitimate reasons, and Mozilla refusing to do so
> for ideological reasons. 

I was talking about firmware that uses the same serial number (or even certificates) for different devices. Maybe it all originates from openssl's handling of serial numbers. That's mistake and copying...

> 
> It's not always practical to throw expensive working equipment into the
> garbage just because of old firmware. Let's not even mention the fact that

If the firmware doesn't allow to change the certificate, it's broken from the beginning.

> you can't UPGRADE firmware without first being able to CONNECT to the device
> in question, which of course is impossible with Firefox. 

No SSH/CLI?

> 
> The specific reasons why this is a real problem have been described
> extensively over and over again, and the arguments against it are
> consistently weak and dumb.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=385471#c7

(...irony/sarcasm followed...)
(In reply to Ulrich Windl from comment #185)
> (In reply to bmercer from comment #184)
> > (In reply to Ulrich Windl from comment #178)
> [...]
> > > Specific mistakes are no invariants. Maybe the problem is that there are too
> > > many bad examples around and people copy mistakes without understanding.
> > No, it's not a matter of something being copied. It's a matter of an
> > exception being needed for legitimate reasons, and Mozilla refusing to do so
> > for ideological reasons. 
> 
> I was talking about firmware that uses the same serial number (or even
> certificates) for different devices. Maybe it all originates from openssl's
> handling of serial numbers. That's mistake and copying...

So what? A mistake made long ago still needs to be worked around today. Just because it was wrong doesn't mean you can ignore it.

> > 
> > It's not always practical to throw expensive working equipment into the
> > garbage just because of old firmware. Let's not even mention the fact that
> 
> If the firmware doesn't allow to change the certificate, it's broken from
> the beginning.

I keep seeing this same irrelevant point being raised. 
The firmware is broken? 
Yes. Yes it is. We all know it's broken. Nobody is saying it's desirable or good. 

BUT IT IS REALITY AND WE STILL NEED TO INTERACT WITH IT ANYWAY.

Ignoring this real-world fact is pure arrogance. 


> > you can't UPGRADE firmware without first being able to CONNECT to the device
> > in question, which of course is impossible with Firefox. 
> 
> No SSH/CLI?
No Chrome/IE/Opera/Whatever? We know alternatives exist. 
Deliberately missing the point I was making does you no credit. 

> 
> > 
> > The specific reasons why this is a real problem have been described
> > extensively over and over again, and the arguments against it are
> > consistently weak and dumb.
> 
> See also https://bugzilla.mozilla.org/show_bug.cgi?id=385471#c7
> 
> (...irony/sarcasm followed...)

 There is no real reason for not allowing exceptions in specific cases other than ideology and arrogance.
Here's a possible workaround, for administrators that prefer to use Firefox to connect to your multiple network devices.

It's dangerous. Don't do it unless you understand what's happening, and unless you're able to ensure that nobody will accidentally use such a configuration to remove the usual SSL/TLS security mechanisms.

Use at your own risk:

- on your workstation, 
  install mitmproxy from mitmproxy.org and run it (it will listen on 127.0.0.1:8080)

- create a separate firefox profile:
  firefox -no-remote -CreateProfile mitm

- start your separate firefox instance
  firefox -no-remote -P mitm

- install a theme in that separate firefox profile, so you can easily recognize
  whenever you're using your special firefox profile, e.g.:
  https://addons.mozilla.org/en-US/firefox/addon/dark-adams-danger-zone/

- let's restore the classic status bar, so we can have an status bar icon:
  https://addons.mozilla.org/en-US/firefox/addon/the-addon-bar/

- as your profile will configure a proxy, it might be handy to easily switch between
  proxy enabled and proxy disabled, so this addon might be useful:
  https://addons.mozilla.org/en-US/firefox/addon/quickproxy/
  (this will install a red P in the status bar to quickly enable/disable the proxy.
   It's not required for this solution, but might be useful, if you ever
   need to use this profile to access sites without going through the mitm proxy.)

- configure firefox to use a SSL proxy, go to preferences, advanced, network,
  connection, manual proxy config, and set ssl proxy to 127.0.0.1 and port to 8080.

Now, whenever you run into an issue with your primary firefox instance, and, you understand what you're doing, then start up this secondary firefox profile using
   firefox -no-remote -P mitm
and use it to access your network device. The mitmproxy will dynamically give you a fresh certificate locally created by mitmproxy, and hide the original certificate from the device - which should be a workaround for accessing your devices.

Please be aware that this is a dangerous setup. Don't do this unless you exactly understand what's happening here. You're removing the usual security protections. Every site you visit will require a certificate override, or, you could install the mitmproxy CA in that browser, which is even more dangerous.

Again, use at your own risk.


Please don't respond with comments saying "this is stupid", because, I agree it's stupid that this is necessary. But as said earlier (you have read the technical justifications in this bug, prior to posting, did you?) I don't see a more direct solution in easy reach, because the design principles of NSS make it too difficult.
Whiteboard: [psm-cert-duplicates] [no simple solution possible, fundamental NSS design issue] → [psm-cert-duplicates] [no simple solution possible, fundamental NSS design issue] [dangerous workaround can be found in comment 187]
Kai, I have read the technical justifications in the bug, the simple reality is- this issue does not exist on ANY other browser because in any other browser when I say "I know this is dangerous and retarded, do it anyways" it does... because the user often knows better than the dev of a product how it's being used and NEEDS to be used. 

Every other browser has found acceptable work around except firefox (all of which say, "Hey  man, this is wrecked, are you absolutely sure? This could be a trap!")  

Firefox is in a catch22 here, you can't fix the firmware because the browser won't let you do what needs done.  I've seen this error on dell dracs, ddwrt, several brands of firewall, and various pieces of older hardware I've had to interact with in the field. This is NOT a trivial problem, it has more or less ended firefox usage at most of my work places because it's absurd and no other browser has ANY issue bypassing it after a warning. 

I've been following this bug since the first time I found this post searching for a workaround nearly a decade ago.  The fact it's still outstanding is both stupid and absurd.  The fact unlike every other browser under the sun I can't say "I know, proceed anyways" so I can fix the base problem on the network hardware is the problem.  

A simple about.config option to allow override is all that is needed.  We're well aware that a broken firmware causes the problem with the certificate not firefox, however... how firefox deals with it is the real problem here.  There is no override... there is no way to say "It's cool, I know what I'm doing in this case and this is necessary, so I can actually FIX the real problem."

The solution you posted isn't a solution at all.  It's hubris to assume firefox does anything so much better than chrome, internet explorer, or opera that it warrants going to those lengths.  It doesn't.  Most admins have long ago switched to another browser rather than deal with this issue constantly.  It's pretty sad really. ~posted from chrome by an ex-firefox user.
For what its worth, comment #171 is the only work around anyone needs.  It's dangerous and insecure and the only solution fast enough to make it worth doing rather than just changing browsers.

rm -f cert8.db cert_override.txt (or equivalent simple batch file running as admin in windows)

If this problem existed only for ddwrt, you wouldn't see this degree of annoyance and outrage, but it exists for dozens of vendors and millions of devices sysadmins interact with daily, most notably for myself was the older (customer owned) dell drac.
PLEASE, stop adding more rants to this bug.

This doesn't help anyone.
Whiteboard: [psm-cert-duplicates] [no simple solution possible, fundamental NSS design issue] [dangerous workaround can be found in comment 187] → [psm-cert-duplicates] [no simple solution possible, fundamental NSS design issue]
Possibly dumb question:

Why is this bug still open if the developers have no intention of fixing it after almost a decade?
(In reply to Michael Parks from comment #191)
> 
> Why is this bug still open if the developers have no intention of fixing it
> after almost a decade?

It's not about intention, but about capability.

The issue is real, and it would be good to fix it, but at this time, we don't have a solution.

We can't fix it easily, because of technical constraints and lack of resources to rewrite the underlying NSS library in a way to work around the technical constraints.

Hopefully one day someone will be able to provide a technical solution.
(In reply to Kai Engert (:kaie) from comment #192)
> (In reply to Michael Parks from comment #191)
> > 
> > Why is this bug still open if the developers have no intention of fixing it
> > after almost a decade?
> 
> It's not about intention, but about capability.
> 
> The issue is real, and it would be good to fix it, but at this time, we
> don't have a solution.
> 
> We can't fix it easily, because of technical constraints and lack of
> resources to rewrite the underlying NSS library in a way to work around the
> technical constraints.
> 
> Hopefully one day someone will be able to provide a technical solution.

Maybe we should start by filing a bug/whatever for the NSS library? No-one who works on NSS is likely to do anything without such a bug being filed I guess... I'll leave that to someone who understands the issue or NSS better though.
Gotcha. Okay.

As I understand it, and from the discussion on #312732 which is the underlying issue, the problem is that the crypto uses the cert ID as a unique key in a database. When a dupe is encountered, you can't have two primary keys in a database, so it just dies with a fatal error, hence firefox gives up connecting to the site and passes on the fatal error to be presented.

Okay, so what about one of the following? Help me understand why one of the following won't work:

* Connecting without storing the certificate, period.

* Storing the dupe certificate in its own temporary database to be wiped on shutdown

* Using the old cert for the new site (if id==newid){connect}, throwing appropriate user warnings

* Throwing out the old cert when the new one is encountered (this database has to have delete functionality?), after appropriate user confirmation.

There *has* to be a workaround available for this that doesn't involve deleting the cert DB (--security) and/or installing a local proxy (massive PITA).

Kai, people are ranting because this behavior is absolutely braindead. The technical reasons are well documented, but the behavior at the end of the day is /shockingly dumb/. "The browser won't let me connect to my site? WTF?" 

The reasons given for this behavior are a mix between subtle and Kafaesque, and it's very easy to feel that this fell off the radar given the age, while all the new shiny stuff gets added to the browser.

Try to understand the frustration, please :)

Pseudo rant and request for clarification aside: How can an interested bystander help fix this?
Workaround suggestion:

If the NSS detects, that there is already a cert in the storage, that hs the same Serial,
offer a "Relace" Funktion to "Delete" the old from the storage and reinitiate the request.

Problem solved.
just to prove this is not only old firmware.

I have the same problem using latest firmware on Fortigate firewalls.

And it really is a problem, all other browsers allow me to temporarily connect but i get the security question each time.

That workaround is fine, but with firefox, I do not even get the option to replace the existing cert.
I'm getting reports that this also affects Canon printer drivers (which have a webservice for configuration), i.e. the imageRUNNER ADVANCE line.
Whiteboard: [psm-cert-duplicates] [no simple solution possible, fundamental NSS design issue] → [parity-IE][parity-Chrome][[psm-cert-duplicates] [no simple solution possible, fundamental NSS design issue]
This is not just an issue for firmware, but for PKI/web development too.

I am a sysadmin/developer and made the foolish mistake of attempting to work with PKI and Firefox.  Removed my (development) Root CA, recreated it fresh, and here is this issue.

8.5 YEARS and this is *still* a huge PITA.  Can someone in-the-know please report here about the progress/existence of the NSS bug report which I hope exists by now and that this bug is presumably tracking?  If it's a (security) feature of NSS, then please make it clear that FireFox's override code must be rewritten to allow such exceptions.

One place or another, an override/exception needs to become an option.
(In reply to jsengla from comment #198)
> I am a sysadmin/developer and made the foolish mistake of attempting to work
> with PKI and Firefox.  Removed my (development) Root CA, recreated it fresh,
> and here is this issue.

If your created a new root CA with the same serial number as your previous root CA, that's definitely NOT a bug in Firefox!
Of course creating a certificate with a duplicate serial# is not a bug in Firefox. What's a bug in Firefox is how it cannot be told to accept such a certificate in those cases where it's necessary by allowing exceptions. 

That's the bug.
Maybe the issue can be reduced to two problems:

1) What is the primary key for a certificate? Obviously it's something like "Certificate's Subject + Certificate's Serial Number". So different certificates using the same subject and the same serial number cause a problem (one could discuss whether the primary key is badly chosen, or whether the certificate created is illegal).

2) What to do if two different certificates would map to the same primary key? Firefox could ignore it and use the certificate already stored, causing a encryption problem most likely, or the older certificate would be replaced with the current one, causing no problem with the current connection, but probably for the site that uses the now replaced certificate.
The problem can be worked around with certutil.
Normally removing a certificate could be done with
# certutil -D 'hostname.fqdn' -d .
issued from the profile directory which normally contains the certificate DB.

Nevertheless, the possibility for an override button should be present on the security warning page.
It's been more than 8 years and we still cannot add an exception to this case? I cannot use firefox because of this problem in my development environment. I cannot change the certificate other developers created and need to work as is. We should be able to add an exception to this case.
Please, at least add a hint on how to remove the offending row from the cert db.
Could some knowledgeable person chime in and perhaps explain why it's not possible to have Firefox (offer to) nuke the offending dupe cert from NSS's certs.db and then try again? If I understand right, that database can be hit from outside of the NSS APIproper, which means we're still in the realm of Firefox feature rather than rewriting a core library.

Having the theoretical override button invoke a `certutil -D <cert fingerprint>` is strictly preferable to the current situation and is comparably trivial to implement.
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, parity-ie
Whiteboard: [parity-IE][parity-Chrome][[psm-cert-duplicates] [no simple solution possible, fundamental NSS design issue] → [[psm-cert-duplicates] [no simple solution possible, fundamental NSS design issue]
See Also: → 808735
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 7 duplicates, 86 votes and 91 CCs.
:keeler, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dkeeler)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dkeeler)
You need to log in before you can comment on or make changes to this bug.