Submitted On 20-JAN-2001
I have requested SOCKS support (Bug 4348805) and it would
be trivial to provide HTTPS support at the same time.
Submitted On 10-SEP-2001
Between the votes here & the comments on the JWS Forum, it
should be quite apparent that support for HTTPS in JNLP
codebase is needed. One simple example is where the client
is using OS user accounts w/HTTPS access and Basic Auth to
protect the JWS app load page. In this case, the JWS app
codebase access needs to use HTTPS to assure the
username/password entries are encrypted. Perhaps there are
workarounds in this case, but why bother.
Also, for sensitive data apps, it might be nice for the
source JAR to be encrypted over the wire (then used/stored
locally unencrypted, of course).
Submitted On 11-SEP-2001
Any e-commerce site these days uses HTTPS.
Submitted On 13-SEP-2001
Update: This problem should probably be ranked behind the
greater problems JWS has with its modal basic auth dialog /
update checking / cached app startup interaction.
Upon further testing, we find JWS & Basic Auth pretty much
unusable because the launched cached app can overlay the
modal Basic auth window & the app will appear frozen.
Developers can use Alt-Tab, but users won't... They'll just
reject your app.
As discussed in the Eval of:
The JWS team will likely need to investigate & propose
solutions to the problems related to launching an app
originating (and cached) from a Basic Auth-protected page.
Submitted On 15-JAN-2002
I have no workaround, rather a statement. How can
developers even begin to use this technology when it does
not support HTTPS for something as simple as a codebase?
This seems very minor and should be an easy fix... so why
isn't sun doing anything about it?
Submitted On 23-JAN-2002
Lack of https support totally kills jnlp viability in a
defense department environment. There are many DoD and DoD
contractor networks that do not allow unencrypted data to
exist on the network. All the pieces are in place for this
to be supported, they just need to be glued together.
Submitted On 05-FEB-2002
This is a major security hole, without this support,
passwords are sent in the clear if download authentication
is required, thus we can't perform authentication, meaning
that a hacker could easily download our app, reverse
engineer and cause major hassles.
Please fix this ASAP.
Submitted On 26-FEB-2002
Why is this close? The problem is not resolved!!!! Because DoD is become more restrictive having the JNLP
files run on HTTPS is mandator. It seem like the people on the Web Start project are lazy.
Submitted On 26-FEB-2002
JWS gave a great deal of features that we, our app team,
were looking for over the plugin. But missed out the
biggest of all.. "https"..
Should we be waiting for a fix from sun or completely
forget about JWS???
Submitted On 05-APR-2002
I totally agree with some other comments. Many DoD
establishments require HTTPS whether we developers, or Sun
like it or not. This essentially freezes out what should be
a useful technology within DoD. I suspect that many
commercial shops have adopted this as well.
Submitted On 26-MAY-2002
Perhaps the web-start folks are not lazy, just off working on totally separate
Is the web-start development team still active?
Submitted On 14-AUG-2002
HTTPS codebase is still not supported. Please reopen and fix
this critical missing functionality.
Submitted On 23-AUG-2002
Hey, check 1.4.1-rc... Looks like HTTPS codebase & z-order
basic auth dialogs bugs are fixed.
Submitted On 29-AUG-2002
Hi I am still able to reproduce this bug with
j2se 1.4.1 RC
Can someone verify if this bug is closed
I still get exception
java.security.cert.CertificateException: Intermediate X.509v3
without basic constraints extension
Submitted On 27-JAN-2003
Please reopen this issue. As of JDK 1.4.1_01 it is not "fixed".
Just because your project manager "deems this to be a non-
critical issue" doesn't mean the issue is closed. Leave it
active as a RFE.
If you count the votes and comments here, and search the
forums, you will see that MANY Web Start users need SSL
support when downloading jars simply because they are
required to use that protocol.
Submitted On 12-MAR-2003
Has this been fixed? If yes, in which release of JRE/JWS?
Submitted On 04-JUN-2003
Here's the error from JWS 1.2.0_01 (FOR DST Certificate)
java.security.cert.CertificateException: Could not find trusted
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.security.cert.CertificateException: Could not
find trusted certificate
... 20 more
Submitted On 07-JUL-2003
kind request from vijay.
Respected SUN JAVA team,
I use to argue with my friends about JAVA working style.
But they use to say that JAVA taking time for producing
output.Whether it is possible to reach Performance
Thanks for considering
Submitted On 24-SEP-2003
This problem hasn't been resolved, has it?
Webstart 1.2, JDK 1.4.1, Windows NT - I still experience
Submitted On 26-SEP-2003
In JRE 1.4.1 and webstart 1.2, you can use HTTPS, however
you will get CertificateNotFound exception if your site https
certificate is not found in the JRE cacerts file.
In Javawebstart 1.4.2 (comes with JRE 1.4.2), this problem is
solved by the new dynamic https certificate support. If
javawebstart encounter a https site with a cert not in the jre
cacerts file, javawebstart will pop up a dialog and ask the
user whether they want to accept the cert and continue the
connection. THis is similar to connecting to a https site with
a web browser.
PLEASE NOTE: JDK6 is formerly known as Project Mustang