219980 - Improve duplicate serial number error message

Status: RESOLVED FIXED

(Core Graveyard :: Security: UI, enhancement)

Description

[Mike Christie]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916

My company acts as the issuer for the certificate we use internally.  At one
point the admin forgot to increment the serial number for the certificate when
they issued a new one.  As a result Mozilla produced an "invalid certificate"
message and correctly indicated the cause of the problem.

However, never having used the certificate manager and not being very familiar
with that area, I was unable to figure out how to fix it.  Eventually I figured
out that I needed to delete the expired certificates and everything was fine.  I
think the error message should be more informative, though.

For example, it would be useful to tell the user that if they still wish to
accept this certificate they need to go ahead and locate the duplicate via the
certificate manager and delete it.  That also means the message should include
enough information to uniquely identify the certificate when they go to delete it.

Even better would be to say "do you want to delete the old certificate and
replace it with this new one?"  This could happen either every time, or perhaps
only when the old certificate is expired.

Reproducible: Always

Steps to Reproduce:
Reproduction is difficult as I know of no public sites that have this problem. 
If you want to reproduce it you have to issue certificates, which I don't know
how to do.  I hope the description makes it easy to figure out how to reproduce
this.



This is low priority because it will probably never affect public websites, only
intranet sites.  However, I do think that when Mozilla point-blank refuses to
display a site, it should be possible for most users to figure out what to do
about it.  That's not the case with this problem, which is why I am suggesting
this enhancement.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Certificates are handled by PSM.

Comment 2

[Peter Kroll]

I have this same problem.
On ev1servers.net they sell dedicated servers that use the default SSL cert, for
connecting to your admin panel, that comes with Apache and Mozilla accepts it.

However, when I reinstalled the server on the same ip then tried connecting
again with Mozilla I get the error mentioned in this bug. If I go to Manage
Certificates in the Mozilla Preferences there are no certificates listed, so I
don't know how I could remove one and accept the other. 

It's safer to accept a bad cert and use encryption than to send data
unencrypted. This issue really has to be fixed. At minimum it should accept the
certificate for this session. That way you can connect to the server. As it
stands now the server it totally unavailable to Mozilla. I am forced to connect
using Internet Explorer which means a major functionality is broken in Mozilla
and this needs to be fixed in 1.7

Comment 3

[Peter Kroll]

Attachment: the error message in question.

Comment 4

[David Anderson]

I have the same problem in Mozilla 1.6. I attempted to use Firebird to connect
to my server when Mozilla refused, but got the same message in that browser too. 


