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
Related
My app has already been signed and notarized successfully, but I got this error while trying to launch the app:
"jna7223640233751603426.tmp" cannot be opened because the developer cannot be verified
Does anybody have the solution for this?
How can I fix this problem? Can I block the file created while launching the app or make it valid for the Gatekeeper?
JNA releases have small precompiled binary JARs for each of its supported operating system/architecture combinations. These are not signed, although the source code is available if you wish to build and sign them yourself.
From a conversation on the JNA mailing list:
MacOS does not allow code created at runtime (which is typical malware behaviour), and that extracting a library at runtime looks like that code was created because it’s not visible outside the jar file in which it came.
A solution listed in that thread is:
by pre-extracting the library and bundling it as part of the installer.
In addition to this, you'll need to configure your application to tell JNA not to extract its own library but to use the one which you have signed and extracted as part of your installer. Source code from the above email thread:
boolean sandboxed = System.getenv("APP_SANDBOX_CONTAINER_ID") != null;
// Some 3rd party apps install to the system and can cause crashes
System.setProperty("jna.nosys", "true");
if(sandboxed) {
// Don't unpack the libraries
System.setProperty("jna.nounpack", "true");
// Tell JNA where the native libraries are
System.setProperty("jna.boot.library.path", "<path to native libs>");
}
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!
I have an issue whenever I am trying to deploy Jetty on a specific machine (works with others), the machine is a non-English Windows machine.
[2013-02-15 04:14:05.894] [ERROR] Thread-39
System.err
java.lang.IllegalStateException: Cannot create tmp dir in
C:\Windows\system32\config\systemprofile\AppData\Local\Temp\ for
context o.e.j.w.WebAppContext{/spdy,null},C:\Program
Files\server\work\tmp\my-app\webapps\spdy.war
[2013-02-15 04:14:05.894] [ERROR] Thread-39
System.err
java.io.IOException: Žw’肳‚ꂽƒpƒX‚ªŒ©‚‚©‚è‚Ü‚¹‚ñB
I tried to see if this is an issue related to admin rights but it is not, I am launching the process with admin rights.
Any suggestions are really appreciated.
Thanks!
Was able to find the issue out. Jetty does not create the TEMP folder if it doesn't exist so you have to check yourself and create the temp folder if it is not there.
In this instance, it ended up being that:
C:\Windows\system32\config\systemprofile\AppData\Local\Temp\ does not exist although C:\Windows\system32\config\systemprofile\AppData\Local\ does and TEMP=C:\Windows\system32\config\systemprofile\AppData\Local\Temp\
Creating "Temp" directory in C:\Windows\system32\config\systemprofile\AppData\Local\ solved the issue!
This is pretty old post, but recently I had just the same problem, so I want to share my experience too.
Parts of the code causing the problem can be found here:
http://download.eclipse.org/jetty/stable-8/xref/org/eclipse/jetty/webapp/WebInfConfiguration.html#225, resolveTempDirectory (WebAppContext context) method (check last lines of the method, third case explained in the comments). So, another workaround for the problem can be also changing default java.io.tmpdir folder to point to an existing one.
I have already checked on some systems and C:\Windows\system32\config\systemprofile\AppData\Local\Temp folder doesn't exist on Windows: 7, 2008, 2012.
I'm configuring the JPL right now, and wanna work with swi-prolog using java.
I downloaded the newest stable version of SWI-Prolog, which is 6.2.0, and installed in D:\swipl
First, I added the following path to the PATH virable: D:\swipl\bin, which should include all dll files needed.
Then, I added the following path to the CLASSPATH virable: D:swipl\lib\jpl.jar, which should be the jar file needed.
When I tried to run the versions example provided, I got the following error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: jpl.fli.Prolog.thread_self()I
at jpl.fli.Prolog.thread_self(Native Method)
at jpl.Query.open(Query.java:286)
at jpl.Util.textToTerm(Util.java:162)
at jpl.Query.Query1(Query.java:183)
at jpl.Query.<init>(Query.java:176)
at Versions.main(Versions.java:11)
After searching online, I found that many people just get java.lang.UnsatisfiedLinkError: no jpl in java.library.path which is because of the setting for the PATH variable, rather than the error I get here: java.lang.UnsatisfiedLinkError: jpl.fli.Prolog.thread_self()I (and yes, there is a "I" at the end of the line).
Has anyone gotten this error before? I've tried several previous version of SWI-Prolog, but also got other kinds of errors. I'm using Eclipse IDE for Java development -- have I missed anything?
I've sent the problem to the official mailing list (swi-prolog#lists.iai.uni-bonn.de) provided by swi-prolog.org, and luckily someone helped me to prove that there are some problems in the version 6.2.0. We then both tried the version 6.0.2, and it works perfectly. He mentioned that (and I noticed that) there is no swipl.dll in the bin folder of the version 6.2.0, which MAY causes the issue.
I've already reported the issue to the staff via Email, and at least for now, I suggest that people who want to configure JPL should download the version 6.0.2. Three things to remember:
add a new variable SWI_HOME_DIR under system variables in environment variables, and set the path to the place where you installed the SWI-Prolog (Mine is D:\swipl);
Add the path %SWI_HOME_DIR%\bin to your PATH variable, rather than use something like "D:\swipl\bin". (Otherwise [FATAL ERROR: Could not find system resources] will occur)
Add the path %SWI_HOME_DIR%\lib\jpl.jar to your PATH variable, rather than use something like "D:\swipl\lib\jpl.jar". (Otherwise [FATAL ERROR: Could not find system resources] will occur)
If you are using Eclipse for Java development, it seems that you DO NOT need to configure in your IDE. As long as you follow the 3 steps above and add the correct jar file as an external library, it should be fine.
I'm not sure whether the temporary solution works for everyone, but definitely, everyone who has the issue should try this method first. As long as the issue in the version 6.2.0 has been figured out, I'll add some comments here.
BTW, as far as I know, until now, people who have the issue are using 32-bit Windows.
Try adding your path to java.library.path via Run > Run Configuration > [project name] and add the following under "VM Arguments" tab.
-Djava.library.path="D:\swipl\bin;."
Furthermore, under the "Environment" tab, add the following:
VARIABLE: PATH
VALUE: D:\swipl\bin;${env_var:PATH}
After that, go to Project > Properties > Java Build Path, select "Libraries" tab.
Click "Add External JARS.." and find your jpl.jar.
Great Great Great, second answer is the solution
create SWI_HOME_DIR variable to set the swi prolog instalation directory
SWI_HOME_DIR ------- C:\Program Files\swipl
set PATH to point to the library and bin like this
PATH ------ %SWI_HOME_DIR%\bin;%SWI_HOME_DIR%\lib\jpl.jar
This fix my problem "Exception in thread "main" java.lang.UnsatisfiedLinkError: no jpl in java.library.path windows" it is a little bit rare but it works find.
I had the same problem. In addition to set the PATH, you need to verify if the installed SWI program has the same architecture (32 or 64) of your JVM.
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.