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

Deployment products should call SSLContext.setDefault()

    • Icon: Enhancement Enhancement
    • Resolution: Won't Fix
    • Icon: P4 P4
    • None
    • 6
    • deploy

      J2SE Version (please include all output from java -version flag):
        java version "1.6.0-beta2"
        Java(TM) SE Runtime Environment (build 1.6.0-beta2-b86)
        Java HotSpot(TM) Client VM (build 1.6.0-beta2-b86, mixed mode, sharing)

      Does this problem occur on J2SE 1.4.x or 5.0.x ? Yes / No (pick one)
        Yes

      Operating System Configuration Information (be specific):
        Windows XP

      Hardware Configuration Information (be specific):
        Sony VAIO Laptop

      Bug Description:


      Background:
      -----------
      We have a client who, as a corporation, uses ActivIdenity smart cards.
      They use the card to, among other things, hold the personal
      certificates needed to establish SSL connections.

      We were not sure if webstart 5.0 would work in this environment and were
      very pleased that it did. It just worked out of the box. The users
      were prompted to put in their card and enter their PIN just like they
      were used to. The dialogs that came up appeared to be the same as the
      ones that appear when they try to establish a connection in Internet Explorer.

      From their descriptions, I am guessing that the webstart does not use
      a browser keystore "file" so much as an API call that causes IE (or
      MSCAPI) to do its thing.

      And although I am very pleased that it is working, I am not sure it is
      working be design and that it will continue to work. I know you strive for
      compatibility between versions, but (and this caused me problems before) you
      do feel free to declare a behaviour a bug then change it.

      We are working hard to get a test environment set up here, but our client
      is not being very forthcoming in the regard. Because of this, we have not
      had an opportunity to test 5.0->6.0 compatibility in this area.

      Issue:
      ---------
      We are planning to use the apache HTTPClient in the next version of
      our software. However, we would like to be able to initialize the
      SSLContext with the KeyManager and TrustManager that webstart uses.
      This will ensure that if webstart can connect, so can we.

      There are no API's for doing this and I believe it is critical that
      there are, otherwise there is no way to propertly initialize an
      SSLContext

      I know it is late in the game for Mustang, but certificate requirements
      are rapidly becoming more prevalent. As this happens, the fact that there is
      no API for interfacing with webstart's context is going to be more and more
      of a frustration and serious issue.

      I feel Java needs to react swiftly
      on this issue to ensure that solutions are possible.
      If a client (like
      the government) spontaneously institutes a mandate that cannot be met
      using standard Java libraries, providers are forced to make difficult
      decisions...sometimes with near-intractably small time windows.

      I brought up this issue at JavaOne 2006 to both the webstart and security teams
      and did not get the sense that this issue (initializing the SSLContext) was really
      being addressed by either team.


      Possible Solutions:
      -------------------
      1) Having an API call to retrieve the TrustManager and KeyManager objects
      2) Having an API call to get an initialized SSLContext from webstart
      3) Have the default KeyManager and TrustManager be the ones that webstart uses

      As a workaround in 5.0, it is possible to instantiate the com.sun.deploy.security.X509DeployKeyManager
      and the com.sun.deploy.security.X509DeployTrustManager directly. However this is
      not documented, and doesn't not work in 6.0 beta2
      Furthermore, this seems to only work when running accessing the application via webstart.
      In my development environment, not running through webstart, it behaves differently.

      Steps to Reproduce (be specific):

      static SSLContext getSSLContext() throws IOException {
      TrustManager trustManager = getTrustManager();
      KeyManager keyManager = getKeyManager();
      SecureRandom secRand = null;

      try {
      SSLContext context = SSLContext.getInstance("SSL");
      context.init(new KeyManager[] {keyManager}, new TrustManager[] {trustManager},secRand);
      return context;
      }
      catch (KeyManagementException ex) {
      throw new ConnectErrorException(ex);
      }
      catch (NoSuchAlgorithmException ex) {
      throw new ConnectErrorException(ex.getMessage());
      }
      }
      private static KeyManager getKeyManager() throws ConnectErrorException {
      KeyManager rval = null;
      if (!usingDevelopmentEnvironment()) {
      try {
      Class c = Class.forName("com.sun.deploy.security.X509DeployKeyManager");
      Object o = c.newInstance();
      LogManager.log(o.toString(),Level.DEBUG_5);
      rval = (KeyManager)o;
      }
      catch (Exception e) {
      LogManager.log(e,Level.ERROR);
      }
      }
      return rval;
      }
      private static TrustManager getTrustManager() {
      TrustManager rval = null;

      boolean useTrustEverythingManager = usingDevelopmentEnvironment();

      if (useTrustEverythingManager) {
      rval = new TrustEverythingTrustManager();
      }
      else {
      double d = Double.parseDouble(System.getProperty("java.specification.version"));
      if (d < 1.6d) {
      try {
      Class c = Class.forName("com.sun.deploy.security.X509DeployTrustManager");
      Object o = c.newInstance();
      LogManager.log(o.toString(),Level.DEBUG_5);
      rval = (TrustManager)o;
      }
      catch (Exception e) {
      LogManager.log(e,Level.ERROR);
      }
      }
      else {
      try {
      Class c = Class.forName("com.sun.deploy.security.X509ExtendedDeployTrustManager");
      Object o = c.newInstance();
      LogManager.log(o.toString(),Level.DEBUG_5);
      rval = (TrustManager)o;
      }
      catch (Exception e) {
      LogManager.log(e,Level.ERROR);
      }
      }
      }
      return rval;
      }


      Exception in 6.0
      at com.sun.deploy.security.X509ExtendedDeployTrustManager.isSupportedAlgorithm(Unknown Source)
      at com.sun.deploy.security.X509ExtendedDeployTrustManager.checkServerTrusted(Unknown Source)
      at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown Source)
      at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source)
      at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
      at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Unknown Source)
      at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source)
      at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
      at java.io.BufferedOutputStream.flush(Unknown Source)
      at org.apache.commons.httpclient.ChunkedOutputStream.flush(ChunkedOutputStream.java:190)
      at org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:502)
      at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1973)
      at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:993)
      at dsi.joint.io.ApacheDConnection.sendSinglePart(ApacheDConnection.java:121)

            herrick Andy Herrick (Inactive)
            tyao Ting-Yun Ingrid Yao (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: