-
Enhancement
-
Resolution: Won't Fix
-
P4
-
None
-
6
-
x86
-
windows_xp
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)
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)