-
Enhancement
-
Resolution: Won't Fix
-
P3
-
None
-
7u6
-
x86
-
os_x
The certificate based authentication didn’t work with Webstart at all.
When using an HTTPS connection to a webserver, the server is required to present
a certificate stating what it is. However, it is also possible to set up a
webserver to require the client to also identify themselves. In this case,
the webserver has a list of Certificate Authorities in its configuration that
it uses to validate these certificates.
For instance, a webserver might have a certificate that called “MyKey” and
another one called “MyCA”. The “MyKey” one is used to tell others who it is.
(For example, Amazon has one that says it is ‘amazon.com’)
If the webserver is set up to require certificate based authentication:
The “MyCA” certificate is used by the webserver for validation.
When an HTTPS connection is attempted, the client side needs to produce
a certificate. This is returned to the webserver and the webserver
checks to see if the client certificate was “signed” by “MyCA”.
If it was, the connection is allowed to proceed. If not, the
socket connection is severed.
This type of configuration is used in places like the military. We
have a client where the employees have USB devices (or something) that
have their private certificates on them. When Webstart connects to our
webserver, Webstart comes back an prompts the user to access their card.
They do so, the connection is allowed to proceed, and they can download the jars.
This can also be done without hardware cards, by just by creating certificates
with something like keytool or openssl. Since we have a client that uses feature,
we need to test it. On Windows, Webstart accesses the system to determine
what the certificates are. (You can add certificates directly to Webstart,
but this is not desirable, and, if a hardware device is used, impossible.)
On the MAC, webstart does not seem to know about the system certificates.
It is hard to say exactly what is happening when we try to connect, but the
error is consistent with the webserver cutting the connection because the
client side failed to identify itself.
Incidentally, we tried to add the certificate directly to Webstart,
though the control-panel type thing. That worked. However, this is not
really a solution. For one thing, it make for an annoying user experience
(since they have to set up their certificates in more than one place).
More importantly, however, is that this will not work for keys on
password protected hardware devices.
When using an HTTPS connection to a webserver, the server is required to present
a certificate stating what it is. However, it is also possible to set up a
webserver to require the client to also identify themselves. In this case,
the webserver has a list of Certificate Authorities in its configuration that
it uses to validate these certificates.
For instance, a webserver might have a certificate that called “MyKey” and
another one called “MyCA”. The “MyKey” one is used to tell others who it is.
(For example, Amazon has one that says it is ‘amazon.com’)
If the webserver is set up to require certificate based authentication:
The “MyCA” certificate is used by the webserver for validation.
When an HTTPS connection is attempted, the client side needs to produce
a certificate. This is returned to the webserver and the webserver
checks to see if the client certificate was “signed” by “MyCA”.
If it was, the connection is allowed to proceed. If not, the
socket connection is severed.
This type of configuration is used in places like the military. We
have a client where the employees have USB devices (or something) that
have their private certificates on them. When Webstart connects to our
webserver, Webstart comes back an prompts the user to access their card.
They do so, the connection is allowed to proceed, and they can download the jars.
This can also be done without hardware cards, by just by creating certificates
with something like keytool or openssl. Since we have a client that uses feature,
we need to test it. On Windows, Webstart accesses the system to determine
what the certificates are. (You can add certificates directly to Webstart,
but this is not desirable, and, if a hardware device is used, impossible.)
On the MAC, webstart does not seem to know about the system certificates.
It is hard to say exactly what is happening when we try to connect, but the
error is consistent with the webserver cutting the connection because the
client side failed to identify itself.
Incidentally, we tried to add the certificate directly to Webstart,
though the control-panel type thing. That worked. However, this is not
really a solution. For one thing, it make for an annoying user experience
(since they have to set up their certificates in more than one place).
More importantly, however, is that this will not work for keys on
password protected hardware devices.