[JDK-8108891] support https access to the dl.javafx.com Created: 2010-01-26  Updated: 2015-06-16  Resolved: 2010-03-22

Status: Closed
Project: JDK
Component/s: deploy
Affects Version/s: None
Fix Version/s: fx1.3

Type: Bug Priority: P2
Reporter: Igor Nekrestyanov (Inactive) Assignee: Thomas Ng (Inactive)
Resolution: Fixed Votes: 0
Labels: soma-yes-b30, sqe-verified
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Subcomponent: javafx

Here is the original report:

The site we build that uses JavaFX runs over 'https':

However the html (or rather 'php' page) that loads javafx uses 'http':

Because of this, IE8 (on Windows XP) produces the following warning popup:

Do you want to view only the webpage content that was delivered securely?
This webpage contains content that will not be delivered using a secure HTTPS connection, which could compromise the security of the entire webpage.
[ More info ] [ Yes ] [ No ]

When pressing 'Yes', JavaFx won't load.
The debug sessions complains:
Error: Object expected

and points to:

<script type="text/javascript">

I've tried loading 'dtfx.js' over https, but that doesn't work

Do you have another URL that will load 'dtfx.js' over ssl?
We're using JavaFX 1.2 .

We need to provide solution for such users.

Comment by Rinaldo DiGiorgio (Inactive) [ 2010-03-04 ]
Adding this ability requires that we identify all of the urls. Assuming that it is one or just dl.javafx.com will get us into trouble. Here is the proposed plan. Create a version of war that runs on dl.javafx.com and run it in ssl mode on ccdev-sca11-06 and verify that all of the urls work including any potential interactions with Akamai and LL .

1) Ask Operations if they will terminale SSL
  if they do not and we need to terminate SSL in the GF isntance we will experience a signifincat performance reduction and may require more machines or servers with SSL HW

2) Verify that no cert change is needed at Akamai and LL
  Ask Stamos how long that would take.

2 May not be needed but needs to be investigated.

So the tasks to complete this with some of them optional are listed below

1) Verify that application works with self signed or pki.central internal certs ( 1 day )
2) Operations verifies that they install a cert on LB and what the lead time for them to do that is Will Thornburg Will this be in Austin, 365 or both
3) if we need to terminate SSL new performance numbers and impact (3 days)
4) Akamai and LL if needed what thier time is
5) if more are needed lead tiem from Operations

Comment by Igor Nekrestyanov (Inactive) [ 2010-03-04 ]
NOTE: we do NOT want complete runtime to be served over https. This is because:
    1) https will add overhead (and jre might be not that stable with https/update checks/etc)
    2) FX preload works for http only and using https will require full runtime download and 2 versions of runtime in the cache
We only need to serve whatever is needed by browser, i.e.
     - javascript files
     - images
from the original war file.

And we need to make sure that js will generate correct links to jars/jnlp even if dtfx.js was loaded over https
(using http protocol).

This also means that we do not need to redirect https requests to CDN.

Ideally we should be using same certificate as we use to sign FX runtime (to avoid second security dialog).
I do not not know if this is technically possible to reuse this certificate for https.
Comment by Rinaldo DiGiorgio (Inactive) [ 2010-03-04 ]
I understand the goal, I want to verify that it works as expected for the user using IE. I want to verify that no t browser content has leaked to any CDN or other server.

Your comment about "Ideally we should be using same certificate as we use to sign FX runtime (to avoid second security dialog).
I do not not know if this is technically possible to reuse this certificate for https. "

is probably beyond our current capabilities. I know of no one that has done this. I have spoken to several engineers at Sun and a contact at Verisign. I am researching one more lead. There is some integration with the Browser security files and the java keystore that may not exist. I worked on such a project many years ago where we wanted the java card to be used for the keystore by both the java run time and the browser. So this is unlikely but -- Obviously if the security still worked it would be a step forward.
Comment by Thomas Ng (Inactive) [ 2010-03-22 ]
this should complete all the runtime changes needed for SOMA for HTTPS support:


will create another JIRA for infrastrucuture changes only
Comment by Thomas Ng (Inactive) [ 2010-03-22 ]
fix is in jdeploy scrum now.
Comment by Srikalyan Chandrashekar (Inactive) [ 2010-03-31 ]
Installed test certificates signed by verisign in javafx-dl1 server , deployed JavaFX.war (b31 which uses soma #386) , setup an applet that
1) streams both dtfx.js and javafx-rt.jnlp via https -------- This works
2) streams dtfx.js viz https and javafx-rt.jnlp viz http ------ This works too
Case 1 gets even the jar files through https
Case 2 gets jar files through http

Tested on
both IE8 and Firefox - Windows
Safari - Mac

However we had to set a system property javafx.deploy.nondefaultport=8080 in the glassfish so that servlet explicitly sets the http port which otherwise uses default 80 only in case of older plugins in Mac(typically) .
Comment by Malathi Narayanan (Inactive) [ 2010-05-04 ]
Verified using Soma b31 by Srikalyan
Generated at Sat Aug 24 02:53:36 UTC 2019 using Jira 7.13.5#713005-sha1:8d78f1047b9cca7d35d4d13f706b37e27d869e07.