Description of problem: Accessing SSL/TLS protected services from an application distributed as a JNLP file, results in an exception: "java.security.NoSuchAlgorithmException: SunTlsRsaPremasterSecret KeyGenerator not available" This happens no when the application request full permissions (<all-permissions/>), so is not a problem of security restrictions Version-Release number of selected component (if applicable): java-1.6.0-openjdk-1.6.0.0-52.1.9.6.fc14.x86_64 How reproducible: Always Steps to Reproduce: 1.Start an application that access SSL/TLS services, simple example at: javaws http://marcanoonline.com/downloads/fedora/bugs/javaws_ssl/test.jnlp 2. the applications request authorization because it request all permissions, 3. grant the request 4. the exception is shown on the console Actual results: Start... javax.net.ssl.SSLKeyException: RSA premaster secret error at sun.security.ssl.RSAClientKeyExchange.<init>(RSAClientKeyExchange.java:116) at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:703) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:228) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:610) at sun.security.ssl.Handshaker.process_record(Handshaker.java:546) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:913) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1158) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1185) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1169) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:440) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139) at java.net.URLConnection.getContent(URLConnection.java:705) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getContent(HttpsURLConnectionImpl.java:426) at java.net.URL.getContent(URL.java:1043) at com.example.BugTestcase.main(BugTestcase.java:9) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:461) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:732) Caused by: java.security.NoSuchAlgorithmException: SunTlsRsaPremasterSecret KeyGenerator not available at javax.crypto.KeyGenerator.<init>(KeyGenerator.java:141) at javax.crypto.KeyGenerator.getInstance(KeyGenerator.java:191) at sun.security.ssl.JsseJce.getKeyGenerator(JsseJce.java:240) at sun.security.ssl.RSAClientKeyExchange.<init>(RSAClientKeyExchange.java:108) ... 21 more Expected results: Print on console Start... End... Additional info: Source of the test case is on the same directory of the JNLP file, bypassing security using the javaws option -nosecurity workaround the problem, but the desktop of the applications icon is not generated with that option and it is regenerated every time
Correction, "desktop icon of the application"
We need to know which algorithm is being requested. It may be elliptic curve cryptography which can't be shipped in Fedora due to possible patent issues.
(In reply to comment #2) > We need to know which algorithm is being requested. It may be elliptic curve > cryptography which can't be shipped in Fedora due to possible patent issues. I am sure it is not related to patents, let me detail more: the following fails (after granting access to my self signed certificate): javaws http://marcanoonline.com/downloads/fedora/bugs/javaws_ssl/test.jnlp the following works: javaws -nosecurity http://marcanoonline.com/downloads/fedora/bugs/javaws_ssl/test.jnlp the sample code only do this: new URL("https://www.redhat.com/").getContent(); a simple HTTPS request, no fancy crypto. I think the bugs is related to the latest changes to netx and must be a classloader problem when the security manager is active (see above, with option -nosecurity works) Sample is at http://www.marcanoonline.com/downloads/fedora/bugs/javaws_ssl/src/com/example/BugTestcase.java, example provided as a binary in order to be able to sign it and grant all permissions
(In reply to comment #2) > We need to know which algorithm is being requested. It may be elliptic curve > cryptography which can't be shipped in Fedora due to possible patent issues. it's SHA1withDSA, at least for IcedTea6-1.7.5
There was a similar bug a while back: https://bugzilla.redhat.com/show_bug.cgi?id=524387. I have a potential fix; let me check first with Deepak if it makes sense to him.
Fixed upstream: http://icedtea.classpath.org/hg/icedtea-web/rev/11a9a305dd44
icedtea-web-1.0.2-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/icedtea-web-1.0.2-2.fc15
icedtea-web-1.0.2-2.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
No plans to update Fedora 14? this is an awful bug that kills all the advantages of distribute Java applications using JNLP. adding the need to define a local icon with command line arguments to bypass the sandbox, even if the app does not requires full privileges