is it possible to move J2EE out of the equation and use static html pages directly accessed in SSL ? What happens when you access https://dev:8443/app and https://dev:8443/app/ (note the trailing slash) with Mozilla ?
I just tried to do an https call leaving out the application altogether. - I first accessed the documentation that comes with Tomcat 5 at http://<dev>:8089/tomcat-docs. It worked fine. - Then I tried it with https://<dev>:8443/tomcat-docs. It failed in the same way, with the access denied message. So, the problem really has nothing to do with the application. It is in the communication between Mozilla and Tomcat. From my continued research I am wondering if it is possible that the default self-signed certificate created for Tomcat by the JDK 1.4.2 on Solaris might use a key type that is not supported by Mozilla...
maybe you can attach (remove any security sensitive information if needed) the output of "openssl s_client -connect yourdevserver:443"
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57436 A Class 3 and Class 2 Verisign PCA root certificate included in various releases of the SDK and JRE (see Contributing Factors below) will expire on January 7, 2004 and may result in the following upon expiration: ... maybe it is related, or you can find some more info there about the certificates used?
Additional info/questions: 1) Accessing https://DEV:8443/tomcat-docs and https://DEV:8443/tomcat-docs/ (trailing /) both return the Forbidden...Access Denied error. http://DEV:8089/tomcat-docs functions. 2) Olivier suggested I attach the output of "openssl s_client -connect yourdevserver:443" to this log. Is openssl included somewhere in the Windoze distribution of Mozilla? I tried to access the openssl.org binaries for windows link and it appears to be broken. 3) The Verisign root certificate issue is probably a problem, but should not be relevant to this issue, since this problem has been occuring since mid-December (back then on Mozilla 1.4). 4) The DEV box JRE (as shown by java -version) is 1.4.2_03-b02, with HotSpot Client VM 1.4.2_03-b02 mixed mode. 5) The localhost (windows, where localhost Tomcat server and Mozilla reside) has been (at least on one of the client PCs) 1.4.2_02-b03 and HotSpot 1.4.2_02-b03. Mozilla's "About Plug-ins" shows the JRE to be 1.4.2_02-b03. I will fully upgrade the localhost's Java to 1.4.2_03 (which should also fix the Verisign certificate on localhost) and report. 6) We did some additional tests with other browsers: Netscape 4.5, 4.75 and 7.?. They all worked fine.
I upgraded the JDK on localhost to 1.4.2_03. Now all machines are on the same. All other browsers still work, and Mozilla still fails with DEV but not localhost. I tested accessing localhost with Mozilla from a different machine, and in that case Mozilla fails with localhost. So, perhaps localhost was working with Mozilla but only because it was on the same computer.
I am running Mozilla 1.6 (backported) on a Debian woody system. I think I can confirm this bug. I have 2 accounts at the same web hotel. Both servers (different machines) use Plesk as the adminstrative interface. They have the same certificate, originally issued to Plesk, which has now expired. To get access to the newest account on the second server, I had to delete the Plesk entry from Certificate Manager. Then I could log in by accepting the certificate twice. "Only for this session" was used. After looking around there, I tried to access the older account. I was prompted to accept the certificate, and said OK for this session. Then I got a pop up: ------------------------------------ Alert two.zzz.dk received a message with incorrect Message Authentication Code. If the error occurs frequently, contact the website administrator. ------------------------------------ I crosschecked with IE, and it works fine. I can get to both servers in the same session. A search at Bugzille showed this bug, which seems _very_ similar.
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: general → kaie
Component: Browser-General → Client Library
Product: Seamonkey → PSM
QA Contact: general
Version: Trunk → unspecified
This issue has been around since the netscape 4.01 era. It's not really a bug, it only happens in these weird situations where you're trying to use two different certs with the same CN. The workaround is to clear your browser cache, shut down and restart your browser.
Comment 7 does not describe the same symptoms as comment 0, and would appear to be a different bug. In any case, the servers mentioned in these reports are so old that this likely isn't an issue any longer. If that's not the case, please open a new bug in Core :: Security: PSM.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.