-
Bug
-
Resolution: Not an Issue
-
P3
-
None
-
1.0
-
None
-
generic
-
generic
bradford.wetmore@eng 2000-01-14
The following information was moved from the evaluation section
of 4302483. That bug was to track a condition where an
expired root certificate caused the SSL handshake to fail.
It was initially thought that this might be related to that
bug, but upon further investigation, it was determined that
this bug was failing a verification step, not
date checks. The externally visable stack traceback is exactly the same,
because the function that caused this is a simple boolean function.
In src/share/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl.java:isTrusted(),
there is a call to chain [i].verify(issuer.getPublicKey()). issuer
was previously set by calling getTrustedCertificate(issuerName),
where issuerName is the DN that comes out of the certificate
being passed. The issuer eventually is set to that value stored
in the local keystore.
verify() is throwing the below exception, which causes isTrusted() to return
false, which throws the externally visable exception back in
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate()...
java.security.SignatureException: Signature does not match.
at sun.security.x509.X509CertImpl.verify(X509CertImpl.java, Compiled Code)
at sun.security.x509.X509CertImpl.verify(X509CertImpl.java, Compiled Code)
I didn't go into the jdk to determine which of the verify() function
calls is generating the exception.
The information about the test suite follows:
Setup a JSSE/JDK enviroment. I did a production version of
JDK 1.2.2, and a domestic version of JSSE 1.0. Set $JAVA_HOME to
the JDK directory.
The Test suite is located in /net/sqesvr/vsn/jsse-ts. In this directory,
there are two test directories, 4302483-server, and 4302483-client.
Setup two windows, one for each test directory.
On Both:
cd src/Authentication
Client:
./run_auth_client
Server:
./run_auth_server
It's my gut feeling that the cert database might be out of
sync between the client and server, but Dan didn't think so.
He has more knowledge of the database setup than I do.
What follows is Dan's original test and bug describption from 4302483.
daniel.daugherty@Eng 2000-01-05
I have been able to reproduce this bug using the JSSE product test suite:
- make two copies of the test suite (jsse-server and jsse-client)
- link the client's results directory to the server's results directory
- create a testkeys file with initial valid date before 1/1/2000 and
ending valid date after 1/1/2000
- create a testkeys file with initial and ending valid dates after
1/1/2000
Run the Authentication sub-area with the following testkeys configs:
jsse-server jsse-client Auth
testkeys testkeys results
----------- ----------- -------
pre-Y2K pre-Y2K PASSed
post-Y2K post-Y2K PASSed
pre-Y2K post-Y2K FAILed
post-Y2K pre-Y2K FAILed
For the pre-Y2K testkeys file, I used one with an initial valid
date of 10/27/1999 (through 10/26/2000). For the post-Y2K file,
I used one with an initial valid date of 1/5/2000 (through 1/4/2001).
Using the pre-Y2K testkeys file on both server and client with
a system date of 1/5/2000 PASSed. This shows that the pre-Y2K testkeys
file is valid on 1/5/2000. Using the post-Y2K testkeys file on both
server and client with a system date of 1/5/2000 PASSed (this is what
normally happens).
However, using pre-Y2K on one machine and post-Y2K on the other machine
FAILed in either combination:
10/27/1999 10/26/2000
|------------------------------------|
1/5/2000 1/4/2001
|-------------------------------|
^ 1/1/2000
The problem appears to be because the initial valid date
fall on either side of 1/1/2000.
daniel.daugherty@Eng 2000-01-05
After discussion with Satya, I tested two more configs:
jsse-server jsse-client Auth
testkeys testkeys results
----------- ----------- -------
12/1/99 pre-Y2K FAILed
1/1/2000 post-Y2K FAILed
The 12/1/99 testkeys file is valid from 12/1/99 through 12/1/2000.
The 1/1/2000 testkeys file is valid from 1/1/2000 through 1/1/2001.
It appears that any mismatched beginning validity date will result
in a failure. This last test was done with the system date set to
1/5/2000 and 12/25/1999.
- relates to
-
JDK-4302483 SSLException occurs in URLReaderWithOptions example program
-
- Resolved
-