This sounds like something a bug needs to be filed on. If you have openssl, can you do:
openssl s_client -connect 192.168.168.132 -showcerts and send the dump thereof? My instant thought is that there might be an IP address in a subjectAltName entry of type dNSName, or an IP in the Common Name (CN=) of the certificate. There's no way to know without seeing the certificate that's being misinterpreted. -Kyle H On Sun, Jun 26, 2011 at 11:55 AM, Menno Hershberger <[email protected]> wrote: > I am pasting a post I made on June 7th in the mozilla.support.firefox > group. Someone in that group suggested I bring the problem here. I'll add > a bit at the end... > ---------------------------------------------------------------------- > Our telephone company controls equipment by accessing the card slots > (called "Blades") via webserver. The blades and software come from Occam > Networks. Each blade is assigned a local IP. The first time we accessed > each blade we had to go through the invalid certificate routine and then > add the exception and all was well from then until just the last couple > of days. Now, on some of the blades, we're getting "server down" and when > we refresh the screen we get the certificate untrusted screen. Then when > we attempt to add exception, we get another screen telling us that the > site is valid and there is no need to add an exception. The only button > left to push is Cancel. > > Please view http://mewnlite.com/getcertificate.jpg for clarification. > > OK. We have three computers we use on this equipment. > > On one of them I uninstalled Firefox 4.0.1 and deleted the associated > data folders and then installed Firefox 3.6.16. After adding all the > exceptions we can now access all the blades properly. > > On the second one I did same as above except I reinstalled Firefox 4.0.1. > And everything works. > > The third one is MY computer and I really really don't want to uninstall > and reinstall Firefox due to the amount of add-ons, theme, etc. I have. I > exported my passwords and bookmarks, then renamed cert8.db, key2.db, and > secmod.db. Since these are supposedly the files that store all the > certificate data, I thought this would start me out with a clean slate. > But no, it's doing the same things on the same blades. > > I've called Occam and find that they're getting these complaints from > phone companies all over starting just a few days ago. And they're > working on it. > And I always hate to add this, but "it works in Internet Explorer" only > by pressing "Continue to this website anyway (not recommended)" > > The Occam Company has always recommended Firefox. Our own company uses > Firefox. And *I* use Firefox! :-) > > Does anyone know of a way where we can just bypass the certificates > altogether? This is an in house system so there shouldn't be any security > problems. > ---------------------------------------------------------- > Since I posted this Firefox upgraded to 5.0 without even asking. If I > can't get this resolved soon we'll probably just switch over to IE. > Surely someone knows what file is holding that information. If I could > just delete or rename it, then add all the exceptions again, it would > sure beat uninstalling, deleting data folders, and reinstalling. > > Help would be greatly appreciated! > > -- > -- I'm out of white ink -- > > _______________________________________________ > dev-security mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
