Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4304940

Network test suite is not verifying X-mited certificates with those stored local

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not an Issue
    • Icon: P3 P3
    • None
    • 1.0
    • security-libs
    • None


      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.

            ywangsunw Yingxian Wang (Inactive)
            wetmore Bradford Wetmore
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: