Java Web Start (JWS) says that it can't launch my application because the jar file is unsigned:
Error: Unsigned application requesting unrestricted access to system
Unsigned resource: .../dynaccn.jar
But the jar file is signed:
$ jarsigner -keystore ... dynaccn.jar idv
$ jar tf dynaccn.jar
META-INF/MANIFEST.MF
META-INF/IDV.SF
META-INF/IDV.RSA
META-INF/
edu/
edu/ucar/
edu/ucar/unidata/
edu/ucar/unidata/dynaccn/
App$1.class
...
$ jarsigner -verbose -certs -verify dynaccn.jar
28325 Tue Aug 17 09:41:58 MDT 2010 META-INF/MANIFEST.MF
28404 Tue Aug 17 09:41:58 MDT 2010 META-INF/IDV.SF
2880 Tue Aug 17 09:41:58 MDT 2010 META-INF/IDV.RSA
0 Tue Aug 17 09:41:58 MDT 2010 META-INF/
0 Mon Aug 16 10:10:34 MDT 2010 edu/
0 Mon Aug 16 10:10:34 MDT 2010 edu/ucar/
0 Mon Aug 16 10:10:34 MDT 2010 edu/ucar/unidata/
0 Mon Aug 16 10:10:34 MDT 2010 edu/ucar/unidata/dynaccn/
...
sm 486 Mon Aug 16 10:10:34 MDT 2010 App$1.class
X.509, CN=University Corporation for Atmospheric Research, OU=UNIDATA, O=University Corporation for Atmospheric Research, L=Boulder, ST=Colorado, C=US
[certificate will expire on 2/6/11 4:59 PM]
X.509, CN=Thawte Code Signing CA, O=Thawte Consulting (Pty) Ltd., C=ZA
[certificate is valid from 8/5/03 6:00 PM to 8/5/13 5:59 PM]
[KeyUsage extension does not support code signing]
X.509, EMAILADDRESS=premium-server#thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
[certificate is valid from 7/31/96 6:00 PM to 12/31/20 4:59 PM]
[CertPath not validated: null]
...
jar verified.
Warning:
This jar contains entries whose signer certificate's KeyUsage extension doesn't allow code signing.
This jar contains entries whose signer certificate will expire within six months.
This jar contains entries whose certificate chain is not validated.
This jar contains signed entries that's not signed by alias in this keystore.
and both JWS and my browser have a certificate for "Thawte Premium Server CA".
The problem occurs even if the JWS cache and the browser download area are empty.
I don't believe the "KeyUsage" message is relevant because 1) the same certificate chain is used for another application that does launch successfully; and 2) documentation I've read indicates that the Thawte Code Signing CA is only used to verify the UNIDATA certificate and not to sign code.
My environment is Linux 2.6.27.41-170.2.117.fc10.x86_64, Firefox 3.6.8 (i686), and Java 1.7.0-ea.
Why won't this application launch?
UPDATE: I've discovered that the application launches if the "codebase" attribute in the JNLP file references a local directory but not if it references a URL that lies behind user authentication. In the latter case, javaws(1) interprets the authentication webpage as a JNLP file (with obvious results) if invoked from the command-line. If invoked by the "deployJava" script from a user-authenticating webpage (so that the browser has a session cookie), then javaws(1) says that the application isn't signed. I find both of these failure modes odd as the javaws(1) documentation says that it understands user authenticating web pages and the jar file is signed.
I'm on Gentoo Linux, running OpenJDK 7, and I think I experienced the same problem.
I could not get it to work with OpenJDK 7. Only re-signing with a release of the Sun Java 6 JDK ultimately signed the application correctly. (I also re-built it all due to it being managed by ant, I don't know if that is necessary, though).
Merely switching to the official JDK 6 without rebuilding only makes the "[CertPath not validated: null]" warning when varifying with "jarsigner -verify -verbose -certs" disappear, but does not appear to work in the application I ultimately use.
make sure you are not using a cached (unsigned) version of the jar. Clean the temp folder where JWS downloads jars
make sure that all dependencies (jars) of your jar, that require special permissions, are also signed
Make sure you wrap your calls in the applet with a doPrivileged block. I am unsure why it works like this but seems to work like a charm.
Related
I Signed with JDK:1.8 jarsigner.
Verify Results with JDK:1.8:
C:\glassfish4\jdk8\bin\jarsigner -verify sample_sha1_sha1.jar -verbose
Timestamped by "***" on Wed Jun 06 17:59:57 UTC 2018
Timestamp digest algorithm: SHA-1
Timestamp signature algorithm: SHA256withRSA, 2048-bit key
jar verified.
But same signed jar when i verify with JDK: 1.7_21_b11, it says jar unsigned.
Results:
C:\glassfish4\jdk7\bin\jarsigner -verify sample_sha1_sha1.jar -verbose
898 Wed Jun 06 17:59:56 IST 2018 META-INF/MANIFEST.MF
m 172 Wed Nov 16 18:45:40 IST 2016 META-INF/NOTICE
m 10351 Wed Nov 16 18:45:40 IST 2016 META-INF/LICENSE
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
jar is unsigned. (signatures missing or not parsable)
Please help me how to solve this.
We have one way ssl HTTPS server which sends CA certificates to the client. When the client sends the request to the server we are getting a javax.net.ssl.SSLHandshakeException.
When the client sends request to the https server, server is throwing a sslhandshake exception as shown below. We tried to edit java security file but that seems to be not working.
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- |NF javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
2016/08/31-12:19:18.231919-16953-17284-0x018c510000000001-002- at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
Client and Server connection is established.
root#myhostname> wget --no-check-certificate https://myserver:4443/zen_myevent_listener/eventListener/p1
--2016-09-01 05:09:44-- https://myserver/zen_myevent_listener/eventListener/p1
Connecting to 10.255.120.133:4443... connected.
The algorithm for this is shown in the picture below:
These are the certificates on HTTPS server which we have generated.
-rw-------. 1 root root 3967 Aug 26 15:07 01.pem
-rw-------. 1 root root 1659 Aug 26 15:06 ca.crt
-rw-------. 1 root root 1751 Aug 26 15:05 ca.key
-rw-------. 1 root root 112 Aug 26 15:07 index.txt
-rw-------. 1 root root 21 Aug 26 15:07 index.txt.attr
-rw-------. 1 root root 0 Aug 26 15:05 index.txt.old
-rw-------. 1 root root 42542116 Aug 31 09:48 log.txt
-rwxrwxrwx. 1 root root 8805 Aug 26 12:51 openssl.cnf
-rw-------. 1 root root 3 Aug 26 15:07 serial
-rw-------. 1 root root 3 Aug 26 15:04 serial.old
-rw-------. 1 root root 5626 Aug 26 15:07 server-chain.crt
-rw-------. 1 root root 3967 Aug 26 15:07 server.crt
-rw-------. 1 root root 806 Aug 26 15:06 server.csr
-rw-------. 1 root root 887 Aug 26 15:06 server.key
and 01.pem /01.der file is placed on client.
When we googled and checked, we got the below fix/resolution. Even after trying this, we are still getting the same error.
The reason for this is twofold:
Sentinel 7.1 SP1 or later ships with a newer Java version that has a restriction to not allow RSA keySizes of less than 1024
The default certificates used in the logging applications have a key size of less than 1024 and don't comply to this restriction. Because of this, the server rejects the connection with the error message shown above.
The fastest way to get the system working is to revert back this
change. Edit the file jre/lib/security/java.security and look for this
line:
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
Remove the last restriction, the line will look like this:
jdk.certpath.disabledAlgorithms=MD2
Restart Sentinel for the changes to take effect.
This would not be a solution but a workaround to get things working after the upgrade.
A proper resolution is to use custom certificates on the logging applications that use strong encryption (key sizes of 1024 or more).
Once all applications have been updated, the restriction can be put
back in place.
IDM 4.5 includes an instrumentation upgrade with certificates to a key size larger than 1024 to fix this problem.
eDirectory 88SP8 Patch 2 and eDirectory 88SP7 Patch 6 have
Instrumentation upgrades with certificates to a key size larger than
1024 to fix the problem. (Note: Instrumentation is not automatically
upgraded with eDirectory, you must also manually install the
instrumentation package within the eDir patch.)
Even after trying this we are still getting the same error. Could some one help us how to proceed with this?
Here is the output of openssl x509 -text -in server.crt
root#rover> openssl x509 -text -in server.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=IN, ST=Karnataka, L=Bangalore, O=mycompany, OU=abc, CN=rover/emailAddress=myemail#gmail.com
Validity
Not Before: Aug 26 09:37:05 2016 GMT
Not After : Dec 9 09:37:05 2019 GMT
Subject: C=IN, ST=Karnataka, O=mycompany, OU=IMS, CN=rover/emailAddress=myemail#gmail.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:a4:51:0e:c5:7e:eb:e9:8e:89:9c:79:6a:b5:94:
d3:94:53:43:b2:26:47:a5:13:25:87:a3:73:03:27:
4f:f8:b2:60:86:00:b3:c7:8a:d4:bd:3c:70:33:1e:
16:4b:0a:e7:a7:50:a6:48:0e:33:cf:6e:72:30:13:
c0:bd:1a:b3:57:ec:ec:bd:6b:90:84:f4:79:a9:29:
48:50:7d:e0:07:22:c5:cc:b1:81:4d:8d:61:f5:c6:
58:87:73:e0:1b:b9:a1:fc:a0:1a:42:79:96:f6:11:
cf:0a:60:fe:26:d4:e3:a6:b8:ca:8d:2c:48:b1:41:
5e:f8:64:a6:2f:02:e5:5b:8f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Authority Key Identifier:
keyid:C5:05:6A:D7:1B:9A:E1:B6:A5:A2:2F:70:2B:13:C6:C2:74:DA:70:45
DirName:/C=IN/ST=Karnataka/L=Bangalore/O=mycompany/OU=IMS/CN=rover/emailAddress=myemail#gmail.com
serial:B0:C5:54:AC:F8:78:7B:5F
Signature Algorithm: md5WithRSAEncryption
36:ae:d7:aa:c2:ce:20:91:c9:57:77:e7:4b:c5:e1:b5:28:5d:
4b:85:db:03:90:67:4e:f9:7d:b1:35:8c:de:80:6d:bf:f5:d0:
c9:1b:10:8a:c2:de:5e:88:d6:f6:0d:fc:05:92:f0:88:81:98:
8c:c9:a4:57:1b:70:7d:8d:dc:90:c9:cd:e3:77:1f:81:f0:63:
39:42:14:ff:d6:46:cb:f9:84:2c:8d:cc:1e:b5:b9:6a:12:2a:
c4:d4:5c:fa:79:a6:ea:a8:9b:53:65:54:c9:68:a4:d8:63:0f:
64:a5:35:88:6d:9f:3b:bf:dd:ec:5f:69:95:a2:17:94:97:c9:
26:89:d2:1b:12:2f:39:35:1f:aa:41:d0:23:2f:0e:c8:83:02:
9d:70:46:ff:23:3d:5b:46:58:fa:ff:1c:3f:d1:9b:78:21:b9:
cf:ae:b5:3c:64:12:70:92:71:0f:9f:b0:f9:54:6a:e7:51:41:
b0:66:2f:0a:57:a1:a7:e6:f8:e0:7b:46:7d:e5:66:b7:f7:e9:
d4:23:16:89:b0:bc:8e:c5:e6:b9:69:a1:bc:2b:98:08:fc:10:
9c:9e:71:a8:b6:c1:fa:9a:71:5a:79:9d:07:cb:73:d4:e7:5a:
01:16:76:38:6e:29:8b:6a:12:72:e9:ac:36:54:a2:9f:75:ef:
3b:6e:c6:e0
-----BEGIN CERTIFICATE-----
MIID2DCCAsCgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBjzELMAkGA1UEBhMCSU4x
EjAQBgNVBAgTCUthcm5hdGFrYTESMBAGA1UEBxMJQmFuZ2Fsb3JlMQ4wDAYDVQQK
EwVOb2tpYTEMMAoGA1UECxMDSU1TMQ8wDQYDVQQDEwZtYXJzMDQxKTAnBgkqhkiG
9w0BCQEWGmtpc2hvcmUudmVybmVrYXJAbm9raWEuY29tMB4XDTE2MDgyNjA5Mzcw
NVoXDTE5MTIwOTA5MzcwNVowezELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCUthcm5h
dGFrYTEOMAwGA1UEChMFTm9raWExDDAKBgNVBAsTA0lNUzEPMA0GA1UEAxMGbWFy
czA0MSkwJwYJKoZIhvcNAQkBFhpraXNob3JlLnZlcm5la2FyQG5va2lhLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApFEOxX7r6Y6JnHlqtZTTlFNDsiZH
pRMlh6NzAydP+LJghgCzx4rUvTxwMx4WSwrnp1CmSA4zz25yMBPAvRqzV+zsvWuQ
hPR5qSlIUH3gByLFzLGBTY1h9cZYh3PgG7mh/KAaQnmW9hHPCmD+JtTjprjKjSxI
sUFe+GSmLwLlW48CAwEAAaOB1TCB0jAJBgNVHRMEAjAAMIHEBgNVHSMEgbwwgbmA
FMUFatcbmuG2paIvcCsTxsJ02nBFoYGVpIGSMIGPMQswCQYDVQQGEwJJTjESMBAG
A1UECBMJS2FybmF0YWthMRIwEAYDVQQHEwlCYW5nYWxvcmUxDjAMBgNVBAoTBU5v
a2lhMQwwCgYDVQQLEwNJTVMxDzANBgNVBAMTBm1hcnMwNDEpMCcGCSqGSIb3DQEJ
ARYaa2lzaG9yZS52ZXJuZWthckBub2tpYS5jb22CCQCwxVSs+Hh7XzANBgkqhkiG
9w0BAQQFAAOCAQEANq7XqsLOIJHJV3fnS8XhtShdS4XbA5BnTvl9sTWM3oBtv/XQ
yRsQisLeXojW9g38BZLwiIGYjMmkVxtwfY3ckMnN43cfgfBjOUIU/9ZGy/mELI3M
HrW5ahIqxNRc+nmm6qibU2VUyWik2GMPZKU1iG2fO7/d7F9plaIXlJfJJonSGxIv
OTUfqkHQIy8OyIMCnXBG/yM9W0ZY+v8cP9GbeCG5z661PGQScJJxD5+w+VRq51FB
sGYvClehp+b44HtGfeVmt/fp1CMWibC8jsXmuWmhvCuYCPwQnJ5xqLbB+ppxWnmd
B8tz1OdaARZ2OG4pi2oScumsNlSin3XvO27G4A==
-----END CERTIFICATE-----
java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
...
Signature Algorithm: md5WithRSAEncryption
This is pretty bad. MD5 as signature algorithm is broken for many years and this brokenness was already used successfully in major attacks years ago (Stuxnet). My guess is that Java complains about this.
Since the certificates are obviously just created recently someone messed up this certificate creation badly. Don't try to work around it but instead create proper certificates, i.e. using a proper signature algorithm (SHA-256 instead of MD5) and a proper key size (2048 instead of 1024).
First I want to say I am beginner in Java / Web development (but with great experience in programming and analysis). I search several surveys in several locations, not finding a solution to the problem that I think is configuration.
The story:
I implemented an Applet that uses javax.smartcardio for the ATR, this works fine without any problems! This applet must "transmit" the collected information to a web page that uses javascript (inside the script of this page), I opted to pass the information in json format and chose Gson for this... Running the applet inside the IDE this works fine!!! Running inside the browser (local IIS 7.5 server) this not work, showme a error: "Uncaught Error: java.lang.InvocationTargetException".
In first time I saw that the IIS log showed the following line:
2014-01-14 02:42:35 127.0.0.1 GET /com/google/gson/Gson.class - 80 - 127.0.0.1 Mozilla/4.0+(Windows+7+6.1)+Java/1.7.0_45 404 0 2 2
Looking at the contents of the JAR file I could see that the missing gson jar files...
I found that should put the files into WEB-INF \ lib directory of the project, it did not exist and Deployment Assembly also not too ... To fix this, I changed Project Facet (add Dynamic Web Module).
Now there is a folder: WebContent \ WEB-INF \ lib
I copied and pasted the three files from the explorer windows Gson ...
I added the files in deplyment Assembly and now they are in the exported JAR file but the same error keeps happening.
Note: There NOT is a security problem, the applet is signed, after removing gson functions and my method return the ATR code (string) directly the applet works fine.
Any step by step tutorial to "install" for it???
Thanks in advance!
Screen images:
RESUMING
The applet works fine, all functions work, except the function using GSON... In my local server (IIS 7.5) I create a site, and inside this site I put the files: index.html ; MyApplet.jar ; \scrits\Myscript.js Inside de MyApplet.jar file exists many files .class ; .classpath ; project and two folders (META-INF and WebContent with WEB-INF\lib and GSON jar files, three). The problem is: On execute the function using GSON it raise a error, in IIS log I see 404 for /com/google/gson/Gson.class
Applet Jar Content
>C:\inetpub\wwwroot\Sistemas\BryDiscover>"C:\Program Files\Java\jdk1.7.0_45\bin\jar.exe" -
>tvf Bry.Discover.jar
>>"1636 Wed Jan 15 15:33:10 BRST 2014 META-INF/MANIFEST.MF"
>>"1841 Wed Jan 15 15:33:10 BRST 2014 META-INF/PABLOERN.SF"
>>"1207 Wed Jan 15 15:33:10 BRST 2014 META-INF/PABLOERN.DSA"
>>>"415 Tue Jan 14 14:24:56 BRST 2014 .classpath"
>>"1742 Tue Jan 14 00:39:04 BRST 2014 SmartCardInfoList.class"
>>"1418 Tue Jan 14 00:39:04 BRST 2014 SmartCardInfo.class"
>>>"925 Wed Jan 15 15:32:28 BRST 2014 BryDiscover$1.class"
>>>"927 Wed Jan 15 15:32:28 BRST 2014 BryDiscover$2.class"
>>>"921 Wed Jan 15 15:32:28 BRST 2014 BryDiscover$3.class"
>>>"917 Wed Jan 15 15:32:28 BRST 2014 BryDiscover$4.class"
>>>"923 Wed Jan 15 15:32:28 BRST 2014 BryDiscover$5.class"
>>>"917 Wed Jan 15 15:32:28 BRST 2014 BryDiscover$6.class"
>>"1027 Wed Jan 15 15:32:28 BRST 2014 BryDiscover$7.class"
>>"1419 Wed Jan 15 15:32:28 BRST 2014 BryDiscover$8.class"
>>"8905 Wed Jan 15 15:32:28 BRST 2014 BryDiscover.class"
>>"1045 Tue Jan 14 00:35:40 BRST 2014 .project"
>>>>"39 Tue Jan 14 00:35:38 BRST 2014 WebContent/META-INF/MANIFEST.MF"
"249351 Tue Jan 14 00:37:22 BRST 2014 WebContent/WEB-INF/lib/gson-2.2.4-javadoc.jar"
"127564 Tue Jan 14 00:37:22 BRST 2014 WebContent/WEB-INF/lib/gson-2.2.4-sources.jar"
"190418 Tue Jan 14 00:37:22 BRST 2014 WebContent/WEB-INF/lib/gson-2.2.4.jar"
WebContent \ WEB-INF \ lib
Try fetching your applet back from there, using a direct fetch in the browser address bar, to discover a 'not permitted' error (I think they are response codes in the 500 range).
If you cannot retrieve it by direct fetch, the Java Plug-In also cannot access it.
The applet needs to be moved to a place outside the WEB-INF directory structure that is accessible to the browser/plug-in.
Output of Jar command
..
190418 Tue Jan 14 00:37:22 BRST 2014 WebContent/WEB-INF/lib/gson-2.2.4.jar
The standard class-loaders are not designed to work with a 'Jar within a Jar'. It will be necessary to do either of:
Extract the Jar and add the content to the main Jar.
Separately list the gson-2.2.4.jar Jar in the archive attribute of the applet element (and not have it inside another Jar).
I am trying to load the JRI in my webstart-application. I always get this exception:
Cannot find JRI native library!
Please make sure that the JRI native library is in a directory listed in java.library.path.
JNLP file:
...
<resources>
...
<jar href="JRI.jar" />
...
<nativelib href="JRI.jar" />
</resources>
...
I use a batch script to run my application under Windows 7:
set R_HOME=C:\ProgramData\R\R-2.14.0
set R_PATH=C:\ProgramData\R\R-2.14.0\library\rJava\jri
set JNLP_URL=http://localhost/app/app.jnlp
set WEBSTART="C:\Program Files\Java\jre7\bin\javaws.exe"
SET PATH=%PATH%;%R_HOME%\bin\i386;%R_PATH%
%WEBSTART% %JNLP_URL%
I try to use an sh script to start my application under Linux (Ubuntu):
#!/bin/bash
export R_HOME=/usr/lib/R/
export r_home=/usr/lib/R/
export rHome=/usr/lib/R/
export rhome=/usr/lib/R/
export rHOME=/usr/lib/R/
export R_PATH=/usr/lib/R/site-library/rJava/jri/
export r_path=/usr/lib/R/site-library/rJava/jri/
export rPath=/usr/lib/R/site-library/rJava/jri/
export rPATH=/usr/lib/R/site-library/rJava/jri/
export rpath=/usr/lib/R/site-library/rJava/jri/
export WEBSTART=/usr/lib/jvm/java-7-oracle/jre/bin/javaws
export JNLP_URL=http://localhost/app/app.jnlp
export PATH=$PATH:$R_HOME/bin:$R_PATH
$WEBSTART $JNLP_URL
For some reason it does work under Windows, but not under Linux. The two batch scripts should do the same...
The application works fine under both, Windows and Linux, until I try to use a method which tries to use R.
It also works completely (including R), when I start my application with the following sh script as a non-webstart version:
#!/bin/bash
export R_HOME=/usr/lib/R/
export rPATH=/usr/lib/R/site-library/rJava/jri/
export JAVA=/usr/lib/jvm/java-7-oracle/jre/bin/java
LIB=<<Libraries>> # I left out this very long line for this post :)
$JAVA -classpath $LIB:. -Djava.library.path=./FAST:$rPATH de.app.MainWindow $*
I have no clue why it is not working with webstart and Linux...
A jar -tvf JRI.jar gives me:
0 Sun Oct 07 12:28:14 CEST 2012 META-INF/
68 Sun Oct 07 12:28:14 CEST 2012 META-INF/MANIFEST.MF
0 Sun Oct 07 12:28:12 CEST 2012 org/
0 Sun Oct 07 12:28:12 CEST 2012 org/rosuda/
0 Sun Oct 07 12:28:12 CEST 2012 org/rosuda/JRI/
1079 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/RVector.class
582 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/RMainLoopCallbacks.class
2158 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/RList.class
1723 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/RFactor.class
10424 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/Rengine.class
734 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/RBool.class
1010 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/RConsoleOutputStream.class
3082 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/Mutex.class
9887 Sun Oct 07 12:28:14 CEST 2012 org/rosuda/JRI/REXP.class
190345 Sun Oct 07 12:28:12 CEST 2012 libjri.so
JaNeLA gives me
XML encoding not known, but declared as utf-8
'short' description is longer than 'default' description.
and for every resource jar I specified I got (example for persistence-api-1.0.jar):
Downloads can be optimized by specifying a resource size for 'persistence-api-1.0.jar'.
The resource download at persistence-api-1.0.jar can be optimized by removing the (default) value of download='eager'.
The resource download at persistence-api-1.0.jar can be optimized by removing the (default) value of main='false'.
It might be possible to optimize the start-up of the app. by specifying download='lazy' for the persistence-api-1.0.jar resource.
Lazy downloads might not work as expected for persistence-api-1.0.jar unless the download 'part' is specified.
All those notices are green or yellow.
After setting our domain users to support AES encryption for Kerberos tokens (Windows Server 2008R2), on a web-application server side we get the following exception:
GSSException: Failure unspecified at GSS-API level (Mechanism level:
Encryption type AES256CTS mode with HMAC SHA1-96 is not
supported/enabled)
Strangely we have Java 6 (1.6.0_27) , which means that AES should be supported, according to this document: http://docs.oracle.com/javase/6/docs/technotes/guides/security/jgss/jgss-features.html
Any ideas what's missing in our web-application or Java, or third parties? We are using Spring security Kerberos extension (with minimal code modifications to fit into our current Spring 2.x version and additional authentication requirements).
EDIT (2017-05-06): upcoming JDK versions will have this included. Only a config parameter needs to be set, see JDK-8157561.
Follow this link - Java SE Downloads, scroll down and download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for your specific JDK version and follow the process in this tutorial titled: 5.4.2. Kerberos and Unlimited Strength Policy.
The basic steps are as follows:
locate your JDK's security directory (showing Unix below):
$ locate 'jre/lib/security' | grep 'lib/security$'
/usr/java/jdk1.7.0_17/jre/lib/security
/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/security
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/security
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/security
Noting the above, we need to add the downloaded JCE .jar files to /usr/java/jdk1.7.0_17/jre/lib/security.
The JCE .zip file includes the following (showing JDK 1.7's JCE):
$ ls -l UnlimitedJCEPolicy
total 16
-rw-rw-r-- 1 root root 2500 May 31 2011 local_policy.jar
-rw-r--r-- 1 root root 7289 May 31 2011 README.txt
-rw-rw-r-- 1 root root 2487 May 31 2011 US_export_policy.jar
These are the bundled versions with the JDK (again 1.7):
$ ls -l /usr/java/jdk1.7.0_17/jre/lib/security/*.jar
-rw-r--r--. 1 root root 2865 Mar 1 2013 /usr/java/jdk1.7.0_17/jre/lib/security/local_policy.jar
-rw-r--r--. 1 root root 2397 Mar 1 2013 /usr/java/jdk1.7.0_17/jre/lib/security/US_export_policy.jar
We need to move these out of the way and replace them with the included versions in the JCE .zip file. I typically do the following:
$ pushd /usr/java/jdk1.7.0_17/jre/lib/security/
/usr/java/jdk1.7.0_17/jre/lib/security ~
$ mkdir limited
$ mv *.jar limited/
$ cp ~/UnlimitedJCEPolicy/*.jar .
$ ls -l *.jar
-rw-r--r-- 1 root root 2500 Jun 25 12:50 local_policy.jar
-rw-r--r-- 1 root root 2487 Jun 25 12:50 US_export_policy.jar
Restart anything that's making use of JDK (Tomcat, etc.).