(In reply to comment #2)
> However, when I reinstalled the server on the same ip then tried connecting
> again with Mozilla I get the error mentioned in this bug. If I go to Manage
> Certificates in the Mozilla Preferences there are no certificates listed, so I
> don't know how I could remove one and accept the other. 

Comment 5

[John G. Myers]

Perhaps we should change this to say "...get a valid, reissued certificate"? 
The only correct fix is for the certificate to get reissued with a new, unique
serial number.

Comment 6

[Peter Kroll]

>Perhaps we should change this to say "...get a valid, reissued certificate"? 
>The only correct fix is for the certificate to get reissued with a new, unique
>serial number.

The Internet isn't perfect, so we need to temporarily accept certificates that
have duplicate serial numbers if the person chooses. Or to overwrite the old
certificate with the new one.

Comment 7

[John G. Myers]

I disagree with comment #6.  Serial numbers serve a purpose.  If they weren't
needed for that purpose, they wouldn't exist.  We need to get the problem fixed
in the correct place.

This bug is about improving the error message.  Despite information in the error
message as to how the problem needs to be resolved, the reporter appears not to
have comprehended the correct solution, namely to have the admin issue a new
cert.  The error message is clearly worded poorly.

Comment 8

[Peter Kroll]

John,

Collectively we need to make encryption easier not more difficult.
Why is mozilla stopping me from doing what I want?

My hosting provider uses disk images to install OSs for all it's boxes.
Therefore the default certificates all have the same serial number.

There is no doubt that the absolute "correct" procedure is to have a certificate
reissued from a proper authority. The correct procedure isn't to use default
certs anyways.

However, what you fail to understand is using a duplicate certificate is safer
than sending data unencrypted, so why should we encourage people to send
unencrypted data, by making SSL more difficult to use.

This bug does mention it's suggested solution as changing the error message, but
there is no need to file another bug report for this exact bug, when all I want
to do promote the idea suggested by the bug reporter that the cert be accepted
temporarily or to overwrite the old cert.

Are you aware that it costs $750 for a wildcard cert? That's why these default
certs are being used.

Here at mozilla we don't have control over website admins, so we have to make
things easiest from our end.

I don't think you fully understand this issue.
Mozilla accepts a cert which is tagged to an ip/domain. The server is then
reinstalled same ip and same serial number, then mozilla rejects the cert.
It makes no sense why we accept it the first time and not the second time.

Comment 9

[Mike Christie]

Following up the debate about what the error message should say, here's a note
from my sysadmin which I received a minute or two ago, about the fact that a
warning will come up on the certificate for our intranet:

"This is because the certificate is signed by our own internal "Certificate
Authority" instead of paying someone like Verisign $200 to sign it.  We didn't
feel it was necessary to spend the money for a site that will be accessed only
by our employees (The "clients" site DOES have a "real" certificate)."

We're a small company and I think this is the right solution for us, thouagh
clearly it's not "right" in the broader sense.  "Non standard" uses of
certificates are legitimate and should be supported.  (I'm aware this is not the
exact issue reported here, but it is another illustration of valid non-standard
uses of certificates.)

John, you suggested I'd misunderstood the error message.  Perhaps so; but it may
just be that I want Mozilla to do something you think is inappropriate.  I
*don't* want the solution to be that I cannot access the website until my
sysadmin does something -- that seems clearly wrong to me, given the
circumstances.  Obviously if I distrust the site I should not access it, but
since it's my intranet and I know exactly what's gone wrong, I should have the
opportunity to access the site.  If I understand the situation correctly, the
only way to do that without waiting till the sysadmin arrives at the office is
to delete the old certificate with the incorrect serial number.  The message did
not inform me that I could do this; that's the improvement I would like to see.

Comment 10

[John G. Myers]

The admin doesn't need to get a cert from a paid authority, the admin merely
needs to reissue the cert from their own internal CA, giving the cert a unique
serial number.

I believe the wording of the message needs to emphasize the serial number more.
 Something like:

You have received an invalid certificate.  It contains the same serial number as
 another certificate issued by the certificate authority.  Please contact the
server aministrator or email correspondent from which this invalid certificate
came, and urge them to get a reissued certificate, with a unique serial number.

Comment 11

[Peter Kroll]

John,

I agree with Mike, only problem is there is no way to delete the old certificate.

So there needs to be a way to accept the certificate temporarily or a way to
delete the old certificate.

I understand that you are trying to promote proper certificate use through
locking the browser out of the site. But I don't think mozilla's current
behavior is appropriate. Even though you are correct you don't need to purchase
from a CA and can issue them yourself.

Certificates with the same serial number are being used because of OS disk
images or other reasons.

If you personally have encountered this error you would understand how
frustrating it is. I am forced to connect to the site using another browser.

The issue here is really not the message or it's wording it is that there is NO
way to connect to the site in question without the servers certificate being
changed. And the scenerio where this personally affects me is I have to connect
to a control panel that control panel has the feature of allowing certificates
to be requested. How can I connect and try and get the issue fixed if I am
LOCKED out of the site.

You are suggesting emailing the site admin, what if the certificate in question
is used for connecting to my POP3S server securely (which I cant do because of
this bug), then how will I email?
I'm forced to send my email password over clear text to correspond with the site
admin, get the issue fixed then connect securely. Why not temporarily accept a
certificate which I personally trust and connect securely and get the matter
resolved.

Does this make sense?

Comment 12

[Mike Christie]

Are there in fact two separate issues here?  One is that if a new certificate
has incorrectly got the same serial number as the old one, the message does not
indicate that there is a way to view the page by deleting one certificate.  The
other is that in the situation Peter gives, there are no certificates listed in
Manage Certificates so there is no way to view the page.

If these really are separate issues then perhaps we should create a new bug to
track one of them.

John, I looked at your suggested rewrite of the error message.  I admit it's
hard to see how to word it in such a way as to give the information I requested;
and it is also almost always going to be correct to contact the sysadmin in
question to get them to fix it.  The situation I was in was that I wanted to use
the intranet one weekend and couldn't; the sysadmin was not available till
Monday (this is not a production site, so there is no weekend support).  I could
have used it if I had deleted the earlier certificate, which is what I
eventually did, some time later.  As it was I had to use IE.

Here's a suggested change to your error message:

            "You have received an invalid certificate.  It contains the same
serial number as another certificate issued by the certificate authority. 
Please contact the server aministrator or email correspondent from which this
invalid certificate came, and urge them to get a reissued certificate, with a
unique serial number.  If you have reason to believe that this certificate is
correct, you must delete the certificate it conflicts with.  You can do this
using the certificate manager, which can be found under Edit -> Preferences ->
Privacy & Security -> Certificates."

I think the question about this suggested error message is not the wording,
which no doubt could be improved, but whether this information is appropriate
for an error message.  I believe it is, for the reasons I give above.

Comment 13

[Peter Kroll]

I think you are right mike their are two issues here. because when I go to
Manage Certificates there aren't any to delete.

Comment 14

[John G. Myers]

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.

Comment 15

[John G. Myers]

Having Mozilla handle certificates with duplicate serial numbers would be a new
enhancement bug to be filed against NSS.  I don't know whether or not such an
enhancement would be technically possible.  This bug is about the wording of the
existing error condition.

(In reply to comment #12)
> As it was I had to use IE.

Which probably has the advantage of not having seen the other cert.

> If you have reason to believe that this certificate is
> correct, you must delete the certificate it conflicts with.

This has nothing to do with what the user believes.  This is not an issue of
trust, it is an issue of bad protocol.  The certificate is unquestionably in
violation of the protocol spec.  There is no sense asking the user if they think
the cert is "correct", whatever that is intended to mean.

As for deleting the other cert, that might have worked in your particular
situation, but it is not a general solution.  The duplicate certificate is not
infrequently the certificate's issuer, so deleting it can cause other problems
or simply be ineffective due to the cert and issuer both being in the cert
chain.  The duplicate certificate could also be for a different server that the
user frequents, causing the failure to reoccur when the user goes back to that
other server.

There is the problem of how to identify the duplicate cert.  Just mentioning
"the duplicate cert" is just going to leave the user more frustrated because
they will have no idea what to delete.  If they managed to find the certificate
manager, they could likely just start randomly deleting certs, causing no end of
problems.  The APIs have no way to pass a cert or any other supplemental
information from the place where the error is detected to the place where it is
reported.

If NSS were to automatically delete the duplicate cert, that could appear to the
user as if Mozilla were randomly losing cert trust information.  They would be
frustrated because Mozilla would unpredictably reask them about certs they had
previously told Mozilla to remember as OK.  Receivers of the resulting bug
reports would have a hard time diagnosing the problem as being caused by
duplicate serial numbers.

I sympathize with your situation, but there just isn't that much Mozilla can
reasonably do without making the situation worse.  Unfortunately, the more words
a dialog box has, the less likely a user is to read any of them.

Comment 16

[Peter Kroll]

John,

Mike is the bug reporter and he said he doesn't want mozilla to not allow him
onto a site in this case.

Why do you keep insisting that the only thing that can be done is fix the error
message?

Allowing the cert temporarily is very important to me.
I have a server with many domains on it and I haven't setup each domain with a
cert because the general public doesn't use those servers. So the server sends
the default localhost cert and mozilla will only accept the cert for the first
domain I go to with SSL because the CN doesn't match. So I'm forced to check
email unsecurely. Cause I get a similar error to this one in the email client as
well.

If you don't want to get to the bottom of this problem assign it to someone
else, but the words on the error message won't fix anything.

Comment 17

[John G. Myers]

(In reply to comment #16)
> Why do you keep insisting that the only thing that can be done is fix the error
> message?

My reasoning is in comment #15.

> Allowing the cert temporarily is very important to me.

As I mentioned in comment #15, that would be an enhancement filed against NSS. 
NSS relys on the uniqueness of serial numbers.  It uses the issuer name and
serial number as a key into cert storage and is thus not capable of processing
duplicate certs.

> I have a server with many domains on it and I haven't setup each domain with a
> cert because the general public doesn't use those servers. So the server sends
> the default localhost cert and mozilla will only accept the cert for the first
> domain I go to with SSL because the CN doesn't match. So I'm forced to check
> email unsecurely. Cause I get a similar error to this one in the email client as
> well.

Unlike duplicate serial numbers, host name mismatches are overridable.  A
"similar" error is not this error.  What you are describing is not this bug.

Comment 18

[Peter Kroll]

Ok. I'll file another bug against NSS

Comment 19

[chris hofmann]

would need a patch to make 1.7a

Comment 20

[Henrik Gemal]

You can reproduce this error by first going to:
https://i.tdconline.dk/tdco/gfx/local/sso/knap_q.gif
then go to:
https://bestilling.certifikat.tdc.dk/csp/authenticode/README

wasn't it possible to tell which certificates that are duplicates? I got the
error and I still haven't found out the root of the cause.

Comment 21

[John G. Myers]

(In reply to comment #20)
> You can reproduce this error by first going to:

It doesn't reproduce for me, Mozilla 1.6 MacOS 10.3.

Comment 22

[Peter Kroll]

I could not reproduce the instructions in Comment #20 either.

Comment 23

[John G. Myers]

Comment #20 has been diagnosed elsewhere as a 1-bit difference in one of the
intermediate certs.

Comment 24

[Henrik Gemal]

comment 20: is no longer valid, since we fixed the certs on the server

Comment 25

[John G. Myers]

*** Bug 219028 has been marked as a duplicate of this bug. ***

Comment 26

[John G. Myers]

Attachment: Proposed fix

Comment 27

[John G. Myers]

I'm also putting together a patch to openssl to use the current time as the
default (initial) serial number.

Comment 28

[Henrik Gemal]

would it be possible to actually tell which server we're talking about. I got
the error due to an invalid cert at a https server serving some javascript.

"you got an invalid cert from blablabla.net"
or something?

Comment 29

[John G. Myers]

(In reply to comment #28)
> would it be possible to actually tell which server we're talking about.

Not before the localization freeze this round.  There's also the problem that
the error could be encountered in S/MIME.

Comment 30

[Mike Christie]

I would like to suggest a couple of modifications to the proposed error message.
 Here's the current version:
-----------------
You have received an invalid certificate.  Please contact the server
administrator or email correspondent and give them the following
information:\n\nYour certificate contains the same serial number as another
certificate issued by the certificate authority.  Please get a new certificate
containing a unique serial number.
-----------------

John and I have exchanged comments about the fact that the particular problem I
had (see original description) does not lend itself to useful suggestions by
Mozilla in the error message.  See comments 12 and 15.

However, in my original situation I would like to have had Mozilla at least
point me towards more information I could find out for myself, rather than
having to wait for a sysadmin to respond.  So I would like Mozilla to indicate
that I have the option of looking in the certificate manager, by giving me a
button that would take me directly there or by indicating how to get there.

Here is a suggested rewording:

---------------------
You have received an invalid certificate.  Please contact the server
administrator or email correspondent and give them the following
information:\n\nYour certificate contains the same serial number as another
certificate issued by the certificate authority.  Please get a new certificate
containing a unique serial number.  To examine the invalid certificate, press
the "Manage Certificates" button below.
---------------------

If this is doable, then it would also be nice to have it come up on the
appropriate tab within the certification manager.

John, your concern in comment 15 was that my suggested wording then was not
always appropriate.  I agree with your criticism.  My problem with the current
suggestion is that it does not tell a reasonably savvy user where to look to
understand the problem better.  I've tried to make the wording such that it does
not prejudge what the user should do; it simply provides access to a Mozilla
resource that can display more information.

Comment 31

[John G. Myers]

The localization freeze for 1.7 was last night, so barring significant problems
what we have is what we're going to have for 1.7.

Comment 32

[Greg Colyer]

Regardless of the formal appropriateness or technical possibility of allowing
duplicate serial numbers, at the very least Mozilla should not appear to claim
(in its error message or by inflexible behaviour) that the first certificate is
valid and the second certificate is invalid. Maybe the first one was issued by
mistake? That is one reason why deleting the old certifcate and accepting the
new one can be a correct solution to this problem.

Also, it is a general rule that any solution REQUIRING recourse to a third
party, such as a remote administrator, is almost bound to lead to some user
frustration. Third parties can be absent, stupid, underresourced, unhelpful,
etc. They can also say, without malice, "Why not use IE? No-one else is having
any problems."

Comment 33

[Peter Kroll]

Thanks Greg, at least someone else sees my point. I've intentionally keep the
bad certificate on the server, waiting for this bug to be properly fixed.

Comment 34

[idleloop]

I have firefox 1.0.4, and this issue has not been fixed,
at least from the point of view of the final user.
I think there should exist the possibility for the user to choose to go on.
I have two valid certificates purchased from a root CA, and, I don't know how, 
they two have the same serial number, so no firefox user can navigate my whole 
site without shutting down and re-runnin' firefox in order not to know about 
the previous certificate.
Yes, I can go now to the root CA, in order to fix the problem (if it's 
possible), but since I have had these certificates for one whole year, I 
wonder how many firefox user have move to IE just to navigate, without the 
lesser understanding of this window error?
This is not the way. The user must have the final decission, even if it's not 
the addecuate one.
thanks 4 your time.

Comment 35

[John G. Myers]

The wording change was checked in quite some time ago.

Comment 36

[Mike Christie]

The wording change was checked in, but there is a subsequent comment from me
suggesting that more should be done; and comments suggesting shortfalls in the
current approach from at least two other users.  I believe the current wording
is only an interim fix and feel this should be reopened; I hadn't realized it
was shown as a resolved bug.

Comment 37

[Mike Christie]

Reopening per my previous comment.  The current situation is an interim fix and
I believe does not fully address the issues raised.  See comment #32 and comment
#34 for more details.

Comment 38

[John G. Myers]

Per comment 15, this bug is solely about the wording of the error message.

Comment 39

[Mike Christie]

I have opened bug #312732 to address the issue of access to the target website,
per John's comment about restricting this bug to address wording only.

Comment 40

[Greg Colyer]

Would someone please confirm the current wording? If it is the wording at the
TOP of comment #30, which seems to be what is implied by comment #31, then the
present bug (even if confined only to the wording) is not resolved. As explained
already in comment #32, the message should not imply (i) that the new
certificate is "invalid" and the old one is OK, when it might be the other way
round, nor (ii) that the only appropriate solution is to contact a potentially
mysterious/non-existent/uncooperative/etc. administrator.

In particular, if an expired (out-of-date) certificate is replaced by a new one
with the same serial number, it should surely be the old one which is regarded
as invalid. This may well happen with sites acting as their own CA. Perhaps they
are violating the specs, but perhaps they are not going to change.

Comment 41

[John G. Myers]

A new cert that differs from a previously issued cert in expiration date but has
the same serial number is invalid.  This is the case even if the previous cert
has expired.

Comment 42

[Greg Colyer]

John, you seem to be saying that if there are two certificates with the same
serial number, then the one issued later is invalid regardless of the status of
the other. Can you justify this precise point from the relevant standards?

Incidentally, if Mozilla has already accepted a certificate which turns out to
be the newer (invalid) one, what does it say if it is subsequently presented
with the older (perhaps still valid) one? If it gives the same message, then
even by your logic the message would be wrong in that case.

Comment 43

[Mike Christie]

Reopening, since I agree with comment #42 that the wording does not fully
address the possibilities; nor does it provide the user the information to
resolve the issue for themselves, per the suggested rewording in comment #30.

John, if you reclose this, please explain how those two points are addressed in
your view.

Comment 44

[John G. Myers]

If there are two different certificates from the same issuer with the same
serial number, then they are both invalid.

Comment 45

[Mike Christie]

That addresses comment #42 as far as I'm concerned; it doesn't address the
request in comment #30 for a rewording that allows the user to fix the problem
for themselves.

Your comment #15 implies you feel it is pointless to add more text to address
this since the user will not read it.  Is that why you will not modify the
wording?  Or would it be appropriate for me to raise another bug that
specifically requests that wording change?

Comment 46

[John G. Myers]

I don't see how telling the user to examine the certificate is going to solve
the problem.  It seems to me to be a red herring that is merely going to
frustrate the user.

There's also the problem that the proposed additional wording is a dangling
clause.  The server administrator is supposed to click on the button to examine
the cert?

The process for appealing a module owner decision is through [e-mail].
 See http://www.mozilla.org/hacking/module-ownership.html

Comment 47

[Mike Christie]

Thanks for the additional comments.  I agree that this need not be reopened. 
Assuming bug #312732 does not end up as WONTFIX, the solution to that bug will
of necessity give the user directions to access the target website.  Hence there
would be no need for any wording that would assist the user in investigating the
certificates via the certificate manager.

Comment 48

[Greg Colyer]

Bug #312732 was ultimately RESOLVED INVALID; its last comment dreams of "better messaging, but that won't be in this bug."
So should the present one be reopened?

A reminder of the original context: a site certificate has previously been accepted by the user; the provider replaces the certificate (let's call it A) by a new one (let's call it B) with same serial number; the user needs to be helped to work around this security violation and access the site.

According to comment #44 above, in this scenario A and B are both invalid. If the browser nevertheless allows the user to retain the previously accepted A, it should not refuse to countenance the deletion of A and acceptance of B instead.

Comment 49

[John G. Myers]

Holy necro, Batman!

I haven't done development on Mozilla for over a decade, so take my comments in that context.

You would probably find your efforts more productive identifying and filing bugs against the CA implementations that are generating these duplicate serial numbers. (You'll see in comment 27 that I did so for one common implementation.) Modern practice is for serial numbers to contain a minimum amount of securely randomly generated entropy; this protects against certain types of attacks.

Also, publicly trusted certs are available for extremely low cost these days.

Comment 50

[Greg Colyer]

I had simply only just noticed that this bug was apparently resolved, 12 years ago, based in part on an assumption about the resolution of bug 31273, which only happened 2 years ago, and that this assumption may have turned out to be false. (Regarding the timing, in a similar vein I just verified that bug 348045 was fixed, a year ago, 11 years after first reported! Maybe both the fix and my verification could have been quicker; but better late than never!)

Yes, other parties should fix their problems too, but this bug is about how Mozilla helps its users in a given situation. If it still appears to claim (in its messages or by inflexible behaviour) that in the above scenario A is valid and B is not, then this bug should be reopened, and reassigned if appropriate. Thanks for your past work though!

Comment 51

[Greg Colyer]

Sorry, that reference to 31273 should have been bug 312732.

Incidentally (since I'm replying anyway), I'm not currently in a position to retest the scenario easily myself, which is why I say "If" above.