230329 - HTTPS/SSL fails for same app if deployed on multiple servers - works on IE - Mozilla likely has trouble picking the right certificate.

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Security: UI, defect)

Description

[Bruno Melloni]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007

I wrote an J2EE application and deployed it to Tomcat 5.  The application uses a
servlet filter & Struts, and enforces the use of HTTPS.  Nothing special so far.
 I deployed the application first on localhost (Win2000) and then on a DEV
server (Solaris).  The application generates very generic HTML and JavaScript
code.  

IE has no problems whatsoever.


No errors (or even attempts at access) show on the DEV server.  Probably because
the HTTPS call fails right away.  My suspicion is that Mozilla is trying to use
the certificate it originally obtained from the localhost when it encrypts the
SSL communication with the DEV server.

Reproducible: Always

Steps to Reproduce:
1. Write and deploy a J2EE application that uses a servlet filter to ensure that
HTTPS is used.  The filter redirects to
https://sameserver:8443/appname/login.jsp or to the original page (if already
logged in).
2. Deploy in localhost Tomcat 5 using self-signed certificate.
3. Access (successfully) with Mozilla and Internet Exploder.
4. Deploy in a DEV server on Tomcat 5 using a self-signed certificate.
5. Access DEV (successfully) with IE, and (unsuccessfully) with Mozilla.
6. No errors show anywhere on the server logs.

Actual Results:  
In localhost, the URL typed (http://localhost:8089/app) is changed to the SSL
form (https://localhost:8443/app) and the login page displays (or the requested
page if already logged in).  This works with both IE and Mozilla.

In DEV, IE works as above, but mozilla shows the proper URL
(https://dev:8443/app) and then it throws an error:

Forbidden
You were denied access because:

Access denied by access control list. 

Expected Results:  
Same behavior as in localhost.

Note:  Problem has been happening since Mozilla 1.4.  I have not experienced
this problem when accessing an application from only 1 server, only when
multiple instances of the application exist.

Analysis: Since no errors ever show on the server logs, it appears obvious that
the problem is happening in the https communication and that the initial SSL
exchange is failing.  Since things work with IE, my suspicion is that somehow
the wrong certificate is being used in the encryption.  Perhaps, Mozilla might
be using the certificate for (app) from the localhost server to encrypt the
communication to (app) on the DEV server.  Or, there might be something
interfering with Mozilla getting the certificate from the DEV server.

Comment 1

[Olivier Cahagne]

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 ?

Comment 2

[Bruno Melloni]

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...

Comment 3

[Olivier Cahagne]

maybe you can attach (remove any security sensitive information if needed) the
output of "openssl s_client -connect yourdevserver:443"

Comment 4

[Hermann Schwab]

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?

Comment 5

[Bruno Melloni]

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.

Comment 6

[Bruno Melloni]

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.

Comment 7

[Mogens Dybaek Christensen]

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.

Comment 8

[Bruno Melloni]

*** This bug has been confirmed by popular vote. ***

Comment 9

[Paul Rubin]

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 10

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

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.