Closed Bug 659736 Opened 13 years ago Closed 10 years ago

No way to add a security exception - "This site provides valid, verified identification. There is no need to add an exception."

Categories

(Core :: Networking: Cache, defect)

Product:
Core
Component:
Networking: Cache
Platform:
x86_64
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: rom, Assigned: avih)

References

(Depends on 1 open bug,
URL
)

Details

(Whiteboard: [workaround in comment 64][bugday-2011-05-27])

Attachments

(12 files, 1 obsolete file)

screenshot of the bug
96.38 KB, image/png
Details
ssl certificate
1.68 KB, application/octet-stream
Details
Screenshots of successful and failed attempts
320.28 KB, application/octet-stream
Details
Firefox 10 self-signed cert issue on Mac
38.51 KB, image/png
Details
No "Add exception" button
22.91 KB, image/png
Details
Firefox-659736-cert-error.zip Six screen shots showing the issues around the problem.
356.81 KB, application/octet-stream
Details
bug659736.v3.debug-info-patch.patch
11.05 KB, patch
Details | Diff | Splinter Review
logging-on
4.01 KB, patch
Details | Diff | Splinter Review
Still unable to access my router in FF 33.0a2 (2014-09-02).
140.07 KB, image/png
Details
Unable to add an exception for my router in 33.0a2 (2014-09-02).
130.31 KB, image/png
Details
photo.JPG
771.66 KB, image/jpeg
Details
Secure-Connection-Failed-FF-32.0.jpg
148.00 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

