Closed Bug 410622 Opened 18 years ago Closed 18 years ago

sec_error_reused_issuer_and_serial with certs made by Zimbra server script

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: iain, Assigned: KaiE)

References

(
URL
)

Details

Attachments

(1 file)

Corrupted Cert8.db after installation of new release
96.00 KB, application/octet-stream
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2 On this Zimbra server we have created a valid, local certificate in the approved way. FF2 warns correctly in some situations that the certificate relates to a different site name, but allows an override: sensible since it's our site and we know perfectly well that it's legitimate. FF3b2 has two different behaviours and I haven't been able to figure out what triggers one rather than the other (I've seen both on the same site a few minutes apart). Sometimes it gives the error "sec_error_ca_cert_invalid" and gives me the opportunity to access the site anyway (fair enough, though not the most transparent of error messages). Sometimes it gives the error "sec_error_reused_issuer_and_serial" with just a "try again" button. I'm aware that this could be seen as a dup of 405004 but would ask it be considered separately. 405004 has been closed as not being a bug but I believe this is a real issue for three reasons: 1. The behaviour of FF3b2 is different to FF2 2. The behaviour is inconsistent 3. When the sec_error_reused_issuer_and_serial error is seen, there is no way for the user to get to the site (I've been launching FF2 as a workaround). It may well be correct for FF3 to warn users of problems, but surely the final decision on visiting a site should belong to the users, not the developers. Reproducible: Sometimes Steps to Reproduce: 1. With FF3b2 go to https://fermat.axiomtech.co.uk:7071
Assignee: nobody → kengert
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm
You are responsible for making sure there are no duplicate issuer+serialnumber certs. Sorry, but we can't allow exceptions here. Seeing sec_error_reused_issuer_and_serial is a hard and very bad error. We have no way to distinguish the certs if those are duplicate. You are at risk that the trust of one cert would be confused with the trust of another cert, and a site might be treated as trusted, even though it's not. You clearly don't want that.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
(In reply to comment #1) > You are responsible for making sure there are no duplicate issuer+serialnumber > certs. > > Sorry, but we can't allow exceptions here. > > Seeing sec_error_reused_issuer_and_serial is a hard and very bad error. > We have no way to distinguish the certs if those are duplicate. > You are at risk that the trust of one cert would be confused with the trust of > another cert, and a site might be treated as trusted, even though it's not. You > clearly don't want that. > Hi, I understand your point, but from my testing this *is* a bug and *is not* working as designed. I have been getting this error, inconsistently, when connecting to my own Zimbra server, which has a correctly generated certificate. Sometimes I see the error, sometimes I don't. Are you saying that this is the correct behaviour? Note that I sometimes see this error even *after* deleting every single certificate from Firefox in Edit > Preferences > Encryption so I don't really understand what it's comparing to, to find that it's a duplicate. If Firefox were correctly and consistently identifying duplicate certs, I wouldn't argue but that doesn't appear to be happening.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
To add to this, I was getting this error on Friday (inc. after deleting all certs) and had to use IE7 to access the Zimbra server, which it did fine. But this morning (Sunday) I connected with Firefox fine. Nothing changed on the server between today and Sunday. I'm happy to run some debug on my side if someone requests it (you'll need to give me instructions as to what to run).
Same error message trying to access web interface of a linksys WRT54GS router. This was working under Firefox beta 1 acception an exception for the "invalid" certificate. I tried to remove the existing exception created with Firefox 3b1 but now I am not invited anymore to created an exception. This is definitly a bug ! Should you need me to debug this error, feel free, I'd be happy to help.
If you believe, there are no duplicate issuer+serial certs involved, please feel free to allow me to connect to your SSL server, just tell me host and port. For debugging all certs that are involved during a SSL handshake one can use the ssltap utility. http://www.mozilla.org/projects/security/pki/nss/tools/ssltap.html If you give me access to your server, I should be able to quickly run a connection through ssltap. If you can't provide open access, you'd have to run it yourself. Use command line options that give you dumps for all certs and attach them all.
This problem clearly involves multiple server certs. Access to one server's cert will not be enough, I believe. As a guess based on much past experience with this error I'd say there are multiple servers (perhaps multiple routers) each with a different certificate, but each of their certs has the same issuer and serial number. Just looking at one server's cert won't establish the existence of multiple certs with the same issuer name and serial number. And BTW, I would say that the reused issuer and serial error is one for which an override is not possible. NSS simply will not import a second (different) cert with the same issuer and serial as one already known to it. That's not a bug.
Well if it is not a bug why FF 3b1 was accepting to give access to such sites then ? Now another question, if it is not a bug how do I access my router now ? Installing XP with IE :-( And last but not least, why the option to accept this cert as an exception is not any more proposed ? *** IT IS A BUG *** THAT'S ALL ***
Kai : I try to use the ssltap but I am really sure it worked as I did not get any output. Do you have a sample command line for the output you would like to get so I can run it and send it to you ? Thanks in advance for your help
In reply to comment 7, The situation you described in comment 0 is CLEARLY the result of there existing two different certificates, each generating a separate error. Perhaps you have multiple servers (server systems, or server processes running on a single system) that have different certificates with the same issuer name and serial number. If so, you need to replace all but one of those certificates, so that each of the certificates you use has a unique serial number. Nicolas, I suggest that you explore the sources of the multiple certificates. Where do the certificates in your Zimbra server come from? How are they created? (with what software or what web site?) Have you recently re-created one? The existence of such a pair of certificates (two different certs with the same issuer name and serial number) is evidence of a bug in the software that creates them, not of a bug in your browser. Your browser is right to reject them. You should report a bug to the maker of that software that creates the certificates. Have you previously stored one of those multiple certs in your browser's cert DB? If so, you must delete it before you can accept a second one. That delete-and-replace strategy works in the case where one cert is replaced with another, after which the first cert is no longer used. But if you are trying to concurrently use two separate certificates with the same issuer name and serial number, that simply won't work.
Nelson Bolyard : I am sure you do not understand the problem here. I am talking about a Linksys router with its own certificate. It is the only one in my infrastructure (even if I had multiple the chance to have the same cert on different box is very low). Cert is generated by Linksys and you have no option to renew or change the certficate. As already stated this was working in FF3B1 after accepting the exception. Since FF3B2 it is not working anymore. FF3B3 the same error occurs. So it is a BUG in the browser. Once again how could you explain that the box is accessible using Konqueror for example. To finish with when I started to have problem I thought it was a corruption of the FF cert exception Database so I deleted the exception for that particular cert but since then FF does not even ask if I want an exception. If you simply do not want to investigate on this bug, just say it. Otherwise it is time to understand why and how this is occuring. Goggling I found various people reporting the same type of error (with Linksys router but also with web site or devices with web server). For me the end user (I that case myself) should have the final decision whether he wants or not to accept the browsing on any site. At least a parameter has to be available to manage that. I thought FF was flexible !!! Regards,
The error you describe means exactly one thing: Two different certificates, not identical, but have the same issuer name and serial number, are being (or have been) presented to the browser. The fact that two such certs exist is always the fault of the software the produces them. In all the years that Firefox has been producing that error code, there has not yet been a single case where that error was reported mistakenly. That is, in every case, Firefox was correctly the detecting the existence of two different certificates that bear the same issuer name and serial number. In NO case has that error been reported where two such certificates did not exist. In MANY cases, the users who experience this error do not initially believe that multiple certificates exist, and when they ultimately discover the existence of the second certificate, they are often astonished to learn of its existence. NSS cannot simutaneously accept two certificates with the same issuer name and serial number any more than it can accept that 1+1=3. You should be suspicious of the security of products that claim otherwise. The onus for finding the multiple certificates rests on you. There is no way that Mozilla developers can do that for you. But I can give you some ideas of where to look. If the cert in question comes pre-installed with your router, or are generated by the router software itself, then there are several possibilities to explore here. 1. Do you have multiple routers of this same brand? If so, examine each of them to see if they all offer different certs with the same issuer name and serial number. If you find that to be the case, please report it here, but also report it to the manufacturer. Is is a flaw in the software that generates those certificates. 2. Have you recently installed a firmware or software upgrade to that router product, or done any other action that might have caused the server certficate in that router product to be replaced or regenerated? If so, then perhaps you still have the old certificate in your browser's certificate database. In that case, the solution is to remove the old certificate from your cert database.
Hi Nelson, If that's the case, I'm a little surprised you aren't more curious about how I could connect to a server and see the error on Friday but not on the following Sunday (given that I manage the server so I know the cert didn't change). However, I'll investigate further and see if we can tell whether Firefox throwing up a false error or whether every other browser on the market is incorrectly accepting duplicate certificates without mentioning it.
Iain, Your situation and Nicolas's are slightly different in several ways. 1. Your certs are used by a server systems that is not a router. Nicolas's certs are used by a router 2. you seem to participate in the generation of the certs that are used by your server, Nicolas does not seem to participate in the generation of the certs used by his router (I gather). 4. You mention different behavior in FF3b than in FF2. Nicolas has not. Therefore, I request that Nicolas file a separate bug about his case, so that the progress in finding and/or eliminating the second certs can be tracked separately. But I am confident that in both cases, the problem will be solved when all but one of the certs with "reused" issuer and serial numbers have been eliminated. I merely wish to avoid further confusion by tracking two cases this different in the same bug. Nicolas, please cc me on your new bug.
Iain, can you tell us a little more about what a Zimbra server is, and how the certificate(s) for it are generated?
Nelson, Zimbra is a collaboration suite (think OSS alternative to MS Exchange or Lotus Domino). Their website is www.zimbra.com. They've got a wiki page about setting up self-signed certificates (which is what this server has) here: http://wiki.zimbra.com/index.php?title=SSL_Certificate_Problems I've mentioned the issue on the Zimbra forums: http://www.zimbra.com/forums/administrators/14332-possible-firefox-3-bug-may-cause-zimbra-problems.html
How do you generate your self-signed certificates? With what software? Does that software provide you with a way to specify the certificate's serial number when you create it? If so, generate a new cert for yourself and give it a new serial number. In the future, never reuse a previously-used serial number.
After reading the zimbra.com URL cited in comment 15, I looked again at the cert chain from your server. I see that a) you do NOT have a self-signed server cert, but rather you have issued yourself a self-signed CA cert with Zimbra's name in it and with serial number zero. b) according to that web page, the server originally came with a self signed CA cert with that same name and serial number. I think it is very likely that the following series of events happened. 1) you originally ran the server with the original cert in place. 2) you saved the original server cert in your cert DB. 3) then you reran the zimbra scripts for generating a CA cert and your server cert. The newly generated CA cert had the same issuer name and serial number as the original one. 4) you installed the new certs in your server, and got the error. You got the error because the CA cert in your cert DB has the same issuer name and serial number as the CA cert your server is now sending out. An examination of your cert DB should show the Zimba CA cert there. An examination of the "Certificate Signature Value" of that CA cert, and of the "Certificate Signature Value" of the CA cert being served by your server, should show that the two certs are not identical. When you run with FF2, you are using a profile that does not have the old original CA cert in it, which is why it does not get the error. In the short term, you can delete all the Zimba CA certs from your cert DB. That should stop the errors. In the longer term, the Zimba script that generates the CA cert should give it a unique serial number each time, rather than always using the serial number zero. It is a common mistake for writers of CA software to think that their root CA certificate must have serial number zero, or that it is a good idea for that serial number to be zero. In reality, serial numbers need not be sequential. Large 20-byte random numbers work very well. Even using the date/time as the serial number is better than using zero, or any other number, over and over.
I am terribly disappointed by your attitude similar to Microsoft. Always pushing the fault onto another product ! Instead of spending time trying to find another responsible for this bug, you should start debugging. Just to clarify nothing was changed in my environment the only thing that changed is FF version ! But it should not be FF according to you. I now understand companies who refuse to install open source software. Continue acting this way it will help MS to get more money. :-(
Ignoring the comments from the developers and bitching them doesn't help. And why should they start debugging, they already did it and found the reason. You usually can read in the RFC how such cases should be handled.
Iain, I expressed my willingness to debug. That's why I had asked you for clear step by step instructions on how to reproduce this bug starting with a profile. Unfortunately you did not provide such steps. You received a lot of attention in this bug for free (as in beer). And you have received clear explanations why this bug happens. We made reasonable assessments, even without having a clear test scenario. We gave you a lot of information that would enable you to carefully investigate the sites you visit and reproduce the bug. I think that's a high level of support. We did not refuse you, we did brainstorm about your reported problem, even though we can't see it. I'm resolving this bug as INVALID. Please feel free to reopen this bug when you are able to provide us with instructions on how to reproduce, then we will have a look. Thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → INVALID
(In reply to comment #19) > Ignoring the comments from the developers and bitching them doesn't help. > And why should they start debugging, they already did it and found the reason. > You usually can read in the RFC how such cases should be handled. > Well to me they did not debug anything ! They are just guessing the problem is somewhere else. You talked about help, that is exactly what I am looking for. I proposed my help to give you inputs to really debug. So if you think I am "bitching" your problem ! I am JUST DISAPPOINTED as already said.
One more comment. I do not think Safari and Koqueror are not following RFC. These 2 browsers are handling my case correctly ;-) Cheers !
I have the exact same problem as Nicolas. I have a Linksys WRT54GL. I have always been able to connect to it with Firefox 2 by telling it to ignore the unverified certificate. Starting with Firefox 3 beta I was able to connect to the router by adding an exception for the certificate. When I upgraded to Firefox 3 beta 3 I became unable to access my router--I get the sec_error_reused_issuer_and_serial error. I have no custom certificates in the Certificate Manager and no other devices are on the LAN or WLAN. I deleted the exception I created for my router with b2 and am unable to recreate it. So here I have a certificate that has always worked and no other new certificates in use--the only thing that has changed is I upgraded Firefox. Please let me know any diagnostics I can perform to help diagnose this problem.
Nicolas & Christopher, Your router problem is clearly different from the bug originally reported here. Rather than trying to combine two different (but superficially similar) problems into this bug report, please file a separate bug report.
Nicolas & Christopher, If & when you file a separate bug about this, put me on the CC list, and attach a copy of your browser's cert8.db file to that bug. Thanks.
Summary: Sometimes give error sec_error_reused_issuer_and_serial, preventing login → sec_error_reused_issuer_and_serial with certs made by Zimbra server script
Right after I posted my comment I `rm -r .mozilla` and that fixed the problem. After that I was able to re-add an exception for my router. I am guessing that the upgrade from b2 to b3 left my settings in an inconsistent state that confused firefox. I'm not sure if this constitutes a "bug" afterall or if it's just a fluke. I suggest Nicolas try deleting (or temporarily removing) his settings to see if it works for him. Thanks.
I renamed my cert8.db file and restarted FF3B3 (as same bug occurs in B3) and FF then allow me to add a new exception. Now it works. Sounds like cert8.db got corrupted or so. I would like to send you a copy of the incorrect/corrupted cert8.db file but I do not know how to attach it to this note. Please provide me with some instruction how to transmit that file to you. Thanks for your help !
I've found that rebooting my PC (without doing anything else like clearing the cache or deleting the certs) consistently resolves the problem. Not sure how this squares with it being a genuinely duplicate certificate, but it's OK as a workaround since the sec_error_reused_issuer_and_serial message only pops up once a week or so and I'll live with reboots for that.
In reply to comment 26, Christopher, have you had any recurrence of this symptom since you cleaned your profile directory?
This is a problem with a lot of embedded devices. I have the same issue with Zyxel-switches (and similar problems with fortigate vpn-routers). With FF3 security has been tightened, and in many cases it is now so tight it is simply "impossible" to mange devices from firefox. (You can always remove all certificates and restart FF between each device you need to configure, but that is really not practical). I clearly see the point of being strict about bad/wrong certificates, but we surely _need_ a way to override it when I _know_ the device is "secure", and that the _real_ problem is that some developer of routers in Taiwan has decided that it is easier to just load the same image (including certificates) on all devices. I do not ask for a simple point and click-thing, it can be an obscure "yes I really, really know what I am doing" option hidden away somewhere. It just have to exist.
Ola, the situation you described in comment 30, where an administrator has chosen to load the same server image into multiple servers, should not cause this error. If the same exact certificate has been loaded into multiple servers, that would not cause this error. Mozilla corporation has quite a few servers that all run with the same exact certificate, and there is no problem with that. The error sec_error_reused_issuer_and_serial occurs when there exist multiple different certificates, not identical copies, that bear the same issuer name and serial number. I suspect the real cause is something like this: whatever software you use to generate the self-signed certificate always generates a certificate with the same issuer name and the same serial number each time you run it to create a self-signed certificate. If you have run this software more than once, you have created more than one certificate with the same issuer name and serial number. It may be (as you suggest) that most of the routers in which this image has been installed have the exact same certificate in them. That's fine. But if you have even ONE other router that has a different certificate in it, a certificate also produced by that same software, such that there exists even one single pair of routers in your network with different certificates that bear the same issuer name and serial number, then that's the problem. I don't know what software you use to generate these self-signed certificates. It might help for you to name that software. We might be able to work with the developers of that software, to get them to change it so that it no longer always uses the same serial number. But we simply CAN NOT support multiple different certificates with the same issuer and serial number. It's not a matter of trusting a user to make a right decision. It's a matter of having only ONE place to put a certificate with a given issuer name and serial number. There cannot be two certificates in that one place.
Nelson commented: **************************************************** "But we simply CAN NOT support multiple different certificates with the same issuer and serial number. It's not a matter of trusting a user to make a right decision. It's a matter of having only ONE place to put a certificate with a given issuer name and serial number. There cannot be two certificates in that one place." **************************************************** If this is the case then how did you support multiple different certificates with the same issuer and serial number in Firefox 2? From the end-user's point of view this is how it looks: * Firefox 2 allows me to connect to certain SSL-enabled websites even if their certificate is not set up properly. * Firefox 3 will not allow me to connect at all to these websites. Can you see our point of view? Just saying "Your SSL cert is not correct" does not make sense to the end user for whom this used to work and now it doesn't. We had a certain functionality, and now it that functionality is broken.
The NSS certificate code used in Mozilla products has NEVER supported multiple certs with the same issuer and serial number in its entire history, which is now over 12 years old (of which I've been a part for the last 10.5 years). It is conceivable that some code somewhere in FireFox, outside of NSS, is somehow mangling certificates under some circumstances, so that two copies of the same cert, that should be identical, are not identical by the time the second one of them is presented to NSS, and NSS correctly detects this difference.
I have to say, I don't understand the https protocol enough to rewrite the code in my own browser to correct this problem, but rather it's called a "bug" or not it definitely impairs the usability of FF, and Seamonkey. I use the Linksys router that's mentioned in some of the above posts, and there is clearly a problem, in that it always produces a certificate with the same serial number. I've been in touch with Linksys, and they have no interest in fixing it. That being said, if I wish to continue to use my Linksys router I need a web browser that respects my ability to recognize a legitimate security risk and gives me the option to proceed at my own risk. Quoting Iain, "It may well be correct for FF3 to warn users of problems, but surely the final decision on visiting a site should belong to the users, not the developers." Just give me a button that says, "I know the risks, but I'm confident that I'm connecting to a safe site."
Mac, putting it differently: Because the uniqueness of issuer plus serial-number is an absolute requirement of the crypto standards, the people who wrote our code have decided to use that as a unique key. As of today, we are technically unable to distinguish two such items that share the same key. We might attempt to identify such a case when we're able to, but we must reject it, because our internal implementation is strictly unable to deal with it. I think your only choice is: Whenever you run into that error, go to certificate manager, find the linksys cert, delete it, and restart the mozilla application. After the restart, the conflict will be gone. But I think we're simply unable to deal with conflicting certs in a single application session, and unable and not willing to fix it.
Bug reports in bugzilla.mozilla.org are supposed to hold ONE bug each. This bug is about a problem with a Zimbra server that used customer-generated self-issued CA certs that had the same issuer name and serial number as the factory's default CA issuer name and serial number. That issue was resolved in comment 17 above. The other people who have added comments to this bug are having SEPARATE problems with SEPARATE products. Their problems are superficially similar, only because the same error code is reported. But the particulars of their problems are quite different. It is inappropriate to continue to use this bug, about a Zimbra server, to discuss the problems experienced with other products. So, let all further discussion about issues with certs in consumer-class routers STOP in this bug. Open a NEW bug for whatever router product you have (One bug per manufacturer is probably sufficient). This is not the first time you've been asked to do this. See comment 24 and comment 25 above. Any more comments in this bug about issues with products other than the Zimbra server will be hidden. When you have filed a new bug, add me to the CC list. I will add a comment there with some directions about how to gather the necessary evidence with which we should be able to determine, beyond doubt, whether there is any mozilla product bug here, or whether two certificate do indeed exist. I look forward to that new bug. No more non-Zimbra comments in this one!
Status: RESOLVED → VERIFIED
Nelson I do not agree with you when saying this reports a bug with Zimbra. To me it reports the bug of "sec_error_reused_issuer_and_serial ". Of course this was opened originally by someone having this error with Zimbra. Now we are quite a bit with different product having this supposed "invalid" certificate error. I just had the same problem re-occuring AGAIN with my Linksys Router after installing Beta 4. Once again... It is the Cert8.db that gets corrupted somehow !!! Deleting it fix the problem. I read the FF3 (not anymore beta) is about to be released. Is this version free of this bug ? Once again if you want to have a look a this invalid Cert8.db I still have it. Just let me know how I can forward it. Best regards, Nicolas
I found the button to attach file to bug :-) Thanks again for your help ;-)
Now I noticed my latest comments were removed ! :-((( So I am reposting... May be it gets removed again ? I do not agree with you Nelson. This is diffinitly the same bug. Here were are talking about the invalid "sec_error_reused_issuer_and_serial" error that FF3 reports (Beta 4 is also having the problem). Somehow the Cert8.db gets corrupted and then FF is not working as it should be after that. This case should be re-opened.
There are many problems that superficially appear to be the same because they have the same symptoms, even though the causes are different. In the bug tracking system, we file a bug for each separate problem, even if they have similar symptoms. The problem reported in this bug had a cause, which was that the software being used to generate the certs for the Zimbra server was generating multiple certs with the same issuer name and serial number, exactly as the browser reported. That was the cause of the problem reported in this bug, and it was not a browser fault, so from a browser point of view, it is not a browser bug, and hence is marked invalid. There are apparently a set of owners of routers of a certain brand that have a superficially similar problem (same error message). Unless their certificates are generated by the same software that generates the Zimbra server certs, the cause of their problem is a different cause, and therefore NEEDS TO BE FILED IN A SEPARATE BUG. Further attempts to attach irrelevant information to this bug could result in suspension of the offender's bugzilla account.
the issue is not that it is displying this issue, but there seems to be no real way to override it. if i want to connect the control panel app i setup on my linux box on localnetwork, (one that only allows https) im sure i can trust its who it says it is. and most users that use https do so for the encryption, not the identity check. What i request is a way for the end user to override issues like this. onething i have noticed is i am getting to more and more issues in firefox where there isn't a "i dont care" button, ever since ff3b started.
and on a side note: (In reply to comment #23) > the only thing that has changed is I upgraded Firefox. sounds like a bug. debuging 101: look at what changed, that's where the bug lays. We have user after user saying it only started to effect them after Firefox was upgraded. So my question is this: if its not a bug of Firefox's management for cert.db, and it is a issue if invalid certs, then why can ff2 ignore it, and ff3 not? why can't you code a little "I understand the risks. and don't care." button. Where is it your place to say if and when the end user can connect to any given site for any reason? I don't quite understand what gives you that right, other then the fact you code the only GOOD web browser. Under risk of losing users. I'd take a step back look at that, add buttons for "I dont care". Its not just this. I have seen them all over firefox3, and once the support for firefox 2 is dropped, that kind of thing will be the decider for many users when it comes to what browser to use.
This bug concerns users of Zimbra servers ONLY. The comments that others are adding to this bug, concerning issues with routers, belong in another bug, perhaps bug 312732. The problem that these router users are experiencing is due to the fact that FF3 remembers a certificate permanently (by default) when a user chooses to "add an exception", while FF2 only remembered a certificate for the duration of the browser process lifetime, by default. So, the duplicate cert is now embedded in the user's cert DB (the place where it is "permanently" stored), where it will be found as a duplicate the next time the browser is used to contact another router with a bogus cert. For users who experience this problem, the solution is to a) delete the duplicate certificate from their cert DB, using the browser's certificate manager, and b) do NOT create "permanent" exceptions for the bogus certs from those routers, but rather create only temporary exceptions. Bug 312732 says that the error message for sec_error_reused_issuer_and_serial doesn't explain these things to the user. That's the fix. FURTHER DISCUSSION OF ALL ROUTER RELATED ISSUES MUST TAKE PLACE IN ANOTHER BUG.
(In reply to comment #35) > As of today, we are technically unable to distinguish two such items that share > the same key. We might attempt to identify such a case when we're able to, but > we must reject it, because our internal implementation is strictly unable to > deal with it. The user-friendly solution is dead easy and plainly obvious: if a unique key has a different value attached to it than an already stored value for that key, ask for user permission and replace the value: if CERT1(stored) = X and CERT1(presented) = Y and USER = OK then CERT1 = Y. Everything else is pure unwillingness, not inability.
This is not just about routers or Zimbra, and it's unfortunate that you are deleting legitimate comments from end-users. Perhaps there needs to be another bug, fine, but the problem is quite simple: In Firefox 2, you could basically say "Yes, i am aware of the risks and I want to proceed." The same functionality is available in IE6 and IE7. Instead you have to go through a convoluted process to even find the certificate in the store, and then delete it before continuing on to the page with the duplicate-serial SSL cert. Why is it so hard to simply allow the expert user to acknowledge the risks and proceed? Also, why are you censoring comments instead of allowing us to discuss this issue?
*THIS* bug is precisely about Zimbra. See comment 43. Comments about other issues, not involving Zimbra DO NOT BELONG IN THIS BUG. Bugzilla is not a discussion group. Bugs have specific subjects, and specific goals. The goal of THIS BUG is to resolve an issue with ZIMBRA, that is now resolved.
I think the arguments of the developers are stupid, especially Comment #1. Firefox is not there to restrict their users, but the let them the choice of doing what they want. It is simply a fact that dozends of servers, switches, routers or whatever come with builtin remote management consoles. They typically have all the same cert and there is nothing wrong with it. While end users might be confused by self-signed certificates, administrators typically are not and thus should be able to decide on there on if they want to access the console anyway. If you own 20 servers which have the same remote management and builtin certs with the same id, then I don't see a reason to pay money for commercial certs or to issue 20 self-signed certificates that cause another ssl-warning to appear, just to have 20 different cert-ids. The ssl connection of the replaced certs isn't getting more secure with that extra work. It just takes lot of time and is annoying. This is not userfriendly as firefox claims to be! Kai argues: "Seeing sec_error_reused_issuer_and_serial is a hard and very bad error. We have no way to distinguish the certs if those are duplicate." But there surely is a way to get this problem solved: Let the user decide whether to remove the existing cert and serial number and use the new one. The same way a user is offered to create an exception for a self-signed cert, the user could get the option to ignore sec_error_ca_cert_invalid and get help from Firefox to fix the entry. Currently there is no choice than deleting the whole cert8.db losing all previous exceptions etc.; Thats just distressing and peaky.
Supporting this ticket's purpose. I too believe it's a bug as I've been getting it a long time now while trying to access my router (Linksys WRT54GL v4.30.11). "Error code: sec_error_reused_issuer_and_serial" This error appears only in Firefox. I use version 3+ and tried it on Sabayon Linux 4.0/4.1, Ubuntu 9.04 and Windows XP SP2. First few times on a clean installation works fine. IE, Opera, Safari, Konqueror - work fine.
Seeing this on access to Github: https://github.com/* results in an instantaneous redirect and the sec_error_reused error dialogue: https://github.com/backuppc "Secure Connection Failed ... (Error code: sec_error_reused_issuer_and_serial)"
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: