447847 - Impossible to add SSL exception for duplicate issuer+serialnum error

Status: RESOLVED WONTFIX

(Core :: Security: PSM, defect)

Description

[aethergoth]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Please read this to the end; the problem is not the same as the many other certificate-warning-related reports/complaints.

Many desktop apps & services include HTTP front-ends.  Because the IP address the app runs under is not known until someone begins using it, it is impossible to include an authority-signed certificate with the program.  Regular users cannot possibly be expected to generate their own certificate.  Encryption is required, so the only option is for the app to create a self-signed certificate.

When Firefox 3 visits the embedded webserver, users are presented with a very obnoxious message.  I gather this is meant to prevent phishing, which is a nice goal, but seriously, it mostly just convinces people to switch to a different browser.  But okay, let's assume that annoying the hell out of users trying to visit legitimate sites is a feature.  There are still several problems:

First, sometimes there is an 'add an exception' link at the bottom of the page, sometimes there isn't.  Sometimes it's a link, and sometimes it's a button.  Sometimes, there isn't a link at all.  Sometimes, a dialog box pops up with the "sec_error_xxxx" message.  There is no consistency.  It seems to be related to the domain being visited (i.e. localhost v.s. an IP), and with a given URL it is always consistent.  But aside from that I can't see a pattern.

Since we can't predict how the error will appear, we need to plan for the worst and assume there is no link.  That means telling normal users to go to Tools > Options > Advanced > etc.  Again, I really hope you realize that this only convinces users to either switch to a different browser, or use an app without SSL, thus decreasing their security.  But hey, they can theoretically reach that UI, so fine.  The real problem is in the 'steps to reproduce' section.

Reproducible: Sometimes

Steps to Reproduce:
1.  HTTP server A (localhost) has self-signed cert A, issued by X with serial Y
2.  HTTP server B (some_ip) has self-signed cert B, issued by X with serial Y

These are two separate installations, but since it's the same app generating the certificate, it of course has the same issuer and serial on the self-signed cert.  There is no other way to do it.

3.  I visit server A, and manually add an exception for its cert
4.  I visit server B, and try to add an exception.  I click "get certificate"...
Actual Results:  
Upon clicking "get certificate" for server B, I get this error dialog:

An error occurred during a connection to <IP REMOVED>.

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

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

(Error code: sec_error_reused_issuer_and_serial)


So it is *impossible* for me to visit both servers at the same time.

Expected Results:  
Since I've gone through a huge amount of inconvenience just to get to that screen, I sort of hoped it would do what I asked, and add the exception.

I'd classify this as "a major feature is broken" because it is flat-out impossible (not just 'difficult' but impossible) to visit a legitimate page using Firefox.

Comment 1

[Johnathan Nightingale [:johnath]]

You are describing several problems here and while I appreciate your warning at the beginning, most of them are indeed covered by existing bugs.

