It seems that if you try to navigate to a page with Webclient that uses https and the certificate doesn't completely check out (e.g. the name is different from the server or the authority is not recognized), the Webclient does nothing (it just stays on the current page). I tried this in the application where I'm embedding as well as the EMWindow sample application that comes with it and I got this no-op behavior. If you go to the same site with Mozilla or IE, you get a warning dialog. Note that pages with completely valid SSL certificates seem to load just fine. Try this: go to https://login.yahoo.com This has a valid certificate and should be fine Now try https://mail.yahoo.com Nothing happens Do this in a regular browser and it will inform you that the certificate applies to login.yahoo.com, not mail.yahoo.com, so you must authorize the connection. Note that in both my application and EMWindow the Prompt interface is implemented, but is not brought into play for this certificate situation.
Reporter: Please always specify which "Build ID" you're using, as found in the title bar of the main Mozilla window. Thank you for using Bugzilla!
Oops. Meant to do that. I'm running Gecko/20010726 Netscape6/6.1 with Webclient 1.1 (Win32).
Ed, do you know of any way to deal with this?
This also happened with Mozilla 0.96, there was a MessageBox which told about the invalid certificate, but after confirming nothing happened. On Mozilla 0.98 I receive the following error-message after I confirm: "www.mmc-startup.com ha received an incorrect or unexpected message. Error Code: -12227"
There doesn't seem to have been any activity on this bug since it was reported. I understand the developers are probably very busy with getting Mozilla 1.0 out, but it would be greatly appreciated if someone could confirm or resolve this issue and offer some sort of workaround if there is one, or at least explain why this bug is not getting attention.
This bug is a real problem for me, because I have to use IExploder for pages with questionable certificates. So I can't exclusivly use Mozilla but I'd love to.
You might want to compare against bug 113007 : http://bugzilla.mozilla.org/show_bug.cgi?id=113007 to see if this is a dupe or dependent on that bug. It would be nice to consolidate them if we can.
I guess this bug is a dupe of bug 113007 . However the thing I reported here was about something else and I just "got this bug wrong". So I have added a new bug 143744 , which is about "my" problem.
Clearly this is a duplicate of Bug 113007. Can somebody please mark this one as duplicate.
Is it clearly a duplicate? Many comments in Bug 113007 talk about fixing MFCEmbed. If I understand it correctly, MFCEmbed is just one embedding client, not the main embedding API. Does this problem need to be fixed in each embedding client or is it one fix in the embedding core and everything works? If each needs to be fixed, then this bug applies to the Java Webclient and should remain independent.
marking NEW to get more attention
Hi, my problem may be related to this bug (I am not sure), I have written my own HTTPS server and recognized the following: If I close the socket of the https request after 100 milliseconds of inactivity I can NOT access the page with Mozilla 0.9.7 ... 1.1beta, but if I configure the server to close the socket after 10000 milliseconds I can. With Netscape 4.77 this problem don't occure, and the reason is: At the first access to the server a certificate check is started and this needs a long time (because user interaction is needed), at the end the user accepts the server certificate but the connection is perhaps closed; now: Mozilla don't remember that the user accets the certificate but Netscape 4.77 does. As a result I can connect to the https-page with netscape on the second try but I can't access it on the second try with mozilla because it starts a new certificate acception process with the user.
This bug is related to problems with certificates in Mozilla Webclient, a Java embedding API for Mozilla. From your description, it sounds like your issue may be related to Mozilla in general. Do you have the certificate problem using an embedded version of Mozilla (in which the browser is inside a different application) or using the actual Mozilla browser?
My problem occures with a not embedded version of mozilla, on a SuSE Linux 7.2 Box; and other browser like Netscape 4.77 opera, links, ... don't have this problem
I believe this is my problem as well. I use a self-signed certificate (so login passwords are not sent clear text) for my personal web page. Other browsers (IE, Opera for example) will report the state of the certificate correctly and allow access. Mozilla (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830) reports: Error establishing an encrypted connection to <addr>. error code -8183 Same situation with Netscape 7.0 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0).
Running Mozilla 1.1 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826) on Windows 2000 SP1. May have further evidence related to this bug. I access a site with no valid cert chain. Mozilla (correctly) complains (e.g. "you have attempted to establish a connection with mail.yahoo.com". BUT it then goes on to say "however, the security certificate presented belongs to "Raymond Foulkes 222159". This is MY server certificate stored on MY local smartcard, visible through the security options. It looks like Mozilla is reporting the wrong cert i.e. a local one, not one presented by the https site. Would be nice if it got the cert right and allowed me to OK it (some of our certs not traceable to root authority built into Mozilla). I am not a developer, just a user, so I cannot take part in the "component" discussions.
I sort of have renewed interest in this bug now. I checked the behavior with Webclient 1.3 (and Mozilla 1.0.1 and JDK 1.4.1_03) and it's gotten WORSE! Now, Webclient simply does not connect to SSL sites, regardless of whether the certificate is correct. I would imagine this puts a kink in a lot of projects. I haven't tried this against what's in CVS (I lack the skill to build Webclient), but if SSL doesn't work, I would consider this a showstopper. Have others had problems with SSL? Can someone verify if the problem still exists in a CVS build? I suspect there is a connection between this bug and bug #113007. See comment #10 of this bug for more on that. Interestingly, someone "recently" indicated that 113007 has worsened in the same way as this bug (37th comment of 113007), but no one has yet commented on whether the SSL problem stems from the embedding library or the particular embedding clients (e.g. Webclient, MFCEmbed, etc.). Any feedback on this issue would be much appreciated, especially a sense of when this might get some attention.
Hi M. Epstein, Can you please specify steps to reproduce your problem? I want have a look into the probem. I have found that the Webclient application hangs while accessing https pages when cookies dialog is displayed in the demo application, but if have cookie accepted and offered to remember it works without problem. And I have found it also hang when password save dialog appears in https page. Off course for invalid certificate nothing happens. I think the embedded clients(like Webclient etc) need to handle this situation based on some event. I am using a) Webclient 1.3 b) JRE 1.4.1_05 c) MOZILLA 1.0.1 FYI: I have juts compiled webclient in cvs against MOZILLA 1.4 but I feel it is not stable as 1.3. I am in process of testing it.
To reproduce this problem: 1. Start the Webclient test application (if installed according to its instructions, this is located in the Mozilla directory under bin\javadev\example) by double-clicking its runem.bat file. 2. In the application's location bar, type in a URL for a site with a known problematic certificate, e.g. https://mail.yahoo.com. 3. Note that nothing happens (at least in Webclient 1.3 with Mozilla 1.0.1). To address some of your other questions and comments: We have found Webclient 1.2 often hangs if a modal dialog is displayed (on non-secure sites). We've gotten around this problem by displaying the dialogs in a separate thread. Interestingly, the cookie dialog appeared while using Webclient 1.3 to reproduce this bug and it did not hang the application. It's possible the certificate problem is rooted deeper in the Mozilla embedding infrastructure. Have a look at bug # 113007 for some discussion on that. I'm glad to hear work is going towards getting Webclient working with newer versions of Mozilla.
I finished testing the latest webclient compiled with mozilla 1.4 and it is quite unstable. I could reproduce the certificate problem. As mentioned it has gotten worse in latest version of webclient with jdk1.4+. Now you can't visit a page https page itself . I get the following error when visiting HTTPS page ---> WARNING: no registered socket provider. I suspect some PSM problem. I don't think Mozilla embedding has problem as off mozilla version 1.4. As i have found "mfcembed" works perfectly when visiting site like https://mail.yahoo.com, It shows appropriate message as the normal browser would do. edburns has published webclient2.x design, but i don't know when he would start it. I am thing of implementing webclient based on how "mfcembed" is implemented. Any suggestion would be realy helpfull.
I don't know a whole lot about Mozilla's embedding architecture, so I couldn't make informed suggestions for improvements but it would definitely be nice to see some of the stuff in CVS (e.g. the Selection API) made available and it might be easier to integrate new browser features quickly if the Java-to-XPCOM bridge were revived (see http://www.mozilla.org/projects/blackwood/connect/), but this discussion is probably best suited to the Mozilla Java newsgroup (netscape.public.mozilla.java or firstname.lastname@example.org) instead of this bug. If possible, it's probably better to try to work with the existing Webclient as opposed to making a rival one.
Created attachment 155706 [details] [diff] [review] Small fix to reproduce this with TestBrowser app Webclient 2.0 a1 TestBrowser app won't load *any* https page with the following error printed at the console: [java] WARNING: no registered socket provider, file .../mozilla/netwerk/base/src/nsSocketTransport2.cpp, line 751 To reproduce: 1. Apply attached patch so that TestBrowser class passes https URLs down to Webclient API. 2. ant.bat run.test.browser (make sure it rebuilds TestBrowser.java!) 3. Type in https://login.yahoo.com/ -- nothing happens in the browser, the above error message is printed in the terminal Win2k, MOZILLA_1_6_RELEASE, Webclient 2.0 a1.