User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040115 Firebird/0.8.0+ Build Identifier: Thunderbird version 0.6 (20040502), alsov version 0.5 During sending of message following error appears. 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. Server: pop3.dover.sk (pop3s - port 995, smtp - port 25) The problem is, that the SAME server certificate is used for pop3s service and for TLS in SMTP Thunderbird refuses to work with it, it either accepts it for POP3 and resfuses to use it for SMTP (so that i have to turn off TLS) or accepts it for SMTP and refuses to use it for POP3S (so i have to use POP3) This may be a feature, not a bug, but i don't see point why two (or even more) services (pop3, smtp .. https?) located on the same machine should not use the same certificate. At least, the certificate contains a lot of info (issuer, canonical name etc), but there is nothing like 'port' or 'service' specification, is there? Reproducible: Always Steps to Reproduce: 1.configure Thunderbird to connect to pop3.dover.sk, use any user name (email@example.com) 2. configure Thunderbird to use pop3s (port 995) and TLS over SMTP 3. try download messages, save certificate, when asked for password click cancel 4. try to send message Actual Results: Popup window: 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. Expected Results: Accept the certificate and send mail...
At one point I had this working in 0.5. Meaning I was able to use pop3-ssl AND smtp-ssl with the same certificate, then one day, out of the blue, I started getting that duplicate certificate serial number error dialog. I upgraded to 0.6 but it never worked, I got the dialog the first time I tried it. Even if I change back to non-SSL pop (port 110), secure SMTP still gets this error. I can only use pop-ssl, not smtp-ssl.
(In reply to comment #1) You will be able to use non-SSL pop + secure SMTP, you only have to delete current certificate (wich Thunderbird remembers as related to SSL-pop3). Go to Tools->Account settings-> Security -> Manage certificates and delete the appropriate certificate
This bug have recieved very little attention from the developers. Since there are no voting for this bug, I just want to join the users with problems related to using the same certificate for several parts of Thunderbird. This is a real problem form me and forces me to choose another mail client software.
This is really strange. My sysop made a new certificate for my imap and smtp server that didn't have serial number "00" (zero zero), but "06" (zero six). And it worked! I can now use the certificat to auth imap server as well as smtp server. It is still strange why "00" serial number should give you problems if "06" doesn't. But I'm happy that my problems are resolved.
I also am experiencing this problem. I'm using thunderbird 0.8 on Mac OS X, and though every version before this has had the problem, I've been able to get around it by never saving the certificate. However, in version 0.8 it no longer works. Why can't a SMTP server and an IMAP server have the same cert? This makes Thunderbird's SSL support useless in my setup...
I am getting this too. Both my work and myself are too cheap to buy certificates for SSL so we're both using the autogenerated courier-imap-ssl certs. It won't let me use both accounts via Thunderbird since the serials match. This should work, but just warn the user. I know what I am doing and I trust the certificates.
Todd, the standards require that the serials not match between two certificates. The security code has that assumption built in, and has problems when it's violated. This bug appears to be about a different issue, that a given cert can only be used for one email service.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
(In reply to comment #7) > Todd, the standards require that the serials not match between two certificates. > The security code has that assumption built in, and has problems when it's > violated. > > This bug appears to be about a different issue, that a given cert can only be > used for one email service. What do you think would happen if you released a browser that would only display HTML that strictly conformed to the standard? The answer is, no one would use it. Don't you think it would be far better to have a configurable option to allow the user the freedom of choice to permit non-standard certificate use? Try to be pragamatic -- many people have commodity accounts whose administration is beyond thier control. BTW, to repeate my issue, which is slightly different, I get the problem as a duplicate certificate when it is used for both smtp-tls and pop3s, these are the outbound/inbound of the SAME mail service. This bug is a show stopper for many people who want secured communication. Listen to the users.
I confirm that this bug occurs in all releases including 1.0.6 Thunderbird. I furthermore confirm that certificate on my server pop3.dover.sk has serial number 00 so it may be as Jakob Fredriksson wrote - only 00 cetificates are a problem? Please someone remove this 'strict certificate checking' at least in a way of configuration option (it can be in registry, on command line, anywhere, only please permit this - even ssh client has a way to turn off 'strict checking' of certificates..) pet
This bug report claims that the two certificates are identical, but the cited error message occurs when two certificates are DIFFERENT, but have the same issuer name *AND* the same serial number. In the world of X.509 certificates, one certificate refers to another by giving the issuer name and serial number of that referenced cert. The entire design of X.509 assumes that (a) every issuer will have a unique name, (that is, no two issuers will have the same name), and (b) no competent issuer will ever issue two certs with the same serial number. That is, no compentent issuer will ever use the same serial number twice in two different certs. Thus the combination of issuer name and serial number are designed to provide a unique identification for every certificate. That is not merely an implementation choice. It is fundamental to the design of X.509. It is common for databases of X.509 certificates to use the combination of issuer name and serial number as a unique identifier for the cert in the DB. That is the case in NSS. NSS puts all the cert into an internal DB that is uniquely indexed by issuer name and serial number. It *CANNOT* have two different certs with the same issuer name and serial number. When NSS gets a cert and sees that there is already a cert in its DB with that same issuer name and serial number, it checks to see if the two certs are identical (in every detail). If so, it can just throw the new one away and use the one already in the datgbase. But if it finds that the two certs are not identical, but share the same issuer name and serial number, then it must choose one or the other, because the DB cannot hold both. It chooses to keep the one it saw first, and drop the second one, and warns the user about the two certs. Software that creates every cert with serial number zero is lame. The world of correctly designed and implemented X.509 certificates should not have to redesign the entire X.509 system just because of some lame software. In regards to the original complaint: two servers CAN share an identical cert. But it has to be completely identical in every resspect. Two servers can NOT have certs that are DIFFERENT but have the same issuer name and serial number. I suspect that if you go back and examine the two certs that you claimed were identical, you will find that they were NOT identical, except in the areas of issuer name and serial number. The solutions for people who are generating their own certs are simple: either 1) use the SAME IDENTICAL cert on all your servers, not two different certs with the same issuer name and serial number, or 2) make every cert you create has a unique issuer name and serial number. To do that, I suggest you: a) put your own name in your cert as the cert issuer, and b) use the current date and time as your serial number. Serial numbers can be very big numbers,, and don't have to contiguous starting from zero. So on 2005-October-28 at 17:48, make the serial number 200510281748, and voila, you will have a unique combination of issuer name and serial number. Given that the software is working in accordance with the design of X.509, the international standard for certificates, this "bug" is invalid. It is also a duplicate of many other bugs with the same complaint.
(In reply to comment #11) > This bug report claims that the two certificates are identical, but the > cited error message occurs when two certificates are DIFFERENT, but have > the same issuer name *AND* the same serial number. At least in my case the IMAP and SMTP server were using the same cert file on the disk, so your explanation doesn't fit.
There is only one cause of the error message cited above. It is the discovery that a newly received cert matches the issuer name AND serial number of an already-stored cert, but is not bit-for-bit identical to the stored one.
(In reply to comment #11) [...] > Given that the software is working in accordance with the design of X.509, > the international standard for certificates, this "bug" is invalid. > It is also a duplicate of many other bugs with the same complaint. > What is the goal here? Is it to provide a usable product for end users, or to provide a product that will only function properly in an environment in which all pieces strictly conform to the standards? If the goal is to provide a usable product, then the user should be permitted to proceed with a non-conforming configuration, after clicking through appropriate warning dialogs (only the first time, though, please) A measure of software robustness is the ability to interoperate with external participating components, even if they are not perfectly configured. Keep in mind that many users have no control over the administration of their ISP's e-mail servers. Imagine if Firefox only permitted displaying web content which strictly conformed to xhtml, and rejected all other content -- no one would use it.
When it comes to security code, the primary goal is to provide security, and that requires parties, in particular cert issuers, and server administrators, - not so much end-users - to do their due diligence. The problem we are talking about here is not a minor misconfiguration on the ISP's part, it is a security hole big enough you could drive two military tanks through it. There are a dozen other major security problems with the way the ISP certs are setup here that I won't even mention. It's simply not possible to provide security given this setup. Mozilla is fully justified in not supporting this setup. There is no possible circumstance in which anybody has any business accepting those certs. If the users don't want security or warnings, they can use the regular application protocols without SSL/TLS, which don't use certs. If the users want security, then there is a minimum amount of security know-how expected of the ISP and CA for security to be actually achieved. In this case, the threshold is not even close to having been met.
(In reply to comment #13) > There is only one cause of the error message cited above. It is the discovery > that a newly received cert matches the issuer name AND serial number of an > already-stored cert, but is not bit-for-bit identical to the stored one. Well, I just double checked. I pointed my imap server to the EXACT same certificate that sendmail is pointing to and now Thunderbird gives me the error from comment #0. So I still say there is a bug in Thunderbird. The code is not working the way you think it is...
(In reply to comment #15) > When it comes to security code, the primary goal is to provide security, and > that requires parties, in particular cert issuers, and server administrators, - > not so much end-users - to do their due diligence. The problem we are talking > about here is not a minor misconfiguration on the ISP's part, it is a security > hole big enough you could drive two military tanks through it. There are a > dozen other major security problems with the way the ISP certs are setup here > that I won't even mention. It's simply not possible to provide security given > this setup. Mozilla is fully justified in not supporting this setup. There is > no possible circumstance in which anybody has any business accepting those > certs. If the users don't want security or warnings, they can use the regular > application protocols without SSL/TLS, which don't use certs. If the users want > security, then there is a minimum amount of security know-how expected of the > ISP and CA for security to be actually achieved. In this case, the threshold is > not even close to having been met. > I don't know what the security hole you're talking abnout is, or the "dozen other problems" you won't mention. I think it's ludicrous to say if the users don't want warnings, they can only chose to not have encryption. Let me just say from a user perspective this: For the same server configuration, if I use Mac Mail, it works -- if I use T-Bird it does not work. The only reason I don't just switch back to Mac Mail, is that I use a variety of platforms, and would prefer using the same mail client on them. Since we're trying to solve a problem, here are the details, including information not in the first report. (my report) Per nelson_bolyard.com suggestion, I went back and examined the certificates on my ISP's pop3s and smtp/ssl services, using Mac Mail, which permits this immediately from the warning dialog. Mac Mail did not like the certificates either, but the error was, "the root certificate for this server could not be verified", it could be because the type of certificated is "X.509 v3 root certificate". Presumably this means they didn't get the cert from a CA, but minted it themselves. Fortunately, Apple apparently gives higher priority to the users's freedom of choice, rather then having some developer decide for me what is secure and what is not, because they present a warning dialog with a "continue" button, allowing me to proceed at my own risk. Furthermore, when I repeat the process, I am not asked to click through those dialogs again. I recieved the same warning dialog when sending outgoing mail via smtp/ssl. The two certificates have the same issuer name, but different serial numbers, therefore, they are, in fact different certificates. When I try the same setup on T-bird, I don't get a warning dialog on the inbound, pop3s, but upon attempting an outbound connection via smtp/ssl, t-bird hangs. My ISP makes SSL secured SMTP available on the same port, 25 (not 465). I read that this is commonly done lately and SSL negotiation begins with a standard, non secured socket connection. However, if I reconfigure for smtp/tls, I get the duplicate certificate error dialog. I have to admit that I was under the impression that TLS and SSL were the same thing, so I am not certain what the issue is here. In summary: pop3/ssl smtp/ssl smtp/tls ----------------------------------------------------------- T-Bird works hangs duplicate serial number error ----------------------------------------------------------- Mac Mail get can't verify get can't verify no tls option root cert warning, root cert warning, on Mac Mail but then works but then works after user ack after user ack
(In reply to comment #17) *** I got it working with T-bird! I found a very interesting artifact using the "manage certificates" screen. In the "authorites" tab, I saw an expired certificate from my ISP listed as type "software security device". I deleted this certificate and re-tried the setup exactly as described in message #17, above. This time, upon making the first pop3/ssl request after deleting that expired CA cert, I got the warning dialog that the certificate could not be verified. If I select "accept this certificate for this session", I can proceed. If I make another request to check my mail, I still get the warning dialog, and I have to *again* indicate my preference to accept the certificate temporarily. -- that's a bug, it should not ask me again until I restart t-bird. The outbound story is a little better; upon sending my first message after deleting the expired cert., I get the warning dialog the certificate could not be verified (different cert then the pop3/ssl cert). When I select "accept this certificate temporarily for this session", I can proceed. When I make subsequent requests to send smtp messages, I do *NOT* get re-prompted, so unlike the pop3/ssl case, this works as expected. If I repeat the test case above but accept the certificates permanently, both times (inbound pop3/ssl and outbound/tls) then I don't get the warning dialogs again, even after restarting T-bird, as expected. Addtionally, when I go into the "manage certificates" screen, those two certificates are listed under the "web sites" tab, not the "authorities" tab, as was the expired certificate that had caused all this trouble in the first place. (for me) Summary: There is a condition where if a certificate somehow gets installed as a CA type certificate and expires, then smtp/tls using a newer certificate from the same issuer (sorry, I failed to note the serial number of the expired CA certificate) but with a newer date, causes a duplicate certificate error dialog. For inbound pop3/ssl connections, if a warning dialog is presented to the user and the user chooses "accept this certificate temporarily for this session", then that dialog continues to pop up each time the user presses the "get mail" button, even though the dialog should be suppressed after the first acknowledgment. (this does not happen on outbound smtp/tls)
Comment 18 confirms my diagnosis. The server had been using a self-issued cert. The user had stored it in his DB, by having chosen to "accept this cert pemanently". Then the cert expired, so the server admin issued himself a new cert, but used the same serial number as in the previous one. So, the server admin had issued two different certs with the same issuer name and serial number. That was an error on the part of the cert issuer. The new cert should have had a different serial number (and/or issuer name) than the previous one. When NSS encountered the new cert, it found that the new cert had the same issuer and serial number as one already in the database. The rest is as I described in comment 11 above. Comment 17 introduced another complaint, namely that "accept this certificate temporarily for this session" causes recurrent dialogs during the same session. That is a separate problem than originally reported here. There is at least one other bug already filed on that TBird issue, so please don't file another duplicate bug on that issue. Thanks.
(In reply to comment #19) I think that before the certificate expired, they were using the same one for *both* pop3/ssl and smtp/ssl, which is the original complaint in this case and which is why I had earlier chimed in with the other users who were experiencing problems when their ISPs were using the exact same cert for pop3/ssl and smtp/ssl. In that case, this may still be a valid bug. > > Comment 17 introduced another complaint, namely that "accept this certificate > temporarily for this session" causes recurrent dialogs during the same > session. That is a separate problem than originally reported here. > There is at least one other bug already filed on that TBird issue, so > please don't file another duplicate bug on that issue. Thanks. > I think I would have searched for an existing case before filing a new one (like I did in this case), but thanks for the pre-emptive admonishment.