(In reply to comment #0)
> First, sometimes there is an 'add an exception' link at the bottom of the page,
> sometimes there isn't.  Sometimes it's a link, and sometimes it's a button. 
> Sometimes, there isn't a link at all.  Sometimes, a dialog box pops up with the
> "sec_error_xxxx" message.  There is no consistency.

The structure of the page is consistent (a link which expands an extra information section with an "Add Exception" button) except that there is a bug where it sometimes displays the fallback error dialog, and it shouldn't.  That is bug 431712.  Absent that bug, the experience for typical broken cert scenarios should be consistent in all cases.

> Since we can't predict how the error will appear, we need to plan for the
> worst and assume there is no link.  That means telling normal users to go to
> Tools > Options > Advanced > etc.  Again, I really hope you realize that this only
> convinces users to either switch to a different browser, or use an app without
> SSL, thus decreasing their security.  But hey, they can theoretically reach
> that UI, so fine.  The real problem is in the 'steps to reproduce' section.

You should not feel it necessary to advise your users to follow that route - even in the case of bug 431712, the error page is *also* displayed.  The error page with the add exception link is always shown in cases where an exception can be added -- however duplicate serials are a different problem.

I understand that you are trying to be helpful, and I appreciate that, but lecturing people on the assumption that you've thought about this problem longer and harder than they have is unlikely to engender the kind of forward progress you're (presumably) looking for.

> Steps to Reproduce:
> 1.  HTTP server A (localhost) has self-signed cert A, issued by X with serial Y
> 2.  HTTP server B (some_ip) has self-signed cert B, issued by X with serial Y
> 
> These are two separate installations, but since it's the same app generating
> the certificate, it of course has the same issuer and serial on the self-signed
> cert.  There is no other way to do it.

This is the crux of your problem - not other things like bug 431712.  This is a hard-stop failure.  The combination of issuer and serial must be unique, since that is, by RFC, the way to identify a certificate.  That is why you aren't seeing the opportunity to add an exception.

I'm confused by your statement that "since it's the same app generating the certificate, of course it has the same serial" and your suggestion that there's no other way to do it.  Most applications that use this pattern generate a random number for the serial, or use some calculation based on the date, or munge the issuer; there are many ways to make the chance of duplication vanishingly small.

The expectations of the RFC language around uniqueness of the issuer/serial pair are spread throughout our codebase.  bug 219980 is concerned with making the error message clearer about why this is a problem, but at the end of the day the app is generating certs that can't be kept in the same database without breaking reasonably fundamental principles of SSL.

If the app you describe was generating certs with parse errors, you wouldn't file bugs here because it would be pretty clear that the solution was to fix the app's cert generation.  It turns out that instead, the app is generating certs which parse correctly, and could work fine in certain restricted environments, but do not work on the open internet, where multiple instances might be visited by the same user.  Without meaning to sound dismissive, we are profoundly unlikely to change our crypto assumptions to accommodate that.

Comment 2

[Johnathan Nightingale [:johnath]]

Bob/Kai correct me if I'm wrong, but I believe that, other than the parts which duplicate other bugs, this is WONTFIX.

Comment 3

[aethergoth]

I'm sorry for my tone, but I've spent a considerable amount of time trying to find work-arounds, and browsing through many other support tickets.  In every case there is a complete refusal to acknowledge this as a problem.  This is very frustrating when my inability to navigate to a page I want to reach is, by definition, a problem.

Perhaps it would be better for the app to mess with the issuer (although that is likely to scare off users even more), or use a large random serial number.  The fact is, it doesn't, and I can't do anything about that.  I know the site is legitimate, but I cannot get there, because my web browser insists that it knows better.

My concern is not with the fact that this throws an error, but that there is no way around the error.  The entire purpose of the 'add exception' page, as I see it, is to override the default behavior, and it isn't doing that.

Comment 5

[Ashley Black]

I concur with David Schnur. This is a real pity that this is a WONTFIX.
What is needed to be understood here, is that the real world is not RFC compliant all of the time. 

Maybe my understanding is not all that great, but what can't FF offer to replace the certificate FF already has indexed with the current one.

Comment 7

[tim.pelling]

I agree with Ashley's comment - it is a pity that this is marked WONTFIX.

The behavior has started impacting my ability to use Firefox to access h/w mgmt interfaces at work since upgrade to v3.5 (previous versions didn't exhibit this behavior in my scenario).

i.e. from my perspective changes in v3.5 "retrograde" existing functionality

Only viable real-world workarounds; use a different browser, maintain two versions of firefox - neither of these approaches are commensurate with the assumed goal of this project - proliferation of firefox as a browser.

Comment 8

[Johnathan Nightingale [:johnath]]

Tim - might it help at all to add your exceptions as temporary, instead of permanent, so that at least you do not get the error between browsing sessions?  I appreciate that people in admin roles often have to interact with large numbers of these things one after another, so this may not help. But given that it's excpetionally difficult to deal with certificates that are broken in this way, I thought it might make your life a little easier?

Comment 9

[tim.pelling]

Yes; perfectly acceptable to go through a warning/confirm-cycle every time - I expect you wouldn't want to allow people to mistakenly permanently accept a bad-certificate exception for an internet site and never subsequently warn them about it (for example).

Are you saying that this is an already feasible workaround? 

I've not been able to work out how.

Comment 12

[stefan.thieme]

I do understand that issuer+serial are in conflict with some issuer+serial in my browser cache.
If only I could determine which other site the conflicting certificate belongs to, would already help in resolving the issue on the server side.
Currently I only know there is a conflict, but not both / other conflicting certs and therefor have no option to solve it administratively.
In the past I would at least get the information which certificate the current side is presenting.
But since the SSL connection is restricted by the error, not even that information is available.
I have to resort to openssl s_client and other tools to research and resolve it.