Closed Bug 244276 Opened 20 years ago Closed 19 years ago

Thunderbird won't use new cert with same issuer and serial number as an old one in the cert DB

Categories

(NSS :: Libraries, defect)

Product:
NSS
Component:
Libraries
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: pet, Assigned: mscott)

Details

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
(test@dover.sk)
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Component: Message Compose Window → Libraries
OS: Windows XP → All
Product: Thunderbird → NSS
Hardware: PC → All
(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.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Summary: Thunderbird can not work with 2 identical certificates (pop3s , smtp+TLS) → Thunderbird won't use new cert with same issuer and serial number as an old one in the cert DB
(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.
You need to log in before you can comment on or make changes to this bug.