When I go to my page (https://rom1v.com/webmail), it says the certificate is not recognized (normal, it's my own). I have a button "add an exception", I click, and it says my certificate is valid. So I cannot add the "security exception". And I cannot access my site either…

See attached screenshot.

Reproducible: Always
Attached image screenshot of the bug — 

    
    

    
  
Duplicate candidates:
Bug 457573
Bug 545606
Bug 552976
Bug 654846
Summary: No way to add a "security exception" → No way to add a security exception - "This site provides valid, verified identification. There is no need to add an exception."
Whiteboard: [dupeme]
Version: unspecified → 4.0 Branch

    
    

    
  
Can you check in Option -> Advanced -> Security -> View certificates -> Servers if you already have an exception for this server? If yes, please post its details.

    
    

    
  
@aceman:
I had an exception for this server, but I deleted few days ago (but it didn't solve the problem).

To be more precise, this domain was hosted on a computer which died recently, I now host it temporarily on my laptop (so the certificate for the domain has changed).

Another point (don't know if it's important), the domain is now on the same host as my firefox (so it is like "localhost").

    
    

    
  
Even if you had an exception, then FF shouldn't ask and should show the site. It seems there is no domain in the certificate, it just has 'ubuntu'.

For me, FF allows to store the exception normally and then shows the site fine at each visit. Have you checked the certificate manager as I wanted? What are the details of the exception.
Whiteboard: [dupeme] → [dupeme][bugday-2011-05-27]

    
    

    
  
You need to generate your certificate with a CN that includes "rom1v.com", not just "ubuntu".
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID

    
    

    
  
OK, maybe the default certificate on ubuntu desktop does not include a domain.

But don't you think there is still a bug ?
Firefox should give the possibility to ignore that imo.

    
    

    
  
I filed a similar Bug 654846, and was hoping there'd be something in common between our systems that we could identify as the cause of the issue, but my issue spontaneously resolved a few days ago (I don't know if they changed something on the server in question - it was work-related, so I couldn't provide the link), and I'm able to access the website in this bug report with no problems.

However, I do consider it a bug. Access was entirely blocked off in Firefox, and yet other browsers had no problems.

    
    

    
  
I filed a similar Bug 654846, and was hoping there'd be something in common between our systems that we could identify as the cause of the issue, but my issue spontaneously resolved a few days ago (I don't know if they changed something on the server in question - it was work-related, so I couldn't provide the link), and I'm able to access the website in this bug report with no problems.

However, I do consider it a bug. Access was entirely blocked off in Firefox, and yet other browsers had no problems.

    
    

    
  
Hi,
Please Re_Open this bug, this really valid.

I can't add exception for expired certificate.
The CN of the cert is correct.

    
    

    
  
Then provide the URL of the site with the problem certificate.

    
    

    
  
Unfortunately I can't provide the URL. It is internal use only.
BTW.. It works correctly on Firefox 3.6. I have encountered it in 4.0.1 

Head of Certificate is:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 626457 (0x98f19)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddress=support@cacert.org
        Validity
            Not Before: Dec  6 18:29:51 2010 GMT
            Not After : Jun  4 18:29:51 2011 GMT
        Subject: CN=devtools.domain.com

    
    

    
  
I think CA Cert root authority cert is not shipped with Firefox by default. Did you have to add it manually?

    
    

    
  
I didn't add CA root Cert manually. Also I added it cert as exception last time.

This bug is not reproducible if you try to add expired cert for the first time (I have verified it on other firefox instance), this seems to occurs only if you added Cert to security exception and after that Cert became expired.

    
    

    
  
Good hint. Let's look into that.
Rom, was your certificate on https://rom1v.com/webmail expired? It looks like you created a new one valid from 1.6.2011 now.

    
    

    
  
@aceman : yes I created a new one (instead of the default ubuntu snakeoil) to workaround the problem…

    
    

    
  
I just reinstalled my server tonight, so the certificate has changed again. And there is the bug again.

But I think this is a problem of certificate change, not certificate invalidity: when I click on "show" the certificate, it gives as name the name of my old machine (the first I added an exception in firefox), which does not exist anymore.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

    
    

    
  
Ok, I'll check also that theory. I hope I have your old (ubuntu) certificate stored as exception on my test machine.

    
    

    
  
Sorry, can't reproduce. I have done this on my https://localhost server:
1. created a new certificate (CN not matching the 'localhost' name) valid for 1 day, self-signed.
2. visited the site immediately while cert was valid and added the exception.
3. waited for 1 day where the site worked fine without warnings.
4. on the 2nd day visit, got a warning about expired cert.
5. no problem, I allowed the exception (for the same cert!) and site worked.
6. created a new valid self-signed certificate for the server.
7. visited it, warning -> new exception.
8. even put back the old expired cert -> warning -> new exception.

I got no problems. Every time I was allowed to create the exception and got to the site. So, what am I missing? This was on FF5.0beta.

    
    

    
  
I believe this to be a DUPE of bug 545606.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → DUPLICATE

    
    

    
  
It cannot be a dupe.  Bug 545606 is about the incorrect wording in the add exception dialog when you have a working exception.  Any case in which the add exception dialog thinks the cert is good but the PSM AuthCertificate and BadCert hooks think it is bad is a different bug.  To put it another way, fixing bug 545606 might make the dialog show "Exception Already Exists" instead of "Valid Certificate" in the case discussed here but would not change the fundamental problem of being unable to reach the site.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

    
    

    
  
If you can't initially add the exception for a certificate which is reported "Valid" then you are right, this is a different bug. However, if you already have the exception in place, this is the same bug. Please clarify.

    
    

    
  
(In reply to comment #23)
> However, if you already
> have the exception in place, this is the same bug.

No... Bug 545606 is about subdividing "acceptable" (currently mis-worded as "valid") into "valid" and "matches existing exception".  This bug is about a case in which the add exception dialog thinks a cert is acceptable (and thus disables the button) but the PSM hooks think it is not, and as a result it is impossible to reach the site.  Whether the add exception dialog says "valid" or "matches existing exception" is beside the point of this bug.

    
    

    
  
Yes, as you can see I have commented in both bugs and also decided they are not dupes.
Bug 552976 probably is dupe of this, bug 457573 is not sure. However 545606 is not.

    
    

    
  
"But I think this is a problem of certificate change, not certificate invalidity"

I can confirm this : I launched firefox with a new profile (firefox -ProfileManager, then created a "test" profile), and the bug disappeared. I switched back to my default profile, and I the bug reappeared.

I thing the conditions are :
- the certificate name don't match the server name (default certificate is generated using hostname, rom-server for me, while the website is rom1v.com) ;
- this certificate has been accepted by firefox ;
- the certificate has been replaced on the server for the same server name (rom1v.com), whatever the certificate name is.

In that case (I guess, not sure the case is correct), firefox does not manage correctly the security exception.

    
    

    
  
Is this behaviour reproducible at all using the lastest Firefox Nightly?
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

    
    

    
  
Workaround :
- Backup cert8.db : cp ~/.mozilla/*.default/cert8.db{,.backup}
- Execute : firefox -ProfileManager
- Create a new profile ("test")
- Close firefox
- Copy ~/.mozilla/*.default/cert8.db to ~/.mozilla/*.test/cert8.db

Then it works.

    
    

    
  
Sorry, the last line should be :
- Copy ~/.mozilla/*.test/cert8.db to ~/.mozilla/*.default/cert8.db
(of course, copy the clean cert8.db to override the old one)

    
    

    
  
This is happening to me on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

I have an embedded device (card access controller) with a web GUI. It uses a self-signed cert. I was able to get to it fine until after I updated its firmware *and* restarted Firefox. At that point, I now get a prompt that the certificate is not trusted because it is self-signed, but when I try to add an exception, it says it's valid. Same as the attached screenshots. Something is getting confused in some part of certificate validation. Assigning it to the security component in case this is a symptom of something worse going on.
Component: General → Security
OS: Linux → All
QA Contact: general → firefox

    
    

    
  
I can confirm this is happening with a self-signed certificate in 5.0 on Win7.  If reopening the tab, Firefox says 'problem with this site' and you can press the button to add an exception.  That dialog says the cert is valid when you get it and leaves the Permanently Store checkbox and Confirm Security Exception button disabled.

Also, it will not permit me to add an exception from Options | Advanced tab, saying it is a valid certificate when it is nothing of the sort!

Urghh,
SSF

    
    

    
  
Also, it is interesting that the Certificate Viewer knows that the cert is bad:

"Could not verify this certificate because the issuer is not trusted."

SSF

    
    

    
  
Can you provide the URL where you can see it?

    
    

    
  
I'm having the same issue with https://mail.google.com/mail/  It was working fine till last week. 
When I visit the url, it says "This Connection is Untrusted". But when I try to add an exception it says "This site provides valid, verified identification. There is no need to add an exception"

There are no servers currently added in my certficate manager.

    
    

    
  
(In reply to comment #34)
> I'm having the same issue with https://mail.google.com/mail/  It was working
> fine till last week. 

What version of Firefox are you using Mridul? Gmail works fine for me on Mozilla/5.0 (X11; Linux x86_64; rv:7.0a2) Gecko/20110711 Firefox/7.0a2

    
    

    
  
(In reply to comment #35)
> (In reply to comment #34)
> > I'm having the same issue with https://mail.google.com/mail/  It was working
> > fine till last week. 
> 
> What version of Firefox are you using Mridul? Gmail works fine for me on
> Mozilla/5.0 (X11; Linux x86_64; rv:7.0a2) Gecko/20110711 Firefox/7.0a2

Version 4.0. I'm unable to update as it is at work.

    
    

    
  
I upgraded to 5.0.1 and the issue is still there. This is what I see when I go to https://mail.google.com/mail/

----------
"You have asked Firefox to connect
securely to mail.google.com, but we can't confirm that your connection is secure.
 Normally, when you try to connect securely,
sites will present trusted identification to prove that you are
going to the right place. However, this site's identity can't be verified."
----------

This is what I see when I click the "Add Exception.." button
-------
Valid certificate
The site provides valid, verified identification. There is no need to add an exception.
-------

The "Confirm Security Exception" button is inactive and cannot be clicked. 

I'm behind a proxy. Please tell me if you need more information.

    
    

    
  

      
      
      
      

        Attached file
          
        ssl certificate
        — 
      

    


  
It seems that I have the same problem. I attached certificate. This certificate cannot be added to exception.
I hope this will help to reproduce the bug.

    
    

    
  
@Evenij are you behind a proxy as well? I'm unable to reproduce this with GMail locally. However, I'm not behind a proxy.

@Mridul interested to see if other users behind your proxy are experiencing similar issues with the same version of Firefox, other versions of Firefox, and other browsers.

    
    

    
  
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #39)
> @Evenij are you behind a proxy as well? I'm unable to reproduce this with
> GMail locally. However, I'm not behind a proxy.

Nope.
I reproduce this bug without proxy.
I attached self signed certificate, not GMail certificate.
Company where I work generate self signed certificate for mail server every day. I have to "Confirm Security Exception" when it happens. One day I couldn't connect to mail server because the new certificate (attachment 549592 [details]) couldn't be added to security exception.

    
    

    
  
I have similar issue - with current Firefox 6.0 (under 32-bit Windows 7, pl_PL localization).

Here's how I managed to "create" and then solve (actually make a workaround) my issue.

I have a few devices that offer their management interface over HTTPS, with self-signed certificates.

Usually I add an permanent security exception, which works as expected.
Yesterday, for one of devices, I added a temporary security exception - which worked at that moment.

Today (computer was turned off for the night) I was trying to connect to this device's management interface and the problem occured.
(FF suggests adding security exception - as expected, yesterday's exception was temporary. When I try to add it - FF states that there is no need to add an exception, because certificate is valid -- so, I can't access device's management interface)

I was thinking that the same certificate was used for several devices and that is causing the problem. So I deleted all the certificates stored as permanent exceptions for these devices (options->advanced->encryption->show certificates->servers). After that - I was unable to log-in to all the devices, which previously had permanent exceptions and worked fine.

Workaround which worked was "about:permissions" and "forget this page" (for all the pages which caused trouble). After that - I was again able to add security exception for these devices.

    
    

    
  
It would be great if someone on this bug could provide a test page which demonstrates the bug; or at least detailed steps to set up an environment where this occurs. Until such time, I'm afraid this bug will remain UNCONFIRMED.

    
    

    
  
I'm able to reproduce consistently situation described above (comment 41). With several different FortiGate UTM appliances with stock certificates for their management web UI.

Connect to web management, accept exception permanently, delete exception. Connect to web management once again - unable to accept exception, because FF says certificate is valid and there is no need to add an exception.

Unfortunately, I wasn't able (at least yet) to create similar certificate which, served by my Nginx server, would be treated in the same manner by Firefox. With my certificate under nginx - everything works fine.

    
    

    
  
Same issue here. It's on an F5 BIG-IP load balancer appliance, which had a self-signed certificate with an added exception (which worked fine). The system broke and was replaced/reinstalled (now with a new self-signed certificate). When I access the management IP (https://192.168.x.y) it gives me the warning that the site is untrusted and gives me the standard error page where I can click to add an exception, but when I do so the dialogue box says the site is already trusted so there's no need to add any exception.

I've cleared out every single saved exception in the preferences, and tried to import a new cert8.db from a clean profile, but nothing helped.

Tore

    
    

    
  
I found a workaround moments after I posted comment #45, of course...

1) quit firefox
2) rm -rf ${PROFILEDIR}/Cache
3) start firefox

...and now I can add the necessary exceptions again.

Tore

    
    

    
  
@Tore can you provide us with a live test case so we can confirm this bug? We are still unable to reproduce this on our end.

    
    

    
  
Anthony, I'm afraid I cannot provide you with the test case I originally stumbled across as the unit that had the original certificate for which there was an exception is defective and in any case returned to the manufacturer.

However, I'll try to see if I am able to come up with another reproducible test case some other way, and will let you know if so.

Tore

    
    

    
  
I think I'll be able to provide you with access to our demo FortiGate unit after 27.08.2011.

For now, I've exported certificates from this FortiGate and used them in my Nginx server. It seems there is no problem here. I can add, remove and add again security exceptions for site that uses certificate exported from FortiGate (the same certificate that causes troubles on FortiGate).

My problem seems only reproducible on these FortiGates.

    
    

    
  
I'm so glad to have found this post as I've been wrestling with this issue for a long time.  We use self-signed certificates with some embedded network devices that we make at my company, and we encounter this issue frequently.

I was just able to reproduce a very clear test case.  The problem we're experiencing seems to happen when we're using FF to access the device's webpage, we create a new certificate on the device (such as when reinstalling the embedded OS), and then we try to access the device's webpage again with FF.  FF won't let us "add an exception" the second time around after the certificate has changed.  My guess is that FF is referencing an old cached certificate when you try to "add an exception".  Thus it tells you that "there is no need to add an exception" because it thinks it's already there.

I can't easily provide a live test for others to use, though I have written up the steps and have taken screenshots which I'll try to post.  Hopefully this helps narrow down the problem.


Setup:

Server - Debian with Apache 2.  Self-signed certificates made with openssl, CN is "Sample Certificate".  Hostname is vestal.mri.local, 10.0.200.56 

Client - Windows XP SP 3 laptop with Firefox 6.0.2


Part I:
First, successfully connect to the webserver:

- create new self-signed ssl cert on web server, and start web server
- Start FF 6.0.2
- Clear cache in FF
- Use Certificate Manager to clear references to the webserver from both the "Servers" tab and "Authorities" tab
- Point FF to https://vestal
- FF will alert that "This Connection is Untrusted"
- Click "Add Exception"
- The "Confirm Security Exception" button will be available
- Click "Confirm Security Exception"
- *** SUCCESSFULLY ALLOWS ACCESS ***


Part II:
Now cause the 'problem':

- stop web server
- create new ssl cert with the same info (CN, OU, etc)
- start web server
- point FF to https://vestal
- FF will alert that "This Connection is Untrusted"
- Click "Add Exception"
- The "Confirm Security Exception" button will be grayed out.  Text will say "site provides valid, verified identification"
- *** FAILS TO ALLOW ACCESS ***
- For reference, click the "View..." button and copy the information that you see.  This will be used later


Part III:
I think this next part helps to narrow down the cause of the issue:

- open a new tab and point FF to https://vestal.mri.local
- FF will alert that "This Connection is Untrusted"
- Click "Add Exception"
- The "Confirm Security Exception" button will be available
- Click the "View..." button
- Note the details displayed about the certificate.  They will be different than in Part II
- Close the certificate-details windows
- Click "Confirm Security Exception"
- *** SUCCESSFULLY ALLOW ACCESS"
- https://vestal still inaccessible due to problem in Part II


It would appear the process of 'adding an exception' is referencing a cached certificate in Part II, rather than the current ticket.  Part III shows you the details of the current ticket.



On a side note:

I ran a test where I put an entry in my local hosts file:

10.0.200.56	foobar foobar.local.net

This is the same IP as the webserver that I used for the tests, but allowed me to reference it with a different name.  Oddly enough, the certificate problem did NOT happen when I used "https://foobar" in place of "https://vestal" in Parts I and II.

    
    

    
  


  
Three screenshots included:
Part I - shows the original successful attempt to add an exception
Part II - shows the failure to add an exception, after the server changed certificates.  FF displaying wrong cert data.
Part III - shows a successful attempt to add the certificate, after the server change certificates.  Shows correct cert data (different than in Part II)

    
    

    
  
I have run into this bug with Aurora 11.0a2 in a similar context as in comments #30 and #50 : a hardware device with embedded OS with a web GUI that generates a new self-signed certificate after a new firmware version has been flashed to the device. After a firmware flash and a new certificate getting generated, Firefox now complains about untrusted connection, but does not allow creating the needed exception.

Using the workaround mentioned in comment #50 Part III works: I could not create an exception directly for the previously used address https://192.168.1.1, but I was able to create an exception for device's DNS name https://openwrt

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a2) Gecko/20120109 Firefox/11.0a2 ID:20120109042006

    
    

    
  
Interestingly, the workaround proposed at https://bugzilla.mozilla.org/show_bug.cgi?id=457573#c6 also worked:

Killing the Firefox process forcefully enabled me be create the exception for the original address on the next run. Apparently the crash/kill invalidates some internal exception status cache tms., and Firefox stops erroneously saying that it already has a valid certificate.
 
Bug #457573 is most likely a duplicate of this same issue. 

Somebody with edit rights should change this bug from 4.0 branch to more generic.

    
  
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → DUPLICATE

    
    

    
  
oops. fixing duplicate bug number.
Whiteboard: [dupeme][bugday-2011-05-27] → [bugday-2011-05-27]

    
    

    
  
I am not sure yet that resolving bug 660749 will fix this issue, so I am marking this bug as depending on it, instead of being a dupe of it.
Status: RESOLVED → REOPENED
Depends on: CVE-2011-0082
Ever confirmed: true
Resolution: DUPLICATE → ---

    
    

    
  
Kai Engert (:kaie) wrote in bug 660749 comment #6"
> Workaround to add the exception: Clear the cache.
> 
> Go to: 
>   Tools
>   Clear recent history
>   select "everything"
>   keep "Cache" checked, uncheck everything else
>   clear now
> 
> After that, you should be able to add the exception.
> Can you confirm the workaround helps you?
Whiteboard: [bugday-2011-05-27] → [workaround in comment 64][bugday-2011-05-27]

    
    

    
  


  
Reproduced on Firefox 10.0.2 (Mac OS X 10.6.8), occasionally throwing ssl_error_rx_record_too_long.

    
    

    
  
Couldn't reproduce on 11.0 (Mac OS X 10.6.8).

    
    

    
  
It really looks to me to be a cache problem.  I was having the same problem as comment #37.  What I saw that was interesting is when I tried to view the certificate before validating it, the Validity fields were wrong.  I was getting the "Issued On" date from the old certificate, but the "Expires On" date was from the new certificate.

Clearing the cache allowed me to add the certificate.  This is on Firefox ESR 10.0.3

    
    

    
  
Just witnessed this with 12.0 on OS X.

    
    

    
  
Same problem here.

Workaround which worked was "about:permissions" and "forget this page" (for all the pages which caused trouble). After that - I was again able to add security exception for these devices.

This solution worked for me.

    
    

    
  
The same problem for m.e

Workaround worked from comment #6.

    
    

    
  
Same problem.  Using Aurora 14.0a2 (2012-05-18) windows
Added an exception for site, came back and got the warning screen followed by the valid cert message in the bypass screen and no way to access the site.
Could not find the certificate in the certificate stores to delete (odd).

Comment 70: "about:permissions"/"forget this page" allowed be to access the site again.

    
    

    
  
Can we please refrain from any more "I have the same problem" comments on this bug? It's not actually helpful to driving toward a solution. If you are experiencing the same problem, please just click the "vote" link beside the Importance field in this bug report. Please only comment on this bug if you have something to contribute to the solution. Thanks.
No longer depends on: CVE-2011-0082
Depends on: CVE-2011-0082

    
    

    
  
Particular example of this bug is in using 2 devices in active-passive high availability mode where they share the same IP address but either device may be active. You can add add an exception for *one* of the devices, however if the other becomes active (with a different self-signed certificate) you are unable to access the site or add an exception.

    
  

          tracking-firefox14:
          --- → ?

          tracking-firefox16:
          --- → ?
Flags: sec-review?

    
    

    
  
Firefox 14 is not going to get any changes before 15 ships in a week.

          tracking-firefox14:
          ? → ---

    
    

    
  
Soenke: why did you nominate this bug for a security review? Just want to make sure we have the reasons understood to make the correct assignment/choices.

    
    

    
  
The bug forces me (and most likely other users) to disable and/or workaround recommended security functions of Firefox (at least up to 14) in order to use Firefox for all pages I (respectively other users) want to access.

As workarounds have the (bad) smell of hidden tipps and tricks sections of so called expert computer magazines some users will run without thinking about side-effects and other dependencies into higher risk of securtiy exposure. 

Therefore this might erode the trust level of the community into the security-abilities of Firefox. 

This makes me recommending to at least check the various workarounds published in here (already identified duplicates and not yet identified duplicates) in order to highlight risky workarounds. 

Anyways, the long history of this bug (at least since 2008) and the comparably high number of bugs with almost the same content should put definetely more attention to this bug. It is not only a convinience problem as suggested in some comments.

    
    

    
  
Since there is no technical change to Firefox, but a set of workarounds to get pages to avoid security warnings that should be present and thus taken at ones own risk there is no need for a security review. Our best recommendation is to not circumvent the normal security and use certificates on sites as they should be.

As this also has no patch I am removing the tracking flat for firefox 16. These flags are meant to be set on patches for landing in a release, as this has no patch this is not an appropriate use of the flag.

          tracking-firefox16:
          ? → ---
Flags: sec-review?

    
    

    
  
Wow, ancient bug, and it's still in 16.0.
I can't believe that nobody is able to figure out and fix the cause of this problem ... after all, either move the comparissons that check for validity of the certificate to the "add exception" code part, or the other way around ... IMHO, it should be this way around: if I have an exception, and the cert isn't what it used to be, then automatically drop the exception and allow for the user to check it and then add a new exception ... 
What can we do to get this bug higher up on the todo-list? IMO, this is not only an annoyance, but a security issue, and makes FF unusable in many situations concerning self-signed certs ...

    
    

    
  
The same problem.
When clicking 'Get Certificate', it's already Valid Certificate.
In 'View...' it says: Could not verify this certificate for unknown reasons.

Certificate Version: 3
Serial Number: 55:0D:23:02:00:00:00:00:44:33
Certificate Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Validity Not Before: 05/30/2011 11:17:36 (05/30/2011 09:17:36 GMT)
Validity Not After: 05/29/2013 11:17:36 (05/29/2013 09:17:36 GMT)
Subject Public Key Algorithm: PKCS #1 RSA Encryption
CRL Distribution Points: http://certinfo-http.xxx.com/crl/Server_CA_Production_1.crl

Authority Information Access:
Not Critical
CA Issuers: URI: http://certinfo-http.xxx.com/aia/Server_CA_Production_1.crt
OCSP: URI: http://certinfo-ocsp.xxx.com:53417/
Certificate Policies: 2.16.756.5.4.2.1.2.13.1.2

Because I'm behind the proxy, and these Certificates are for intranet only, each time when Firefox uses new hosts, I've to add them into 'No Proxy' list.
So when I've tried to access manually this link with .crt file, I figure out that I have to add another proxy exception host (I'm not sure if it's even requested by Firefox).
But even then, it still doesn't work.
But it could be some kind of hint.

    
    

    
  
P.S. Still reproducible in Firefox 16.0.2 (Ubuntu)

    
  
Depends on: 810085

    
    

    
  
I have a similar issue:

Our IIS has two certs, one for internal use and another for external use. If I add one of them, it works great.

If I try to visit the page from external after create an exception rule for internal, it want to add it again and displays:

"There is no reason to add an exception rule".

Win7 32-bit and FF 16.0.2

Is my issue in reference with this bug?

    
    

    
  
I found a similar issue with Firefox 18.0.1. Please let me know the details, I need to update to support investigation.

Thanks,
Vetri

    
    

    
  
I can shed some light on how to generate this defect.

Simply use a different cert with a host that has a pre-existing cert.

Here's how I did it.

URL in question: https://kvm_trac/svn/repos/

1. Host named kvm_trac, I created a cert called with the common name "trac". (make testcert SERIAL=1)
2. I configured apache with the cert and connected with firefox. 
3. When firefox told me there was a name discrepancy, I added the exception.
4. I then RE-CREATED the cert on the box, with the common name "kvm_trac". (make testcert SERIAL=1)
5. I reconfigured apache for the new cert, restarted the web server
6. I connected again via firefox, and was informed that the server connection was untrusted, but that the certificate was already trusted and verified and no exception was needed.

How I fixed it:
1. Manually delete the certificate for the offending host
2. Connect again and the server allowed me to add an exception.

URL tested was http://kvm_trac/svn/repos (using mod_dav and mod_dav_svn - not sure if they are relevant).

SVNPath was configured correctly for location /svn/repos

What was interesting, that while firefox refused to add the exception for the full URL, it claimed no errors when there was URI (https://kvm_trac)

Client:
Firefox: 18.0
OS: Fedora 17
Arch: x86_64
Desktop: KDE

Server:
Platform: KVM
Arch: x86_64
OS: Centos 6.3

    
    

    
  
Correction in prior comment - no error was detected when I had NO URI as shown above. Mis-quoted.

    
    

    
  
I take it back - still broken

I have managed to add an exception, but Firefox is STILL reporting a problem with the cert. But I can't add an exception because the cert has supposedly been "verified".

I am stuck on the security page.

    
    

    
  
Ok - so here it is boyz and girls. I had a symlink pointing to the original certificate, so that even though the cert was updated, apache did not see it which resulted in the Common Name not matching the URL hostname ( I noticed that updating the SERIAL # did not update the reported SERIAL # in the cert on the exception dialog). 

From this I have determined that the real problem in the cert was that the hostname (Common Name) did not fully match the hostname in the URL. I updated the hostname to a FQDN, removed the extra symlink releasing the delated cert, restarted apache, added the FQDN (kvm_trac.routerlogin.net) to my hosts file, and lo and behold it worked - it allowed me to add an exception AND continue past the warning.

The problem here seems to be that if the host name in the URL does not match the common name in the certificate, even after adding an exception, FireFox still refuses to access the page even though it is reporting that the certificate has been verified. Half an exception doesn't cut it. :)

I do not know if this is by intent, but an exception should be treated as such: The user has overridden the cert verification - let the user continue on.

    
    

    
  
Ok - so here it is boyz and girls. I had a symlink pointing to the original certificate, so that even though the cert was updated, apache did not see it which resulted in the Common Name not matching the URL hostname ( I noticed that updating the SERIAL # did not update the reported SERIAL # in the cert on the exception dialog). 

From this I have determined that the real problem in the cert was that the host-name (Common Name) did not fully match the host-name in the URL. I updated the host-name to a FQDN, removed the extra symlink releasing the deleted cert, restarted Apache, added the FQDN (kvm_trac.routerlogin.net) to my hosts file, and lo and behold it worked - it allowed me to add an exception AND continue past the warning.

The problem here seems to be that if the host name in the URL does not match the common name in the certificate, even after adding an exception, FireFox still refuses to access the page even though it is reporting that the certificate has been verified. Half an exception doesn't cut it. :)

I do not know if this is by intent, but an exception should be treated as such: The user has overridden the cert verification - let the user continue on.

    
    

    
  


  
Where did the "Add exception" button go???

    
    

    
  
I've just seen that on https://blog.mozilla.org (the certificat is valid for blog.mozilla.com).

    
    

    
  
I encountered this problem when accessing the web interface for a NetGear router.  I originally added the security certificate temporarily.  Then when going back to the site, I got the 'Untrusted Connection' screen as expected but the 'Add Exception' dialog claimed the certificate was valid.  I used the workaround from Comment 41 (thank you Jacek Politowski).

I am running Firefox 21.0 on Windows 8 with all updates applied.

    
    

    
  
DLink IP Camera. DCS-5222L. Same problem. Firefox 21.0 on Windows 7 64-bit. All up-to-date.

Google Chrome avoids this problem altogether, seemingly by not storing problematic certs at all. And Chrome runs so much faster than Firefox. I've been avoiding Chrome for some 3+ years now. I don't think I'll even be coming back to check on this Firefox bug report.

    
    

    
  
Thanks for this helpful comment, that's appreciated.

    
    

    
  
Exact steps to reproduce:

This happens when you have previously added an exception where only the domain name mismatches but the certificate itself is entirely valid.

The next time you visit the site you will not be able to add a permanent or temporary exception and cannot browse the site at all.

You can add a temporary exception if you enter Private Browsing mode.

    
    

    
  
(In reply to kurian from comment #99)
> Exact steps to reproduce

These steps are not "exact" enough. Please provide a proof-of-concept URL.

    
    

    
  
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #100)
> (In reply to kurian from comment #99)
> > Exact steps to reproduce
> 
> These steps are not "exact" enough. Please provide a proof-of-concept URL.

https://www.tatatele.in/broadband/

    
    

    
  
Tested with the latest Firefox Nightly 25.0a1 on Ubuntu 13.04 64-bit.

1. Load https://www.tatatele.in/broadband/
> Untrusted Connection warning page loads
2. Expand "I Understand the Risks" and click the "Add Exception" button
> Add Exception dialog appears but all buttons (except for Cancel) are disabled

At the very least we seem to have in internally reproducible case now. Thanks for this information @kurian.

Brian, does this give you any leads on what we could do to fix this issue?
URL: https://www.tatatele.in/broadband/
Status: REOPENED → NEW
Flags: needinfo?(brian)

    
    

    
  
This is indeed a bug.
Go to https://app.siscad.cadivi.gob.ve/STDC-Naturales/cadivi/principal

You get the "unstrusted" dialog and then add security exception
Then, in the add security exception window you get "this site provides valid, verified identification. There is no need to add an exception".

Tested on win8 x64, firefox 22.

In this case , the self signed certificate of that site expired yesterday 18th, triggering this bug. The bug itself is that the Add Security Exception feature is saying that the certificate itself is valid and isn't checking the expiration date itself.

Changing priority to MAJOR because firefox won't let you browse to the site.

I already have a saved exception to this site. If i delete it and try again i have the same problem.

There is obviously a discrepancy in the security validation between the first dialog (the "unstrusted" one) and the second (the add security exception one)

My bet is on the second, since if you try to add the exception manually (in Advanced...) you get the same issue.
Severity: normal → major

    
    

    
  
At least i can confirm that wiping the cache works

    
    

    
  
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #102)
> Tested with the latest Firefox Nightly 25.0a1 on Ubuntu 13.04 64-bit.
> 
> 1. Load https://www.tatatele.in/broadband/
> > Untrusted Connection warning page loads
> 2. Expand "I Understand the Risks" and click the "Add Exception" button
> > Add Exception dialog appears but all buttons (except for Cancel) are disabled
> 
> At the very least we seem to have in internally reproducible case now.
> Thanks for this information @kurian.
> 
> Brian, does this give you any leads on what we could do to fix this issue?

We need to fix CVE-2011-0082 and then this will be fixed.

Alternatively, and more simply, we can stop serving cached responses that had cert overrides when they were cached.
Flags: needinfo?(brian)

    
    

    
  
I recently upgraded to FF24 running on VMware Windows 7. Now I get the same error
which all of you are writing about. I tried a number of suggestions from this forum without any success.
The trouble is that my java code worked on FF23 but not on FF24.

Thanks,
Hamid Assous

    
    

    
  
Today I experienced this problem on Firefox 26 running on Mac OS 10.9.1 (I don't normally use Mac OS as I prefer to use operating systems that respect my freedom). By reading through the proposed workarounds in this thread (none of which actually worked for me), I managed to devise a workaround that does work on Mac OS:

1. From the terminal (on Mac OS):/Applications/Firefox.app/Contents/MacOS/firefox-bin -p
2. Create a second profile if you don't already have one (separate profile to the default).
3. Select that profile so that Firefox starts up using that profile.
4. Visit the site for which Firefox is exhibiting this bug - it should open the site, unlike the default profile.
5. Completely quit Firefox (CMD + Q).
6. Go the the terminal and change into the profile directory that is NOT your default (in my case it's something like: ~/Library/Application Support/Firefox/Profiles/ahfgdhye.TestProfile).
7. Output the contents of the file cert_override.txt.
8. Copy the line that contains the domain for which this bug occurs.
9. Add that line to cert_override.txt in your default profile (in my case it's something like: ~/Library/Application Support/Firefox/Profiles/aelljsci.default).
10. Now start Firefox using your default profile, you should now be able to accept self-signed cert for the site.

    
    

    
  
Would any developers be interested in tackling this for a bounty?

I'd happily chip in $5 to avoid using another browser whenever I deal with a load balancer.
Anyone else?

    
    

    
  
Brian, could you give pointers about how to fix this 3-year-old bug, so that maybe a contributor could do it?
Flags: needinfo?(brian)

    
    

    
  
This is a bug in the HTTP cache. The HTTP cache needs to validate the certificate for the cached entry. PSM provides an API for doing this: SSLServerCertVerificationJob::Dispatch. You can see how this is used in the function AuthCertificateHook in security/manager/ssl/src/SSLServerCertVerification.cpp:

    socketInfo->SetCertVerificationWaiting();
    SECStatus rv = SSLServerCertVerificationJob::Dispatch(
                     certVerifier, static_cast<const void*>(fd), socketInfo,
                     serverCert, stapledOCSPResponse, providerFlags, now);

The HTTP cache needs to do something similar. Note that currently the HTTP cache doesn't store all the information that is needed to re-validate the cached entry.
Component: Security → Networking: Cache
Flags: needinfo?(brian)
Product: Firefox → Core
Version: 4.0 Branch → Trunk

    
    

    
  
Note that the fix I described in comment 110 is the fix for bug 660749, which this bug depends on. So, basically, just fix bug 660749 and this bug--the primary cause of it, at least--should be fixed.

    
    

    
  
Is this bug still waiting for an STR?

If yes, then a URL (as requested in comment 100) would not be enough, since the issue manifests when:
1. You visit a domain X and add the exception (for e.g. self-signed cert).
2. Domain X changes its certificate to another which also requires an exception.
3. You visit domain X again and try to add security exception to the new certificate.

Step 3 fails. Since the STR involves visiting the same site/domain twice where the certificate has changed between the visits, providing a URL as an STR cannot work. The STR must include changing the server certificate between the visits.

I may be able to provide a zip with a small https server (for windows) and two certificates which can be replaced, which should help reproduce it.

Anthony, is a more detailed STR still required here?
Flags: needinfo?(anthony.s.hughes)

    
    

    
  
(In reply to Avi Halachmi (:avih) from comment #112)
> Anthony, is a more detailed STR still required here?

No, see comment 111. This bug is pending resolution of bug 660749.
Flags: needinfo?(anthony.s.hughes)

    
    

    
  
Had this problem on FF versions 25 through 28, and I believe prior as of today, still. Sigh. 
WORKAROUND/SOLUTION (I hope for all or most) until FF is patched:  So, a How-To Fix article has been published for it at http://technotes.whw1.com/computer-related/software/firefox/30-firefox-fix-to-no-exception-button-showing-when-invalid-ssl-certificate  I either am not familiar with this Mozilla Bugzilla interface or I don't have required access, and so if someone could edit the above at top to reference the article or this comment, feel free to do so, and it would be appreciated.  It should help save people the frustration and higher blood pressure I experienced.

    
    

    
  
(In reply to Anthony Hughes, QA Mentor (:ashughes) [Away until 2014-04-28] from comment #21)
> I believe this to be a DUPE of bug 545606.
> 
> *** This bug has been marked as a duplicate of bug 545606 ***

I do not believe this is a duplicate, since no exception option is what this report is about, and the other (54606) has an exception button or selection, regardless of other issues, and so IMO, 545606 should be crossed out as a duplicate relation.  Even if the core code is the same or responsible for both problems occurring.

    
    

    
  
(In reply to Kai Engert (:kaie) from comment #55)
> oops. fixing duplicate bug number.
> 
> *** This bug has been marked as a duplicate of bug 660749 ***

I do not believe this is a duplicate, since no exception option is what this report is about, and the other (660749) has an exception button or selection, regardless of other issues, and so IMO, 660749 should be crossed out as a duplicate relation.  Even if the core code is the same or responsible for both problems occurring.  I read through 660749 and to me they are clearly different.

    
    

    
  
I'm adding an incident to the pile too.

When attempting to connect to a D-Link NAS, I get the same looping logic.
1) "This connecion is untrusted"
2) "I understand the risks"
3) Press "Add Exception"
4) Under "Certificate Status" it says "Valid Certitiate" "This site provides valid, verified identification. There is no need to add an exception." the "Confirm Security Exception" button is grayed out.

Screen shots available at: https://app.box.com/s/33hzjsdwta5kuzrwzfov

I checked for the cert(s) in the certificate manager under "Authorities" and it is not there (had been deleted) and the "Servers" does not contain my d-link address/server as having provided a cert.

This is easily reproduced.

    
    

    
      
  

    
    

    
      
  

    
    

    
      
  

    
    

    
  
****. I found where to put the attachments. Will do so now.

    
    

    
  


  
These are the screenshots from my system while preparing to report comment 117

    
    

    
      
  

    
    

    
      
  

    
    

    
  
I think anyone who is NOT SEEING an Add Exception button or link early on, then should be posting to thread of bug 403220, and I think maybe report of bug 443972 is a duplicate of 403220 bug report.  

Anyone who DOES SEE an Add Exception button or link, may it be grayed out or not, but does not function as one would expect (such as indicating a cert is valid, when it is seen as invalid in a prior window or stage of code), then should post to any of the reports of bug 659736, bug 545606, and bug 660749, as I believe they are strongly related at the very least.

    
    

    
  
(In reply to Tech Notes from comment #125)
> I think anyone who is NOT SEEING an Add Exception button or link early on,
[..]
> Anyone who DOES SEE an Add Exception button or link, may it be grayed out or

Really? How many "me too" posts do we need in either thread? I've not gone through and counted on either one, but there are enough howtos in the threads to reproduce the bug reliably ... how difficult is it to locate the two comparisons that yield the "invalid cert" in the first and the "hey, you already confirmed the exception, so I won't let you do it again, even if it's a different cert now" result in the second case for someone who's familiar with the code?

    
    

    
  
(In reply to Garry Glendown from comment #126)
[...]
> how difficult is it to locate the two comparisons 
[...]

Well, that's great. So you're on top of this problem. Just let us all know when you've identified the problem. We're all waiting.

    
    

    
  
Please note the conveniently dropped part "for someone who's familiar with the code" ... but I do not want to start a discussion about that here, it's not the place ...
As someone who can not be described as being familiar with the code, I took a quick look, and would assume there ought to be some additional checks in the file exceptionDialog.js ... this file initializes the "add exception" button ("extra1") as disabled, and only enables it under certain conditions. 
In the function updateCertStatus, it is checked whether the boolean gBroken is set - otherwise the button remains disabled.
By default, gBroken is set to false in checkCert, but may be updated to true by either findRecentBadCert (which I assume will not trigger as it requires the negative test of the second part), or by badCertListener callback function. I assume that the function MSR_notifyCertProblem is not called due to the fact that the exception is present, even though the certificate does not match the previously found certificate ...
Anyway, at that point I'm somewhat at a loss as to where else to look ...

    
    

    
      
  

    
    

    
  
As a workaround you could use private browsing.

    
    

    
  
I have same issue as above .... Comment 117, but with Cisco ASA ASDM

I'm adding an incident to the pile too.

When attempting to connect to a Cisco ASA, I get the same looping logic.
1) "This connecion is untrusted"
2) "I understand the risks"
3) Press "Add Exception"
4) Under "Certificate Status" it says "Valid Certitiate" "This site provides valid, verified identification. There is no need to add an exception." the "Confirm Security Exception" button is grayed out.

I checked for the cert(s) in the certificate manager under "Authorities" and it is not there (had been deleted) and the "Servers" does not contain my asa as having provided a cert.

This is easily reproduced.

    
    

    
  
IMO, Firefox and no Internet browser should be making the decision for a user on what should or should not be allowed to have an exception made for.  I should always have the ability to add an exception. If that thinking was adopted, then this issue would not exist, since the choice would always be there.  

After all that was one of the big problems with Microsoft's Internet Explorer and other softwares, a while back, where they thought they knew better and forced decisions upon the users.  Now, things are opposite.  IE allows the exceptions under pretty much any condition, with warnings, I think, and FF is trying to make the decision for the user and force it upon the user.  Again, IMO, if such thinking, to force decisions upon a user, exists, then that attitude or thinking should stop, and it will lead to a more usable software, and more adopted usage of FF.

    
    

    
  
Dear "tech notes", 
The issue is that one part of firefox decides (correctly) an exception is required, and allows the user to make that choice. Then one step further, another part decides that adding an exception is not useful because the exception/certificate already exists. Technically also true, but the certificate has expired and needs new approval.

    
    

    
  
The following quotes are from bug 660749:

(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #50)
> This [bug 660749 - avih] is a bug in the HTTP cache. The HTTP cache needs ...

While this (In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #42)
> The difficulties in adding an exception due are now tracked in bug 659736.
> It seems very likely that fixing this [bug 660749 - avih] bug will fully fix bug 659736 ...

Adding an exception became a very real issue with heartbleed, since servers issued new certs while the users already had exceptions for the old certs, and then users can't visit the pages on relevant cases (self issued etc), because Firefox can't accept the new cert.

While the fix for 660749 may also fix this bug, bug 660749 is stalled for many years now due to what seems to be deeper issues and implications than this bug.

This bug _appears_ to be a simpler logic flaw:
Currently:
- The "Add exception" dialog doesn't allow adding an exception if _an_ exception already exists.

Possible solution:
- Same as before, but do allow adding the exception if the new exception is different than the old one (e.g. due to different cert or scope). As an added bonus (not for this bug probably), also offer to invalidate the old cert/exception.

So since this bug has what appears to be bigger impact on users than bug 660749, and it also _seems_ easier to fix, we might as well fix this bug first, and if bug 660749 ever lands, revert the fix for this bug, if required.

    
  
Flags: needinfo?(brian)

    
    

    
  


  
This is an attempt to fix the issue by bypassing the cache.

I'm using "attempt" because I didn't manage to reproduce the problem with current nightly, 2 different self-signed certs and mongoose 4.1 web server, and so I couldn't validate that this modification fixes the issue.

I did follow the code, however, and it seems to me that the only point of failure for this case is that the cache may return the "old" certificate instead of the one which generated the security warning, and therefore the dialog doesn't think it needs an exception, because the old one already has an exception. I also added comments as much as I understand the code (which was not fun).

The modification is intentionally tiny such that its risk could be assessed more easily. A more complete and possibly much deeper fix surely exists, and can be a followup. With a simple fix, however, there's a chance it might get an uplift if we think it's worth it.

Brian, if you think someone else should review this, let me know.

        Attachment #8419780 -
        Flags: review?(brian)

    
    

    
  
I have exactly this same issue using Firefox 29.0.1 (current production version).  This bug report was first submitted nearly three years ago (2011-05-25 13:05 PDT).  How could it still be open?  Just remove the code that causes the button to be greyed out and any code that prevents the security exception from being added.
Assignee: nobody → avihpit

    
    

    
  
Comment on attachment 8419780 [details] [diff] [review]
Don't check for cached version of the certificate

Hi, thanks for the patch. Unfortunately, I won't be able to get to this soon due to other more urgent things taking up all my time. Let's see if Doug can find somebody to help you.

        Attachment #8419780 -
        Flags: review?(brian)
Flags: needinfo?(brian) → needinfo?(dougt)

    
    

    
  
All the patch does (aside from adding numerous comments) is comment out ...

   // Is the cert already known in the list of recently seen bad certs?
   if (findRecentBadCert(uri) == true)
     return;

in checkCert().  The issue is checkCert() has set gBroken = FALSE when the above return is executed.  This is broken code, since it prevents the replacement of a broken security exception; please remove it (this is the only reasonable alternative)!

The more complex we make the code, the more easily subtle bugs are introduced.  More complexity means more test cases and obviously this code was not tested with all the obvious test cases.  We must remember to write code that does what the user wants and not necessarily what the software designer/engineer might think is best.  The above code was a very bad idea and should never have been included.  The user wants a security exception, so give it to him; don't simply ghost out the button he needs to press to finalize what he has requested.  Frustrating the user will simply force him to use a different web browser (not Firefox).  For example, SRWare Iron (Chromium) doesn't have this issue.

    
    

    
  
(In reply to Ken.Fuchs from comment #138)
> All the patch does (aside from adding numerous comments) is comment out ...

Indeed, and it's intentionally tine to make it easier to assess its risk in an environment of relatively complex-ish code.

I'm not quite sure though, did you suggest a specific change to the patch? if yes, could you please state it explicitly again? Thanks.

    
    

    
  
(In reply to Ken.Fuchs from comment #138)
> The issue is checkCert() has set gBroken = FALSE when the
> above return is executed. ...

I don't think it's relevant or correct.

While checkCert() sets gBroken = false when it starts, findRecentBadCert() sets gBroken to true if findRecentBadCert() returns true (and I specifically added a comment for findRecentBadCert which says exactly this).

So if this return statement is executed (which only follows findRecentBadCert() returning true), you're guaranteed to have gBroken == true.

    
    

    
  
As far as know, your patch is perfectly fine as far as it goes (I agree that minimal changes is the right way to patch this issue).  I'm complaining about the code prior to your patch which we both agree is obviously broken.  Finding the wrong cert makes setting gBroken either TRUE or FALSE wrong!  In that sense, setting gBroken to any value is wrong (the fact that some other function might later set gBroken to the correct value doesn't exonerate the prior incorrect code from setting gBroken to a value it can't possibly know is correct or not).  My mistake for implying there was a correct value.

General comment: The code uses too many global variables and the functions have too many side effects (one side effect is one too many).  The code also violates the principal of single function exit.  The code probably should be completely rewritten. I my opinion, code should always be written as though someone's life depended on its proper execution; this is actually more often the case than one might suspect.

Reproducibility of the Bug:

1) Restart the web server with invalid certificate #1 (could be invalidated due to the OpenSSL issue).
2) Use Firefox to access the server; it reports that there is an issue with the certificate.
3) Use Firefox to set an exception for the certificate (which works ok).
4) Reconfigure the web server to use another invalid certificate (perhaps the domain name does not perfectly match or more likely there is a chain of trust failure).
5) Use Firefox to access the server; it reports that there is an issue with the (2nd) certificate.
6) Try to use Firefox to set an exception for the 2nd certificate (which can't be done since the required button is ghosted/greyed out).

The web site is now totally inaccessible to Firefox; there is seemingly nothing a normal user can do to change this.  The only know work around for a normal user is to use a different brand of web browser.  Given the scope of recent OpenSSL bug, this may not be an insignificant number of users.

I have never trusted Firefox's certificate exception mechanism.  I never make the exceptions permanent, because when I have done so, I was never able to access that web site again using that Firefox installation.  Now, it doesn't matter whether I make the exception permanent or not; I lose access to the web site unconditionally.  Most people would consider that to be totally unacceptable.  Seeing that this bug has been open for nearly three years and underlying code, I finally understand why.  What is perplexing is there is a patch for this issue now, but I don't see anyone helping the submitter to go through the acceptance, validation and testing processes.

    
    

    
  
(In reply to Ken.Fuchs from comment #141)
> the code prior to your patch which we both agree is obviously broken

I think it's only broken as far as recentCertsSvc.getRecentBadCert(hostWithPort) doesn't do what the code expects it to. And it's not necessarily a bug, it could also be just a vague definition of this function (may it also return a bad cert for which there already is an exception?). The rest of the code is maybe not nice, but not necessarily broken IMO.


> General comment: The code uses too many ...

I don't think you'd find many which will disagree with this or with the rest of your "good code practices".

But code can sometimes evolve in a non perfect way, and at this point in time we have to deal with the way it is, and not with how we'd hope it would have been. Our first priority here is to fix it with as little risk as possible, and this is what I'm trying to do.

Incidentally or not, this is exactly how the code gains cruft. If anything, you should criticize my patch for not cleaning up the whole thing. But as we both know, this will increase the risk and therefore will take (possibly much) longer to land.

Let's leave the code quality issues, on which everyone agrees, aside for now, and focus on the task at hand: land a safe fix quickly.


> Reproducibility of the Bug:

Yes, the STR is known, and was posted several times already earlier on this bug.

However, while I did bump into this bug myself in the past, I wasn't able to reproduce it locally recently, as I noted on comment 135. If you want to help, try reproducing the bug, then apply the patch and confirm (or deny) that the patch helps.

Your help is appreciated.

    
  

        Attachment #8419780 -
        Flags: feedback?(dougt)

    
    

    
  
I was able to reproduce this issue using a nightly build on a current Debian x64 system.

I looked for the corresponding source code tarball, but could not find anything until I located this:

"Nightlies

At the moment, source tarballs of the nightly snapshots are not provided."

Why?  Do I have to install and learn yet another source code configuration system (mercurial) to simply get the current Firefox source code, just so I can apply the patch (attachment #8419780 [details] [diff] [review]) to verify that it works?  I have no need for mercurial; even to create my own patch, I would not need it.  Not providing nightly source code tarballs is an impediment to quickly verifying the effectiveness of patches.  How is downloading source via mercurial better that a tarball, especially when its only going to be downloaded one time?

    
    

    
  
Go here https://hg.mozilla.org/mozilla-central/ then at the top you'll find download links for gz/bzip2/zip tarballs for the latest revision or any previous revision.

I think the comment at the MDN page is only wrt the exact changeset from which the nightly binary was built, and even that it probably only not maintained, as tarballs for all revisions are available via the link I gave.

    
    

    
  
Also, here are binaries.

If anyone out there is able to (repeatedly) reproduce the issue and would like to help testing, please report if the "base" build still has the issue, while the "patched" build works OK.

Each of the links below contains binary builds for linux/linux64/os x/windows:

Base (revision 183183:6d32bbffc7e4): https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ahalachmi@mozilla.com-3abab3735b61/

Patched (Base + the patch from comment 135): https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ahalachmi@mozilla.com-ae5752227f1e/

Try pushes with all unit tests enabled:
Base:    https://tbpl.mozilla.org/?tree=Try&rev=3abab3735b61
Patched: https://tbpl.mozilla.org/?tree=Try&rev=ae5752227f1e

    
    

    
  
(In reply to Avi Halachmi (:avih) from comment #145)
> Also, here are binaries...

Sorry, I just pushed. It could take a while until the binaries are compiled and ready. It could take anything between few minutes to hopefully not more than an hour or so.

    
    

    
  
Yes, it does take a while to build Firefox.  I built an unpatched version and a patched version (I checked that the undesirable code was actually commented out after the patch was applied) of the bzip2 of Firefox as of several hours ago (mozilla-central-cfde3603b020).  The results of testing as described in paragraph three below was unexpected, so I made sure my environment was identical on each test and repeated them several more times, questioning all my assumptions; this all took more time.

When I verified this issue in comment 143, looking at the certificate, it was definitely the old certificate and definitely not the one I had just switched to, so the root cause as you surmised is most probably due to caching the old certificate when it really should have removed the certificate from the cache.  I simply refreshed the tab, after changing the web's site's certificate and restarting apache2 when I saw the incorrect certificate in the exception dialog.

After applying the patch and rebuilding Firefox, I'm not able to reproduce seeing an incorrect certificate.  However, when I refresh my HTTPS URL on both patched and unpatched versions, Firefox is not able to find any certificate at all for my HTTPS URL, ghosting out the "Get Certificate", "View...", "Confirm the Security Exception" buttons and the Permanently store this exception checkbox.  This is definitely different from finding the wrong certificate, which patch presumably did fix.  Whenever, I open a new tab with the HTTPS URL, it seems to work, perhaps based on a permanently stored exception (although I tried to avoid storing one).  Both certificates I'm using are faulty, one is the standard snake oil certificate that apache2 is released with (no valid CA) and the second is a certificate for the wrong domain name.

Unfortunately, the patch doesn't appear to have any effect at all, beyond never seeing an incorrect certificate to set an exception for (what the patch was created to fix).

    
    

    
  
I just checked cert_override.txt in my profile.  There are no stored exceptions in this file, so the faulty certificates can't be working due to a stored exception, right?

    
    

    
  
When I access my web site's root in a new tab it always shows the apache2 default content using either the patched or unpatched Firefox.  As soon as I refresh the tab, it gives the option to add a security exception, but finds no certificate to provide an exception for.  The content in that tab is now no longer accessible.  Why does the HTTPS URL access work the first time in a tab and never thereafter (via refreshing)?  This issue is different from the one described in bug 659736.  I will try to restrict my future findings to that bug.

    
    

    
  
(In reply to Ken.Fuchs from comment #149)
> When I access my web site's root ...

Sounds like you've collected some very useful info, appreciated.

However, to make sure I didn't mix all the many facts and experiments you posted, would you be able to summarize your findings in few clear bullets?

It sounds to me as if you, like me, are having hard times reproducing this exact bug from scratch with latest nightly/your own build. Am I correct to understand this?

In order to test the patch, we must first be able to reproduce the bug over and over (from scratch - let's say always start with a clean/empty profile) with an unpatched build, and THEN, once we're absolutely sure in our ability to reproduce it on demand from scratch, try the patched build and see if it behaves differently, and if yes, in what way.

Thanks again for your help with this.

    
    

    
  
Well, if the latest-unpatched does not reproduce teh problem, I'd say it would be useful to see if an older production firefox reproduces the problem. If that DOES, then at least we know you can reproduce the problem, even though something chagned the bug-behaviour in the current code, already without the patch.

    
    

    
  
NI me: I'll try to reproduce this today.
Flags: needinfo?(felash)

    
    

    
  
OK. Guys.... 
With PRODUCTION firefox I have just reproduced the problem with a "vanilla" apache server. 
I first started the server with the snakeoil certificate. 
went to the site and approved the exception. 
Then I generated a new certificate, approved the exception. (surprise: this worked!)
then I generated a new certificate and approved the exception. (surprise: this worked!).
Then I switched back to my first generated certificate and approved the exception. NOW I see the bug.

    
    

    
  
OK. Guys.. 

On https://dtp.bitwizard.nl:10059/ you'll find an SSL server that changes certificates every two minutes. (it changes on x:02, x:04, x:06....etc)

    
    

    
  
(In reply to r.e.wolff@bitwizard.nl from comment #154)
> On https://dtp.bitwizard.nl:10059/ you'll find an SSL server that changes
> certificates every two minutes. (it changes on x:02, x:04, x:06....etc)

Thanks.

Does it create a new certificate every few minutes? or does it cycle the certificates? if cycles, how many certs are there? about 3-4?

When I tested with this web site and with the base and patched builds from comment 145 (windows), both builds have issues, but different ones. I started with empty profile for both builds:

base - the buttons were never disabled (so _appears_ like no bug), but on some of the times after I approved it (permanently), it immediately showed the exception page again. Like it got the cert confirmed, but then couldn't load the page due to bad cert. Opening the dialog again and confirming again didn't help - again. After waiting a while, it then did manage to load the page cleanly like it doesn't have any cert issues.

patched - actually seems to suffer from this bug, and also consistently. I could add an exception once (or twice) but then never again. The buttons were grayed out on every try. Like with the base build, after some time it managed to load the page cleanly again without showing an exception.

So both are buggy, the patched build shows the bug more consistently than the base build (from what I've seen so far), and it looks like the test server at https://dtp.bitwizard.nl:10059/ cycles a small number of certificates.

At the very least, it can probably be said that the patch doesn't fix the problem. But it looks like it made the bug more reproducible.

    
    

    
  
(looks like you don't need me ;) )
Flags: needinfo?(felash)

    
    

    
  
Yes, it cycles only two certificates. (it installs one from cron at 0-59/4 and the other at 2-59/4)

From my limited testing, I reproduced the bug on exactly the second time. 

This could mean that I had already approved that "faulty" certificate, but it was now different from last time we saw a certificate on that server. 

So maybe the case is: "you don't need to approve THIS certificate because you already approved this exact certificate". But the "security exception required" popup notices that it's different from last time. 

I'm now on a different browser that hasn't seen any of those certificates yet. (I could probably create a fresh profile, but I have never done that before. )

    
    

    
  
I tried again with the https://dtp.bitwizard.nl:10059/ server. This time I documented as much as I could, but I still can't see a clear enough pattern.

What I think I can say so far is:

- The patched build always reproduces the bug. It probably means that the bug is unrelated to getRecentBadCert() cache, but may still be related to the network (specifically https) cache.

- The base build could never reproduce this bug. But it did have other issues that the patched didn't have (maybe because it couldn't get far enough) like successfully adding an exception and the page then shows an exception again.

I _think_ was able to "fix" this issue with base once with "get certificate" at the exception dialog, but on the other times it happened, "get certificate" didn't fix it (i.e. exception added successfully and the page still says there's a security exception and so the page can't be visited).

On the patched build, "get certificate" never fixed it (i.e. still can't add the exception)

So overall, I think the bug is not with the getRecentBadCert(), so the patch doesn't fix it. But at least it makes it 100% reproducible, which is probably good.

Here's my full log, maybe someone else could make more sense of it than me:
-----------------------------
two builds:
- base (clean cset 6d32bbffc7e4 - 2014-05-15)
- patched: base + the patch from comment 135
- see comment 145 for the actual builds I'm using.

- the server https://dtp.bitwizard.nl:10059/ is supposedly switching certs every 2 minutes (comment 154)

- the cert #NN means that reloading the page showed a different thing (e.g. changing from loaded ok to showing an exception, or vice verse)

- All reloads and actions were executed, as much as possible, on both builds side by side.

empty/new/clean profiles for each, running side by side (with -no-remote)

cert #1:
base:    exception -> added ok
patched: exception -> added ok

cert #2:
base:    exception ->added ok
patched: exception -> can't add (with reloads, "get cert" and retries)

cert #3:
base:    exception ->added ok
patched: no exception

cert #4:
base:    exception -> added ok
patched: exception -> can't add

cert #5:
base:    exception -> added ok
patched: no exception

So far looks like
- there are two certs.
- base can add an exception which seems to invalidate the previous cert+exception.
- patched doesn't allow adding an exception if it already has one.

- patched reproduces the bug every time, base doesn't seem to have this bug.

closed and opened again both (side by side again), certs might or might not have cycled in between

cert #1:
base:    no exception
patched: no exception

(seems to be taking a long time for the cert to switch here, both don't show an exception on reloads)

cert #2:
base:    exception -> added ok
patched: exception -> can't add

cert #3:
base:    exception -> added ok
patched: no exception

cert #4:
base:    exception -> added ok
patched: can't add

cert #5:
base:    exception -> added ok
patched: can't add

So far looks like:
- exactly the same pattern and conclusions as on the first load.

- waited a while without closing the browsers.

cert #6:
base:    exception -> added ok -> page shows an exception again -> (possibly with some wait) added ok again -> page loads fine
patched: no exception

- waited a short while

cert #7:
base:    no exception
patched: exception -> can't add

cert #8:
base:    exception -> added ok -> page shows an exception again -> added ok -> page shows an exception again (and the same at least 2 more times) -> clicked "show certificate" -> added ok, page loads fine
patched: no exception

cert #9:
base:    exception -> added ok -> page again shows an exception (repeated twice) -> tried the "get certificate" trick -> exception again.
patched: no exception

cert #10:
base:    no exception
patched: exception -> can't add
-----------------------------


(In reply to Julien Wajsberg [:julienw] from comment #156)
> (looks like you don't need me ;) )

Oh, I think we do, please :)
Flags: needinfo?(felash)

    
    

    
  
FYI, it now shows which cert is active. 

With my bog-standard ubuntu-compiled browser I could reproduce it, the first time. 
Now, after having cleared the certificates with preferences->advanced->certificates->view_certificates, I can no longer reproduce. It just aks for the exception every time the certificate changes. 

I have the advantage of being able to type "ssl1" to switch to cert 1, and "ssl2" to switch to the other, so I can switch quicker than you guys. 

I'm considering allowing you guys to trigger the cert switch too, but this needs some thought to keep it secure. I don't need a breakin on that machine.

    
    

    
  
(In reply to r.e.wolff@bitwizard.nl from comment #159)
> FYI, it now shows which cert is active. 

Thanks.

> I'm considering allowing you guys to trigger the cert switch too, but this
> needs some thought to keep it secure. I don't need a breakin on that machine.

I'd advise against it, and, if I may, ask that you also don't use your "backdoor" switch. Looks like we have enough unknown variables, and adding another variable of "maybe someone else just switched it" doesn't sound like fun.

Just keep it as is, cycling between 2 certs every 2 mins, to help us rely on it.

Thanks.

    
    

    
  
I just implemented the, you can switch it. ... :-(
Let me see what I can do....

    
    

    
  
I tried making a second site with the other "behaviour", but was unable to get it working. So now we're back to the timed-switching.

    
    

    
  
(In reply to r.e.wolff@bitwizard.nl from comment #159)
> I'm considering allowing you guys to trigger the cert switch too ...

(In reply to r.e.wolff@bitwizard.nl from comment #161)
> I just implemented the, you can switch it. ... :-(

(In reply to r.e.wolff@bitwizard.nl from comment #162)
> So now we're back to the timed-switching.

Well, I think something has changed.

Now both base and patched work 100% correctly all the time and I also don't notice other bugs - adding exception every two minutes now always work and the page then shows correctly on the same two builds which I tested before.

I then deleted the profiles and started from scratch - same result - 100% working correctly all the time.

Maybe this bug also depends on the kind of exception?

What changed on the server other than the small HTML changes? Are these still the exact same certificates?

If these are new certs, what's the difference between the "old" certs and the new ones?

This is becoming uglier by the minute...

    
    

    
  
I think I'm able to reproduce from scratch, with self generated certs all the cases observed on this thread, except one:

reproduced (each case with both builds running side-by-side):
- base always ok but patched always can't add cert.
- both base and patched can't add cert (that's the original symptom of this bug)
- both base and patched always ok (not 100% sure on this one yet).

Couldn't yet reproduce:
- base adds exception ok but then the page shows an exception again.

Didn't try to fix yet. I first want to be 100% sure of the STRs, but I already have an approach for the fix.

I'll post more details soon.

    
    

    
  
@AVI, no there are now 6 certs. The snakeoil one has not been seen by any browser but my own. 
Then the next two were the ones that first figured in the auto-rotate. 
Then the next three were added to allow everybody to trigger a certificate change. 
There are now two "sites" defined that use the first two self-created certificates. And these auto-rotate. 

I have the impression that firefox might be accumulating more state than what is visible. It'll reproduce the first time, but not afterwards. I'm going to create a new user on my machine and test from there.

    
    

    
  
The second certificate was slightly different as I had not filled out the "state". 
I was unable to reproduce with a fresh account. 
I was unable to reproduce after changing to the "identical info" certificate. :-( 

The "number two" certificate is now the one called "C3", which has identical who-is-who info.

    
    

    
  


  
Reproducing this bug is turning out to be super elusive.

My STR includes deleting the profile first, using an https server with a fixed set of certs which I generated myself. I had few STRs, where each was able to consistently reproduce an issue, over and over, and then, some time later, it just doesn't reproduce anymore, with all the factors I could think of intact.

I execute the same build of firefox always, with the same server and the same certs, with -no-remote -profile path/to/test-profile, it looks like a new firefox, and yet, for half an hour the STR is 100% reliable, and then, it starts to be less than reliable, and at some stage it just doesn't reproduce anymore.

Nevertheless, I was able to capture some useful data. I managed to get all the details (even if it seems I can't reproduce anymore now) of the two bugs which I know of:
- Adding an exception but then the page shows an exception again.
- Can't add an exception (this bug).

The sequence of the dialog is this:
- The dialog starts.
- the dialog tries to grab a hold of the cert to display (checkCert()):
  - it tries to use getRecentBadCert(host+port).
  - if no success, it XHR's the protocol+domain+port, expects an exception due to the cert, and then grabs the cert from the exception.
- display the dialog, and enables/disables the buttons according to the cert.

There two points of failure here:

1. getRecentBadCert may return (rarely, but once it happens once, it happens more) a prior cert instead of the one for which the dialog was invoked and still indicate it's broken (so it can be added). That's what my earlier patch bypasses. When this happens, it's possible to add an exception, but then the page will show an exception again. _usually_ ctrl+f5 (reload without cache) fixes it. or restart as well. This is a short term cache and probably doesn't live on disk.

I've seen this happen and saw that the details which getRecentBadCert returns are of a previous cert instead of the one which we wanted to add an exception to.

2. the XHR may return the data from the network cache. If that happens, there's no security exception (JS exception), it grabs the cert and the ssl status from the request, but doesn't modify the gBroken variable explicitly (it might modify implicitly if there's a security exception, but AFAICT isn't).

I've seen this happen too, I saw that the XHR doesn't have a security exception and the cert details it ends up with are of a prior cert and not the one the dialog was invoked for.

Overall, IMO this dialog should just get rid of both (getRecentBadCert and cached XHR). This dialod doesn't happen much, and contacting the server directly before adding an exception seems the most stateless, reliable, and probably most correct as well.

Bypassing getRecentBadCert is easy, but I couldn't reproduce it long enough to verify that my XHR cache bypass actually works.


I'm attaching my debug/info patch for reference.

- It prints all relevant flow and cert data to the console (so you might need to invoke firefox with -console, and set the pref browser.dom.window.dump.enabled = true).

- Allows bypassing getRecentBadCert and XHR cache (the latter untested) using the the (int) pref security.dialog.debug.mode. 0 is the default behavior, 1 bypasses getRecentBadCert only, 2 hopefully bypass XHR cache, and 3 bypasses both.

I'm seriously baffled with the STR of this bug...

        Attachment #8419780 -
        Attachment is obsolete: true

        Attachment #8419780 -
        Flags: feedback?(dougt)

    
    

    
  
(In reply to Avi Halachmi (:avih) from comment #167)
> 2. the XHR may return the data from the network cache. If that happens,

That's this bug. On this case, the "Confirm exception" button is grayed out. AFAICT, that's the only case which triggers this bug.

    
    

    
  
Neil suggested on IRC that this dialog most probably is also used in Thunderbird, and that in Thunderbird it has to rely on getRecentBadCert because it will never be able to XHR the server and re-create the bad cert it needs to resolve.

This resonates with an observation I made during my tests, that when the port of the https server is _not_ 443, getRecentBadCert always finds a bad cert, but when it's 443 (or implied), then that's not necessarily the case.

It's apparent with a new profile. Set up the https server at some non-443 port (accessed with https://myserver:port/ ), and the first time this server is visited, the exception is shown and the button is clicked to open the dialog, getRecentBadCert finds a cert.

Do the same with an https server on port 443 (either explicit or implied), and getRecentBadCert doesn't find anything.

When visiting https://10.0.5.3/ or https://10.0.5.3:443/, the log generated by the patch in comment 167 looks like:

findRecentBadCert: entering (prePath: https://10.0.5.3) ...
findRecentBadCert: not found ([2] no status)

But then delete the profile, set the server to port 9443, and it then looks like this:

findRecentBadCert: entering (prePath: https://10.5.0.3:9443) ...
findRecentBadCert: found

This also works if you try it the other way around (first 9443, then 443). It's not an issue of prior cert because on this test the profile is deleted before each attempt.

    
    

    
  
(In reply to Avi Halachmi (:avih) from comment #169)
> Neil suggested on IRC that this dialog most probably is also used in
> Thunderbird, and that in Thunderbird it has to rely on getRecentBadCert
> because it will never be able to XHR the server and re-create the bad cert
> it needs to resolve.

Adding that IMO, if this is indeed the case and Thunderbird relies on getRecentBadCert, we could add an exception for Thunderbird at the code to not skip whatever it relies on.

The main point here being that if we could fix the issue the the vast majority of users of this code (which I'm estimating as Firefox users) without changing the status for other application, then it would still be a very useful fix, and without negative side effects for platforms where the fix can't be applied.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        logging-on
        — 
          — Splinter Review
      

    


  
So far I found two issues:
1. When using the default port (in firefox, not checked comm-central yet) the port was set up to -1. This made tha call to getRecentBadCert always fail when using the defaul port (kudos to avi on comment 169).
2. the cache nsRecentBadCerts could contain more than one entry for the same host:port pair with (different or same certs), and the code that searched for the entries assumed that there was only one entry (and was searched linearly from the perspective of the memory location not the usage pattern).

So here is a patch that addresses both. I still need to figure out if the port replacement in  findRecentBadCert breaks comm-central.

    
    

    
  
(In reply to Camilo Viecco (:cviecco) from comment #171)
> So far I found two issues:
> 1. When using the default port (in firefox, not checked comm-central yet)
> the port was set up to -1. This made tha call to getRecentBadCert always
> fail when using the defaul port (kudos to avi on comment 169).
> 2. the cache nsRecentBadCerts could contain more than one entry for the same
> host:port pair with (different or same certs), and the code that searched
> for the entries assumed that there was only one entry (and was searched
> linearly from the perspective of the memory location not the usage pattern).

If I interpret your reply correctly, do you imply that the only issue is with getRecentBadCert and default port?

From my observation, the symptoms of such failure is that the UI does allow adding an exception (because the function findRecentBadCert always sets gBroken=true so the UI exception controls are enabled), but after confirmed, the page shows an exception again because the cert which we approved isn't actually the one which triggered the exception and is required for the page to show.

The above is _not_ this bug (though still a bug).

This bug, as far as I can tell, is that getRecentBadCert doesn't find one, it then goes on to XHR the server expecting a security exception from which it could grab the cert, but in practice the XHR hits the network cache, no exception is generated, the (cached) cert isn't broken, and so the UI for adding an exception are disabled. Hence the user unable to add an exception.
Depends on: 1020431

    
    

    
  
(In reply to Avi Halachmi (:avih) from comment #170)
> (In reply to Avi Halachmi (:avih) from comment #169)
> > Neil suggested on IRC that this dialog most probably is also used in
> > Thunderbird, and that in Thunderbird it has to rely on getRecentBadCert
> > because it will never be able to XHR the server and re-create the bad cert
> > it needs to resolve.
> 
> Adding that IMO, if this is indeed the case and Thunderbird relies on
> getRecentBadCert, we could add an exception for Thunderbird at the code to
> not skip whatever it relies on.

It is OK to remove the call to getRecentBadCert and all the functionality that depends on it since AFAICT Firefox doesn't need it. If Thunderbird needs it then Thunderbird can fork the relevant UI and add it back.

    
    

    
  
(sorry, couldn't find the time to reproduce this in a sane way)
Flags: needinfo?(felash)

    
    

    
  
rbarnes to investigate what is needed, if anything.
Flags: needinfo?(dougt) → needinfo?(rlb)

    
    

    
  
I'm having similar issue with internal site with self-signed cert. I used to be able to set up a security exception "This connection is untrusted" - "Add Exception" - and "Confirm Security Exception". Now all I have is "No Information Available" in the "Add Security Exception" window. Clicking hte "Get Certificate" button only refreshes the page and it states "No Information Available"; underneath it states "Unable to obtain identification status for the given site".
I've duplicated the issue on a machine where v30 works properly, but update to v31 breaks. IE works as usual for this.
Please provide a mechanism for users to use FF for internal sites...

    
    

    
  
I recently experienced this at work for an internal site and I was able to fix the situation by doing 2 things:

1. killing the stored exception (options->advanced->certificates tab->view certificates->servers tab) find the stored exception and remove.
2. clearing out my cache. (clear now button under options->advanced->network tab)

This worked for win7 64bit pro ff ver: 31.0

-Steve

    
    

    
  
Hi Steve - I followed your suggestions but behavior is the same. Thanks tho.
Still have "Secure Connection Failed" - (Error Code: sec_error_ca_cert_invalid)





(In reply to Steve from comment #178)
> I recently experienced this at work for an internal site and I was able to
> fix the situation by doing 2 things:
> 
> 1. killing the stored exception (options->advanced->certificates tab->view
> certificates->servers tab) find the stored exception and remove.
> 2. clearing out my cache. (clear now button under options->advanced->network
> tab)
> 
> This worked for win7 64bit pro ff ver: 31.0
> 
> -Steve

    
    

    
  
mcolley, despite the failure, if you're able to see / get to the allow exception buttons/options.. ensure you've also done a hard refresh (ctrl+f5). Just another thought.

-Steve

    
    

    
  
Steve - I did that, no change. Uninstalled/Reinstalled FF, same result. I'll contact the product vendor and see if we can change the cert presented by the app.

    
    

    
  
FWIW - the product vendor responded to my inquiry. They recommended disabling the new functionality;

"Open FF - type:    about:config,
Look for security.use_mozillapkix_verification = true and set it to false."

This does resolve my issue - I'm able to access the application and set an exception for the certificate it presents. It's a workaround, and I'm not real keen on disabling security features, but at least I'm operational right now.

    
    

    
  
I believe this should be resolved as of Firefox 33, which is currently in Aurora.  In that version, we updated the exception processing to make sure that the exception stored was for the same certificate that caused the error.  

Could someone try this in Aurora/33 or Nightly/34 and confirm that the issue still exists?
Flags: needinfo?(rlb)

    
    

    
  
(In reply to Richard Barnes [:rbarnes] from comment #183)
> I believe this should be resolved as of Firefox 33, which is currently in
> Aurora.  In that version, we updated the exception processing to make sure
> that the exception stored was for the same certificate that caused the
> error.

That's good news.

> Could someone try this in Aurora/33 or Nightly/34 and confirm that the issue
> still exists?

The problem was reproducing this bug consistently. If you know how to reproduce it, then it's easy to verify if 33 fixes it. I can try it too if you'll tell me how to reproduce it consistently.

    
    

    
  
(In reply to Avi Halachmi (:avih) from comment #184)
> (In reply to Richard Barnes [:rbarnes] from comment #183)
> > I believe this should be resolved as of Firefox 33, which is currently in
> > Aurora.  In that version, we updated the exception processing to make sure
> > that the exception stored was for the same certificate that caused the
> > error.
> 
> That's good news.

FWIW, here's the relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=940506


> > Could someone try this in Aurora/33 or Nightly/34 and confirm that the issue
> > still exists?
> 
> The problem was reproducing this bug consistently. If you know how to
> reproduce it, then it's easy to verify if 33 fixes it. I can try it too if
> you'll tell me how to reproduce it consistently.

I tried the STR in Comment 141, and could not reproduce.

> openssl genrsa -out key1.pem 2048
> openssl req -new -x509 -key key1.pem -out cert1.pem
> openssl genrsa -out key2.pem 2048
> openssl req -new -x509 -key key2.pem -out cert2.pem
> openssl s_server -accept 8888 -key key1.pem -cert cert1.pem
> # Load https://localhost:8888 and store exception
> openssl s_server -accept 8888 -key key2.pem -cert cert2.pem
> # Load https://localhost:8888 and store exception

I would say that unless someone can reproduce this, we mark it RESOLVED:WORKSFORME.

    
    

    
  
(In reply to Richard Barnes [:rbarnes] from comment #185)
> I would say that unless someone can reproduce this, we mark it
> RESOLVED:WORKSFORME.

It might work for you, but it clearly doesn't for others. If you _know_ that bug 940506 fixed it, then it should be marked FIXED IMO, otherwise, IMO it should be kept open.

Also, bug 940506 is about removing recentBadCert, but as mentioned several times already, getRecentBadCert is _not_ the cause for the symptom where the exception cannot be added (i.e. this bug).

recentBadCert's bug symptom is allowing to add the exception but then it prompts again on bad certificate, so it's not this bug.

So far, the hypothesis for this bug is that the dialog is invoked for a bad cert from the site, but when the dialog tries to retrieve from the site using XHR (to display its properties at the dialog), it gets a cached and valid certificate - which greys out the "add" button for adding the exception because it won't let the user add a valid cert.

    
    

    
  
(In reply to Avi Halachmi (:avih) from comment #186)
> (In reply to Richard Barnes [:rbarnes] from comment #185)
> > I would say that unless someone can reproduce this, we mark it
> > RESOLVED:WORKSFORME.
> 
> It might work for you, but it clearly doesn't for others. If you _know_ that
> bug 940506 fixed it, then it should be marked FIXED IMO, otherwise, IMO it
> should be kept open.

Fair enough.  But let's figure out if there are still people who are broken.  I tried to find the last STR reported (above), and could not reproduce.


> So far, the hypothesis for this bug is that the dialog is invoked for a bad
> cert from the site, but when the dialog tries to retrieve from the site
> using XHR (to display its properties at the dialog), it gets a cached and
> valid certificate - which greys out the "add" button for adding the
> exception because it won't let the user add a valid cert.

OK, so Bug 940506 isn't the best reference.  Look at Bug 1025332 instead.  With that bug, the UI no longer does a separate fetch to get the cert data, so the mismatch in question here shouldn't happen.

http://dxr.mozilla.org/mozilla-central/source/security/manager/pki/resources/content/exceptionDialog.js#65

(Note: The fetch mechanism is still there, to support non-Docshell things like Thunderbird.  But the non-fetch mechanism is used preferentially.)

So again: Has anyone tested this since Bug 1025332?
Flags: needinfo?(avihpit)

    
    

    
  
(In reply to Richard Barnes [:rbarnes] from comment #187)
> OK, so Bug 940506 isn't the best reference.  Look at Bug 1025332 instead. 
> With that bug, the UI no longer does a separate fetch to get the cert data,
> so the mismatch in question here shouldn't happen.
> 
> http://dxr.mozilla.org/mozilla-central/source/security/manager/pki/resources/
> content/exceptionDialog.js#65
> 
> (Note: The fetch mechanism is still there, to support non-Docshell things
> like Thunderbird.  But the non-fetch mechanism is used preferentially.)

On the face of it, the patch at bug 1025332 does look to me like it should fix this bug too.

I'd agree that if we can't find people who experience this bug with nightly from 2014-07-03 onwards (one day after bug 1025332 landed), then we should declare it as FIXED.
Flags: needinfo?(avihpit)

    
    

    
  


  
I'm still unable to access my router via https://192.168.1.1/ after installing FF 33. I'm adding two screenshots. The first shows the error in question, the second shows my inability to add an exception in Firefox's security manager due to "Get Certificate" failing, both using 33.0a2 (2014-09-02). My steps for reproducing it were:

* Change a WRT54GL v1.1 router (firmware Ver.4.30.16 Build 6) to HTTPS-only.
* Click save settings.
* Click "continue" once settings successfully saved.

    
    

    
  
I should add that in my default (and only) profile, my cert_override.txt file is empty, no previously added exception for this router shows up in my Certificate Manager's server list, and neither restarting Firefox nor clearing my cache, etc. solved the issue. 

As a workaround, (thank you comment 107) I created a new temporary profile. This allowed me to add a server exception and access the router again. However, copying the contents of my temporary profile's cert_override.txt file to my default profile still results in a "sec_error_reused_issuer_and_serial" error, even though https://192.168.1.1 now shows up in my server list.

    
    

    
  
Richard, what do you think of comment 189 - 191?
Flags: needinfo?(rlb)

    
    

    
  
(In reply to Joseph Conrad from comment #189)
> Created attachment 8483372 [details]
> Still unable to access my router in FF 33.0a2 (2014-09-02).
> 
> I'm still unable to access my router via https://192.168.1.1/ after
> installing FF 33. I'm adding two screenshots. The first shows the error in
> question, the second shows my inability to add an exception in Firefox's
> security manager due to "Get Certificate" failing, both using 33.0a2
> (2014-09-02). My steps for reproducing it were:
> 
> * Change a WRT54GL v1.1 router (firmware Ver.4.30.16 Build 6) to HTTPS-only.
> * Click save settings.
> * Click "continue" once settings successfully saved.

This is a different issue. The error "sec_error_reused_issuer_and_serial" is not overridable, and thus the certificate exception dialog won't be able to add an override (unfortunately the UI neglects to inform the user that this is the case). What's going on here is the NSS certificate database has seen (and apparently remembers) a certificate with the same issuer and serial number that is nevertheless different from the one the router is sending now. Due to implementation limitations, NSS essentially refuses to handle that certificate. I bet if you remove cert_override.txt, cert8.db, key3.db, and secmod.db from your profile directory (WARNING: this will remove any private keys, user certificates, overrides, and user-added trust anchors), it'll work as intended (until the router decides it needs a new certificate with the same serial number and issuer).
Flags: needinfo?(rlb)

    
    

    
  
(In reply to David Keeler (:keeler) [use needinfo?] from comment #193)
> (In reply to Joseph Conrad from comment #189)
> > Created attachment 8483372 [details]
> > Still unable to access my router in FF 33.0a2 (2014-09-02).
> > 
> > I'm still unable to access my router via https://192.168.1.1/ after
> > installing FF 33. I'm adding two screenshots. The first shows the error in
> > question, the second shows my inability to add an exception in Firefox's
> > security manager due to "Get Certificate" failing, both using 33.0a2
> > (2014-09-02). My steps for reproducing it were:
> > 
> > * Change a WRT54GL v1.1 router (firmware Ver.4.30.16 Build 6) to HTTPS-only.
> > * Click save settings.
> > * Click "continue" once settings successfully saved.
> 
> This is a different issue. The error "sec_error_reused_issuer_and_serial" is
> not overridable, and thus the certificate exception dialog won't be able to
> add an override (unfortunately the UI neglects to inform the user that this
> is the case). What's going on here is the NSS certificate database has seen
> (and apparently remembers) a certificate with the same issuer and serial
> number that is nevertheless different from the one the router is sending
> now. Due to implementation limitations, NSS essentially refuses to handle
> that certificate. I bet if you remove cert_override.txt, cert8.db, key3.db,
> and secmod.db from your profile directory (WARNING: this will remove any
> private keys, user certificates, overrides, and user-added trust anchors),
> it'll work as intended (until the router decides it needs a new certificate
> with the same serial number and issuer).

This sounds consistent with the workaround in comment 191, and sounds like a bug in the WRT firmware generating certificates without random serial numbers.  

Given that bug 1025332 has been landed for a while, and we haven't gotten reconfirmation, I'm closing this as FIXED.
Status: NEW → RESOLVED
Closed: 12 years ago → 10 years ago
Resolution: --- → FIXED

    
    

    
  
Ubuntu 14.04
Nightly 34.0a1
New profile
No cert override.

Hit https://69.4.28.155 - this has an invalid cert and has also expired
I get a screen with no button allowing me to add an exception.

Unless the specific issue im facing has been resolved on another thread I believe this issue persists.

    
    

    
  
(In reply to Simon Taylor from comment #195)
> Ubuntu 14.04
> Nightly 34.0a1
> New profile
> No cert override.
> 
> Hit https://69.4.28.155 - this has an invalid cert and has also expired
> I get a screen with no button allowing me to add an exception.
> 
> Unless the specific issue im facing has been resolved on another thread I
> believe this issue persists.

What do you mean by 'a screen with no button allowing ... an exception'? If you don't see the 'This site provides valid, verified identification. There is no need to add an exception.' message, then that would be a different bug (feel free to file a new one).

    
    

    
  
(In reply to Simon Taylor from comment #195)
> Ubuntu 14.04
> Nightly 34.0a1
> New profile
> No cert override.
> 
> Hit https://69.4.28.155 - this has an invalid cert and has also expired
> I get a screen with no button allowing me to add an exception.
> 
> Unless the specific issue im facing has been resolved on another thread I
> believe this issue persists.

In Nightly 35.0a1, I was able to add an exception just fine.  Could you re-try in Aurora (which is now 34), and if it's still broken, post a screenshot?

Like keeler, I suspect this is a separate issue, if at all.

    
    

    
  
(In reply to Simon Taylor from comment #195)
> Hit https://69.4.28.155 - this has an invalid cert and has also expired
> I get a screen with no button allowing me to add an exception.

I get a message that the cert belongs to a different site, *.infocrossing.com, and Firefox (32.0.1) does allow me to create a security exception.

    
    

    
  
(In reply to John David Galt from comment #198)
> (In reply to Simon Taylor from comment #195)
> > Hit https://69.4.28.155 - this has an invalid cert and has also expired
> > I get a screen with no button allowing me to add an exception.
> 
> I get a message that the cert belongs to a different site,
> *.infocrossing.com, and Firefox (32.0.1) does allow me to create a security
> exception.

This is interesting - I have added a screenshot of the 2 versions of Firefox I have on my Ubuntu.
32
Nightly 34.0a1
You can see in both of them that I have just hit the url https://69.4.28.155 and neither screen provides a button which allows an exception.

    
    

    
  
(In reply to Simon Taylor from comment #199)
> ...
> This is interesting - I have added a screenshot of the 2 versions of Firefox
> ...

Forgot to attach them?

    
    

    
  
(In reply to Avi Halachmi (:avih) from comment #200)
> (In reply to Simon Taylor from comment #199)
> > ...
> > This is interesting - I have added a screenshot of the 2 versions of Firefox
> > ...
> 
> Forgot to attach them?

My comment was pre-emptive and Im now having issues screenshotting from Ubuntu - working through it - standby :-)

    
    

    
  

      
      
      
      

        Attached image
          
        photo.JPG
        — 
      

    


  
Attachment for comment 199. Bit blurry as screenshotting isnt working at present.

    
    

    
  


  
This bug is definitely not fixed in Firefox 32.0.  Please see attached snapshot of the result of accessing https://69.4.28.155.  As others have noted, there is no button to (or other means to) add an exception.

    
    

    
  
Just updated to Firefox 32.0.1.  Same result as in Comment 203.

    
    

    
  
(In reply to Ken.Fuchs from comment #203)
> Created attachment 8490793 [details]
> Secure-Connection-Failed-FF-32.0.jpg
> 
> This bug is definitely not fixed in Firefox 32.0.  Please see attached
> snapshot of the result of accessing https://69.4.28.155.  As others have
> noted, there is no button to (or other means to) add an exception.

I think this isn't exactly the original case of this bug.

The original symptom is that you see an "Untrusted connection" message at the page, and after you click it you see an exception _dialog_, but the "Add Exception" button is greyed out at the dialog so you can't add the exception.

Are you saying that the symptom has now changed and it doesn't say "untrusted.." anymore at the page, and so you can't even spawn the dialog?

    
    

    
  
Just installed the current nightly build (35.0a1).  Again, same result as in Comment 203.

Can someone please explain how this bug can be "RESOLVED FIXED", when it obviously isn't?

    
    

    
  
(In reply to Avi Halachmi (:avih) from comment #205)
> (In reply to Ken.Fuchs from comment #203)
> > Created attachment 8490793 [details]
> > Secure-Connection-Failed-FF-32.0.jpg
> > 
> > This bug is definitely not fixed in Firefox 32.0.  Please see attached
> > snapshot of the result of accessing https://69.4.28.155.  As others have
> > noted, there is no button to (or other means to) add an exception.
> 
> I think this isn't exactly the original case of this bug.
> 
> The original symptom is that you see an "Untrusted connection" message at
> the page, and after you click it you see an exception _dialog_, but the "Add
> Exception" button is greyed out at the dialog so you can't add the exception.
> 
> Are you saying that the symptom has now changed and it doesn't say
> "untrusted.." anymore at the page, and so you can't even spawn the dialog?

Right, there is no mention of "untrusted" connection any more and no "add a security exception" dialog.  The picture in comment #203 is the complete result of attempting to access https://69.4.28.155.

The symptoms of this bug have changed, but there is still no way to add a security exception.  Thus I don't see how this bug can be said to be "FIXED".  Changing the way a bug manifests itself is not a FIX.  Totally removing the ability to add a security exception is not FIX of this bug, assuming one does indeed want to preserve the feature of "adding a security exception".  I do believe that nearly everyone wants this feature (adding a security exception), or at least wants to allow others the potential use of it.

    
    

    
  
(In reply to Ken.Fuchs from comment #206)
> Just installed the current nightly build (35.0a1).  Again, same result as in
> Comment 203.
> 
> Can someone please explain how this bug can be "RESOLVED FIXED", when it
> obviously isn't?

You need to report a different bug.  This bug is not a master bug for all cases where no override is possible -- in some cases, the lack of override is intentional.

    
    

    
  
(In reply to Ken.Fuchs from comment #207)
> (In reply to Avi Halachmi (:avih) from comment #205)
> > (In reply to Ken.Fuchs from comment #203)
> > > Created attachment 8490793 [details]
> > > Secure-Connection-Failed-FF-32.0.jpg
> > > 
> > > This bug is definitely not fixed in Firefox 32.0.  Please see attached
> > > snapshot of the result of accessing https://69.4.28.155.  As others have
> > > noted, there is no button to (or other means to) add an exception.
> > 
> > I think this isn't exactly the original case of this bug.
> > 
> > The original symptom is that you see an "Untrusted connection" message at
> > the page, and after you click it you see an exception _dialog_, but the "Add
> > Exception" button is greyed out at the dialog so you can't add the exception.
> > 
> > Are you saying that the symptom has now changed and it doesn't say
> > "untrusted.." anymore at the page, and so you can't even spawn the dialog?
> 
> Right, there is no mention of "untrusted" connection any more and no "add a
> security exception" dialog.  The picture in comment #203 is the complete
> result of attempting to access https://69.4.28.155.
> 
> The symptoms of this bug have changed, but there is still no way to add a
> security exception.  Thus I don't see how this bug can be said to be
> "FIXED".  Changing the way a bug manifests itself is not a FIX.  Totally
> removing the ability to add a security exception is not FIX of this bug,
> assuming one does indeed want to preserve the feature of "adding a security
> exception".  I do believe that nearly everyone wants this feature (adding a
> security exception), or at least wants to allow others the potential use of
> it.

Ken: The lack of an exception mechanism is not a bug.  There are cases where we want there to be no exception mechanism (e.g., in the case of revocation).  Your particular cert getting that UI may or may not be a bug.

This bug was about the mismatch between the exception UI and cert presented in the initial exchange.  That part has been fixed.  Please file a new bug for the remainder of your issue.

    
    

    
  
(In reply to Richard Barnes [:rbarnes] from comment #209)

> Ken: The lack of an exception mechanism is not a bug.  There are cases where
> we want there to be no exception mechanism (e.g., in the case of
> revocation).  Your particular cert getting that UI may or may not be a bug.

Removal of a feature that contains a bug is not a fix of that bug.  There is
currently no warning about what is wrong with the cert for https://69.4.28.155.
There is currently no way to add a security exception for it.  The cert for
https://69.4.28.155 has not been revoked.

> This bug was about the mismatch between the exception UI and cert presented
> in the initial exchange.  That part has been fixed.  Please file a new bug
> for the remainder of your issue.

The user is not interested in a pedantic explanation of why what has been done
to "fix" this bug is really a fix at all.

The proper thing to do in my opinion is reopen this bug and fix it so a creating
a security exception is possible.  That would involve un-ghosting the security
exception button and actually add the security exception.  Please start
with reverting the "FIX" that "resolved" this bug.  Opening another
bug to fix this bug properly just doesn't make much sense to me.

    
    

    
  
(In reply to Ken.Fuchs from comment #210)
> (In reply to Richard Barnes [:rbarnes] from comment #209)
> 
> > Ken: The lack of an exception mechanism is not a bug.  There are cases where
> > we want there to be no exception mechanism (e.g., in the case of
> > revocation).  Your particular cert getting that UI may or may not be a bug.
> 
> Removal of a feature that contains a bug is not a fix of that bug.  There is
> currently no warning about what is wrong with the cert for
> https://69.4.28.155.
> There is currently no way to add a security exception for it.  The cert for
> https://69.4.28.155 has not been revoked.

It hasn't been revoked, but it's not a valid cert.  As the UI says, the signature on the cert is not valid.  The UI correctly reflects this -- sec_error_bad_signature means the signature is bad :)

The error is non-overrideable in Firefox 32-34, but in 35, the processing has been changed so that the error presented is overrideable ("wrong server").  So the only question here is whether the solution should be uplifted, which is a question for another bug (probably Bug 1058812).  Please comment in that bug.

    
    

    
  
Guys, if you are accessing https://www.paypal.com/ it is a serious issue if the certificate is not valid. Those guys are in business because they have a valid certificate. Something can be said for the policy: when an invalid certificate comes along, don't even allow the user to override it. 
However, what happens when they goof up and for a period of 24 hours in 2015 (at the time of writing this: in the future) their certificate is expired? Of course it's better not to use paypal during those 24 hours. But some people will have to accept the risk that after reading "paypal goof: https certificate expired" in the news when they get an expired certificate warning from their browser they are talking to the real paypal, and not some quickly-setup-man-in-the-middle.

That said, there are cases where "having encryption working" is enough protection against (passive) sniffers. Say when you access your router. Or as the example above shows: suppose DNS is down for a short while. Suppose I manage to get the proper IP address by hand and then access the site? What then? Are YOU deciding that it's not a valid situation and allowing the user to override it is not safe?

In a perfect world, there are properly configured https servers and bad guys with man-in-the-middle equipment. Nobody needs to override the "invalid certificate" warning, as those warnings are always correct. 

In the real world, there are goofs, even from big companies, there are odd situations where the URL doesn't match the certificate and many more situations where overriding the "this site presented an invalid certificate" is a proper action. That's why it is there. That's why it needs to be there. 

Now, if the browser is configured for your grandpa, "The user is dumb, don't show advanced settings", something can be said for not allowing the override in that situation. gramps will have to live without paypal for a day. He'll be unable to reach the (any!) site when DNS is down and he won't be configuring webservers that present a certificate for when they will be live, but are not yet live, so they are currently contacted on an different URL.

    
    

    
  
What's your point?

Richard's point is: we fixed a bug, you think _your_ bug is not fixed, please file a separate bug as this will help make things clearer and fix _your_ bug. Continuing discussion in this bug with more than 212 comments where most don't have meaningful information or have obsolete information or is speaking about different issues, this is not pragmatic.

Thanks !

    
    

    
  
The point is: the browser cannot decide: "in this situation I won't let you override the certificate". Richard was arguing that the browser does sometimes make the decision and he thinks that's a valid situation. It is not.

    
    

    
  
I just wanted to say thank you for addressing this issue.  I tested my use-case from comment 50 against 35.0a1 nightly build and it worked fine.

    
    

    
  
(In reply to r.e.wolff@bitwizard.nl from comment #214)
> The point is: the browser cannot decide: "in this situation I won't let you
> override the certificate". Richard was arguing that the browser does
> sometimes make the decision and he thinks that's a valid situation. It is
> not.

Please take these discussions to the mailing list, dev.security.

    
    

    
  
It's back. sorry about the Dutch.

I cannot add an exception, the dialog box simply does not appear.
Have already deleted the Cert8.db - no effect.
Also deleted all history in the browser, ditto, no effect.



    versie33.0.2
    tijd geopend26967 min
    laatste crash2014-10-29
    bladwijzers2272



U hebt Firefox gevraagd een beveiligde verbinding op te zetten met servername, maar we kunnen niet bevestigen dat uw verbinding beveiligd is.


Normaal gesproken zullen websites vertrouwde identificatie tonen wanneer u een beveiligde verbinding wilt opzetten, om te bewijzen dat u naar de juiste plek gaat. De identiteit van deze website kan echter niet worden bevestigd.
Wat moet ik doen?

Als u doorgaans zonder problemen verbinding maakt met deze website, kan deze fout betekenen dat iemand de website probeert na te bootsen en kunt u beter niet verdergaan.

servername gebruikt een ongeldig beveiligingscertificaat. Het certificaat wordt niet vertrouwd, omdat het uitgeverscertificaat onbekend is. (Foutcode: sec_error_unknown_issuer)
Flags: needinfo?(avihpit)

    
    

    
  
Finally found thr workaround.
first, copy the servername exactly as in the browser, then
Go to Tools > Options > Advanced : Encryption: Certificates - View Certificates > Servers " then 
manual add exception.

Still noidea why the buutto to so so has vanished, but at least now I know how to do this manually.

    
    

    
  
(In reply to Julien Wajsberg [:julienw] from comment #213)
> What's your point?
> 
> Richard's point is: we fixed a bug, you think _your_ bug is not fixed,
> please file a separate bug as this will help make things clearer and fix
> _your_ bug. Continuing discussion in this bug with more than 212 comments
> where most don't have meaningful information or have obsolete information or
> is speaking about different issues, this is not pragmatic.
> 
> Thanks !

ok, just read this, will open a new bug

    
  
Blocks: 1092369

    
    

    
  
(In reply to Suburp from comment #219)
> ok, just read this, will open a new bug

:)
Flags: needinfo?(avihpit)

    
    

    
  
I'm still seeing a similar behavior in Seamonkey/TB and I reported it in bug 1122239.

    
    

    
  
Clear browser history if you connected previously without proxy

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: