In JDK 8 SSLv3 is disabled and TLSv1.2 is enabled by default.
When i google i found lot of posts where SSLv3 is enabled by commenting out the line in java.security file in the lib folder.
I want to enable SSLv3 by setting a system property with out modifying the java installation.
You might be able to do this. First, you need to check if your java.security file has the following line in it:
security.overridePropertiesFile=true
If so, then the following tricks might work. Otherwise, if overriding the properties file is not allowed, then modifying that java.security file is your only recourse.
Assuming overriding the properties file is allowed, then you could try making a copy of java.security somewhere else, e.g. sslv3-allowed.java.security, with the jdk.tls.disabledAlgorithms property value modified to have "SSLv3" removed from it. Then, when you start the JVM, you'd use something like:
$ java -Djava.security.properties==/path/to/sslv3-allowed.java.security ...
Notice the "=="; this tells the JVM to completely ignore java.security, and use only your file. With a single equals sign, your file can append to (or override) portions of the default java.security file.
The above come from reading this post: https://dzone.com/articles/how-override-java-security; a related SO post can be found here: How to enable SSL 3 in Java.
Hope this helps!
Related
Today I want to use the HttpClient to call Hybris interface in the AEM. But I get the error message "java.security.cert.CertPathValidatorException: Algorithm constraints check failed on signature algorithm: MD5withRSA".
In this line throw a exception "java.security.cert.CertPathValidatorException: Algorithm constraints check failed on signature algorithm: MD5withRSA".
httpClient.executeMethod(request);
I changed the below there properties to empty in the java.security file(C:\Program Files\Java\jdk1.8.0_191\jre\lib\security\java.security), but it doesn't work.
jdk.certpath.disabledAlgorithms
jdk.tls.disabledAlgorithms
jdk.jar.disabledAlgorithms
MY JDK Version : jdk1.8.0_191
Is anyone know how to fix it?
Thanks,
Forrest
Aside: the jdk.jar.disabledAlgorithm property is not relevant to this issue.
Make certain you've actually changed the file as seen by the program.
Modern versions of Windows (IIRC since Vista, maybe Seven) don't like files under \Program Files and \Program Files (x86) being written by anything but an installer program. One thing they do at least sometimes is 'virtualize' such writes, to a different file hidden somewhere under per-user %appdata%. Search and you'll find lots of similar problems and frustrations.
Call Security.getProperty() to check the setting actually seen in your program.
If you can't fix the setting in the standard file, you can override it in another file (put somewhere more convenient) by setting sysprop (not secprop) java.security.properties=filename or by calling Security.setProperty() early in your program (before the JSSE/PKIX classes are loaded). See:
Relaxing SSL algorithm constrains programatically
Java - Lock down TLS version in java.security, but allow per app override via launch config?
Alternatively, JDK doesn't really need to be in \Program Files*. I put it in another top-level directory and don't have these issues.
And of course tell whoever is responsible for the server they are way behind the times :-)
Hi #dave_thompson_085,
Thanks to your replay. I have fixed this issue with the below steps.
I Used command "where java" to check which JDK is I am really using.
I reinstalled that JDK.
I removed MD5 from "jdk.certpath.disabledAlgorithms", removed MD5withRSA from "jdk.tls.disabledAlgorithms"
removed "C:\Program Files (x86)\Common Files\Oracle\Java\javapath;" from path of the System variables
restart the computer, then this issue is fixed.
Thanks,
Forrest
I am trying to write a simple client/server application using JSSE for SSL sockets.
I have generated my own 'handmade' certificate with keytool for the server , and I have to set property 'keystore' as follow:
System.setProperty("javax.net.ssl.keyStore","/keystore.ks");
The problem is the following:
As far as I understand, the setProperty wants just the name of the file , not the file itself.
From IDE it works just fine if I use the path to the file (i.e. src/main/resources/keystore.ks , using the standard maven directory structure )
The prpoblem come after I build the JAR with maven. The resource cannot be found.
I understand that resources files are copied in the root of JAR , but I didn't find any method to obtain the right filename to feed to setProperty.
I also tried
String pathKeystore=Server.class.getResource("/keystore.ks").getPath();
and also .toString() .toExternalForm() and so on. But none of it works if later I setProperty with this string.
Looking on other questions I see that the pathname is generally not used for resources, and instead you just read the file , but I need the String in my case.
I don't have a good understanding of what I am doing since I am new to Maven, but basically my question can be summed up as follow:
How to obtain the correct path name of a resource file to be used as a String for setProperty method in a maven-built JAR file?
Thanks in advance to everyone.
EDIT:
I considered also to set the property at runtime :
I launched my jar with
java -Djavax.net.ssl.keyStore=keystore.ks -jar my_jar.jar
I still set the password of this keystore in the code, since I don't have issue with the path with this.
I want to add that I had the same issue on my own client, I have to add the trustStore manually , and I launched it with
java -Djavax.net.ssl.trustStore=jssecacerts -jar my_client_jar.jar
This worked fine, and I guess this is the way that should be done, instead of using the filename.
I have two programs (one in Java and one in Python) that ZIP a folder, upload it to a WebServer and trigger a UNZIP method on them.
The Java version of the program works without issues and the file is extracted on the server without problems.
Here I'm using the ArchiveStreamFactory class i.e. new ArchiveStreamFactory().createArchiveOutputStream(ArchiveStreamFactory.ZIP, this.currentOutputStream);
The Python version only works if I use zipfile.ZIP_STORED method (which does not compress the file). If I use the zipfile.ZIP_DEFLATED method I get internal server error.
I don't have access to the server so for this I can only rely on what I'm able to figure out on my side.
The Java program does seem to use the ZIP_DEFLATED method also as the archive is compressed (smaller) and not just stored.
I've also run zipinfo on the both archives (the one created with Java and the one with Python with DEFLATE - which doesn't work) too see what's different.
Here's the output:
# Java
-rw---- 2.0 fat 14398 bl defN 4-Jun-15 13:55 somefile.txt
# Python
-rw-r--r-- 2.0 unx 183 b- defN 28-Jun-15 21:39 someotherfile.txt
Both seem to be compressed with DEFLATE (defN) method so why does the archive generated by Java works while the one generated by Python doesn't?
So after a lot of debugging and trial and error looks like I found the issue in case anyone else is interested or will have the same problem.
I was also adding the folder to the zip and looks like it didn't liked the folders being compressed with ZIP_DEFLATED. What I did was to manually set the compression to ZIP_STORED for folders and to ZIP_DEFLATED for files and after this it worked. Interesting how Java knew to do this automatically behind the scenes, or at least I guess it does as the Java version is kind of the same (iterate over folders/files and add them to the ZIP) except I just use the default values (so I never explicitly set the compression type for anything).
So basically my code (the version that didn't worked) was something like this:
for dir_path, dir_names, file_names in os.walk(absolute_folder_path, compression=zipfile.ZIP_DEFLATED):
...
# Add folder to ZIP
f_zip.write(absolute_dir_path, arcname=relative_dir_path)
for file_name in file_names:
...
# Add file to ZIP
f_zip.write(absolute_file_path, arcname=relative_file_path)
and the fix was this one:
for dir_path, dir_names, file_names in os.walk(absolute_folder_path):
...
# Add folder to ZIP
f_zip.write(absolute_dir_path, arcname=relative_dir_path, compress_type=zipfile.ZIP_STORED)
for file_name in file_names:
...
# Add file to ZIP
f_zip.write(absolute_file_path, arcname=relative_file_path, compress_type=zipfile.ZIP_DEFLATED)
I've ran into an issue with encoding. Not sure if it's IDE related but I'm using NetBeans 7.4. I got this piece of code in my J2EE project:
String test = "kukuřičné";
System.out.println(new String(test.getBytes("UTF-8"))); // should display ok
System.out.println(new String(test.getBytes("ISO-8859-1")));
System.out.println(new String(test.getBytes("UTF-16")));
System.out.println(new String(test.getBytes("US-ASCII")));
System.out.println(new String(test.getBytes("windows-1250")));
System.out.println(test); // should display ok
And when I run it, it never displays properly. UTF-8 should be able to print that out ok but it doesn't. Also when I tried:
System.out.println(Charset.defaultCharset());
it returned windows-1252. The project is set to UTF-8 encoding. I've even tried resaving this specific java file in UTF-8 but it still doesn't display properly.
I've tried to create J2SE project on the other hand and when I run the same code it displays properly. Also the default charset returns UTF-8.
Both projects are set the UTF-8 encoding.
I want my J2EE project to act the same like the J2SE one. I didn't notice this issue until I updated my java to version 1.7.0_51-b13 but again I'm not sure if that is related.
I'm experiencing the same issue like this guy: http://forums.netbeans.org/ptopic37752.html
I've also tried setting the default encoding for the whole IDE: -J-Dfile.encoding=UTF-8 but it didn't help.
I've noticed an important fact. When I create a new web application it displays ok. When I create new Maven web application it displays incorrectly.
Found the same issue here: https://netbeans.org/bugzilla/show_bug.cgi?id=224526
I still haven't fixed it yet. There's still no solution working.
In my pom.xml the encoding is set properly, but it still shows windows-1252 in the end.
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
I've spend few hours trying to find the best solution.
First of all this is an issue of maven which picks up platform encoding and uses it even though you've specified different encoding to be used. Maven doesn't seem to care (it even prints to console that it's using UTF-8 but when you run a file with the code above, it won't display properly).
I've managed to tackle this issue by setting a system variable:
JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8
There should be another option instead of setting system variables and that is to set it as additional compiler parameter.
like javac -Dfile.encoding=UTF8
You are mixing a few concepts here:
the project encoding is the encoding used to save the Java source files (xxxx.java) - it has nothing to do with how your code executes
test.getBytes("UTF-8") returns a series of bytes representing your String in UTF-8 encoding
to recreate the original string, you need to explicitly give the encoding, unless it is the default of your machine: new String(test.getBytes("UTF-8"), StandardCharsets.UTF_8)
I have installed a java batch process using the version of procrun that ships with tomcat 5.5.33:
Commons Daemon Service Runner version 1.0.5.0/Win32 (Jan 5 2011)
Copyright (c) 2000-2011 The Apache Software Foundation.
In the installation, I specify (among other JVM options):
--JvmOptions="-Duser.dir=C:\LOCAL\serverapps"
My log4j.properties configuration includes:
log4j.appender.InfoLogFile.File=../logs/info.log
However, the info.log file is being written to:
C:\WINDOWS\logs
I've checked the value of user.dir at many different points and it's always C:\LOCAL\serverapps.
But, log4j is behaving as if user.dir=C:\Windows\System32 (or some other subir of C:\Windows).
From what I can tell from the log4j source (1.2.16), the FileAppender deals only with the java.io.FileOutputStream and File classes which claim to make paths relative from the user.dir location.
I've worked around the issue, but I am curious: has anyone else has encountered this type of behaviour? If so, what's really going on?
FileAppender, when given a relative path, creates a file withing the current working directory - not the user home directory.
You need to pass the ${user.dir} within the filename.
SRC:
http://svn.apache.org/viewvc/logging/log4j/trunk/src/main/java/org/apache/log4j/FileAppender.java?view=markup
EDIT: see comment below for correction - user.dir != user.home
http://bugs.sun.com/view_bug.do?bug_id=4117557
I have used ${user.dir} in the lo4j.properties and it has worked. Have you tried?
log4j.appender.InfoLogFile.File=${user.dir}/logs/info.log
PhilW's comment points to the correct answer to the original question. That is, Oracle/Sun declares an issue http://bugs.sun.com/view_bug.do?bug_id=4117557 when user.dir is set via the command line. That is the reason why the relative path is not properly understood when logging files are written out.
By using a an absolute path (even prefixing with ${user.dir} -- which can be trusted at that point - even if the JVM gets the value wrong internally) as Phil, Amir and I all suggest, you avoid the issue altogether.