Could not create script recorder - see log for details: >> keytool error: java.secuirity.KeyStoreException: jks not found <<
Command failed, code: 1
'keytool -genkeypair - alias : root_ca:-dname "CN= _JMeter Root for CA for recording (INSTALL ONLY IF IT S YOURS ), OU= Username: ujala , C=IN" -keyalg RSA -keystore proxyserver .jks -storepass {redacted}-keypass {redacted}-validity 7 - ext bc:c'
How to solve this error during the recording controller in JMeter???
If you properly installed JMeter and Java you should not see error like this, at least I have never faced anything similar.
The fact that keytool application cannot detect jks keystore type which is the default type indicates that something is wrong with your Java installation so I would recommend reinstalling JDK from scratch.
My expectation is that it should resolve your issue. If it doesn't - check whether you (or somebody else) amended any default Test Script Recorder certificate configuration. If the values differ from defaults - try reverting them (or even reinstalling JMeter)
Also be aware of an alternative way of recording a JMeter test: JMeter Chrome Extension, in this case you won't need to think about proxies and certificates
Related
I am trying to install the version 2.162 of the open source Jenkins. The Jenkins successfully came up but, when I go to Manage Jenkins-> Manage Plugins, I see following error:
I've done some search and see this problem is regarding the certificate issue
There were errors checking the update sites: SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed: > sun.security.provider.certpath.SunCertPathBuilderException: unable to > find valid certification path to requested target
In the keystore, which website certs should I add so that jenkins can donwload the plugins from?
I was able to solve this from Jenkins UI very easy to login to Jenkins with Admin
Manage Jenkins
Manage Plugins
Advance (Under the Manage Plugins)
Change URL from https to http and click on Submit
In the Last click on Check Now
You have to configure JENKINS update-site CA-s certificates in your JENKINS java store. Just get those certificates (you can get it from your browser accessing update-site URL) and add it to your java store (java store path: $JAVA_HOME/jre/lib/security/cacerts)
To fix this you need to download all the certificates used by all the sites related to the update plugin process in Jenkins.
Typically:
get.jenkins.io.cer
mirror.gruenehoelle.nl.cer
updates.jenkins.io.cer
There may be more. As you install a plugin. If it fails. Just repeat the process to download the certificate and add it to your keystore.
> Example: keytool -import -alias mirrorgruen -keystore
> $JAVA_HOME/jre/lib/security/cacerts -file ./mirror.gruenehoelle.nl.cer
This worked on MACOSx. Tip: Unless you've changed it. Use the default password of 'changeit' when prompted to type in your password.
Finally restart Jenkins - then attempt to install the plugins. That should turn the results green.
I think the answer here might solve your problem, sounds like the same issue:
Resolving javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed Error?
You should have latest version of JDK.
I faced same issue and it was because while installing I used jdk1.8.0_241 instead of Java 2.91. And here I ended up in all kind of issues.
First I need to move to http from https (Solution above) and then still got same error while installing plugin.
To resolve this , you can see which Java version your Jenkins is referring, in your Jenkins installation HOME folder, under file named Jenkins.xml. Search for following line -
C:\Program Files\Java\jre1.8.0_291\bin\java.exe
if it is outdated, update it, JDK 1.8.291 worked like a charm for me !
This JIRA ticket helped me in getting to root cause of this -
https://issues.jenkins.io/browse/JENKINS-63515
I was using java version "1.8.0_91" when getting the SSL handshake error. Problem got solved after following instructions followed to upgrade Java to version 11
I downloaded jdk version 11.0.14 from https://www.oracle.com/java/technologies/downloads/#java11 and installed it
Also installed fontconfig using
yum install fontconfig
Modified below in /etc/init.d/jenkins with path of Java 11. Ex - /root/jdk-11.0.14/bin/java . Gave 755 permission to all folders and files in path /root/jdk-11.0.14/bin/java
Also configured update site in Jenkins configuration as
http://updates.jenkins-ci.org/update-center.json
If your problem is still not solved with above changes and if you are using a proxy where proxy is giving its own SSL certificate instead of original certficate of the website then below steps will be needed.
Add your HTTP proxy certificate (Get it from your IT team. Or access Jenkins update site in your laptop using same proxy and export certificate from browser as base64 cer file) to trusted certificates using below commands. Put the exported certificates in cer file in linux using vim. Make sure to give 755 permission for all folders and files in below paths so that jenkins user can read them.
CA cert paths
/root/jdk-11.0.14/jre/lib/security/cacerts
/root/jdk-11.0.14/lib/security/cacerts
keytool -import -noprompt -trustcacerts -alias proxy3 -file /root/proxy1.cer -keystore /root/jdk-11.0.14/lib/security/cacerts -storepass changeit -keypass changeit
keytool -import -noprompt -trustcacerts -alias jenkins3 -file /root/jenkins1.cer -keystore /root/jdk-11.0.14/lib/security/cacerts -storepass changeit -keypass change
configured /etc/sysconfig/jenkins with
ENKINS_HTTPS_KEYSTORE="/root/jdk-11.0.14/lib/security/cacerts"
JENKINS_HTTPS_KEYSTORE_PASSWORD="changeit"
Modified below in /etc/init.d/jenkins
candidates="
/root/jdk-11.0.14/bin/java
PARAMS="--logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war -Djavax.net.ssl.trustStore=/root/jdk-11.0.14/lib/security/cacerts"
Just a small hack. Update the URL in the file "hudson.model.UpdateCenter.xml" from https to http
<?xml version='1.1' encoding='UTF-8'?>
<sites>
<site>
<id>default</id>
<url>http://updates.jenkins.io/update-center.json</url>
</site>
</sites>
Background: I have an ongoing problem with a Connection Failure error message when I try connecting to an API using CFHTTP. While reviewing the API in SoapUI I noticed there was a button SSL Info (3 certs) which is outlined below. When I click the button a window of copy pops up with the headlines outlined below.
"SSL Info (3 certs)"
CipherSuite:
PeerPrincipal
Peer Certificate 1:
Peer Certificate 2:
Peer Certificate 3:
I have a feeling these are the key to getting my application to connect and pull the JSON correctly.
Question: How or Where do I install this cert information. Should I copy all 310 lines in the window with the cert information and place it in new file and save it somewhere?
Any info would be great.
I have answered the question of installing certificates before. Here are the steps again to save you from searching...
If you are using cfhttp to connect via SSL (https) then the ColdFusion server definitely needs the certificate installed to successfully connect. Here is a previous answer that I gave on a similar issue:
Here are the steps you need to perform in order to install the certificate to the Java keystore for ColdFusion. First, be sure you are updating the correct cacerts file that ColdFusion is using. In case you have more than one JRE installed on that server. You can verify the JRE ColdFusion is using from the administrator under the 'System Information'. Look for the Java Home line.
The default truststore is the JRE's cacerts file. This file is typically located in the following places:
Server Configuration:
cf_root/runtime/jre/lib/security/cacerts
Multiserver/J2EE on JRun 4 Configuration:
jrun_root/jre/lib/security/cacerts
Sun JDK installation:
jdk_root/jre/lib/security/cacerts
Consult documentation for other J2EE application servers and JVMs
In order to install the certificate you need to first get a copy of the certificate. This can be done by using Internet Explorer. Note that different versions of Internet Explorer will behave slightly differently but should be very similar to these steps. For example, earlier versions of IE might save the certificate under a different tab than I mention.
Browse to the SSL URL in Internet Explorer - https://xyz/infoLookup.php?wsdl.
View the certificate by clicking on the lock icon and clicking view certificate
Then click the Install Certificate... button (note: if you do not see this button you must close IE and run it as administrator first)
Click on IE's Internet Options and click the Content tab
Click the Certificates button
Find the server's certificate under the Intermediate Certification Authorities tab, select the cert and click the Export... button
Export using DER format
Copy the exported certificate file to your ColdFusion server (you can delete the cert from IE if you want)
Run cmd prompt as administrator on the ColdFusion server
Make a backup of the original cacerts file in case you run into issues
The keytool is part of the Java SDK and can be found in the following places:
Server Configuration:
cf_root/runtime/bin/keytool
Multiserver/J2EE on JRun 4 Configuration:
jrun_root/jre/bin/keytool
Sun JDK installation:
jdk_root/bin/keytool
Consult documentation for other J2EE application servers and JVMs
To install the cert:
Change directory to your truststore's location (where the cacerts file is located)
Type this command (use current jvm and use current jvm's keytool) "c:\program files\java\jre7\bin\keytool" -import -v -alias your_cert_alias_name -file C:\wherever_you_saved_the_file\cert_file.cer -keystore cacerts -storepass changeit
Type yes at the prompt to "Trust this certificate?"
Note: your_cert_alias_name I used above can be whatever you want
Note: C:\wherever_you_saved_the_file\cert_file.cer change these values to whatever you use for the server folder and certificate file name
To verify the cert:
Type this command (use current jvm and use current jvm's keytool) "c:\program files\java\jre7\bin\keytool" -list -v -keystore cacerts -alias your_cert_alias_name -storepass changeit
Note: your_cert_alias_name use the same name here that you used above to install the cert
Restart the ColdFusion service It will not read the updated cacerts file until you do this.
You can delete the imported certificate file from the server if you wish.
I've got web application that uses authentification via LDAP. It works flawlessly, but production version is required to use SSL. We have a server running at "ldaps://ourserver.com:636", but Spring Security throws following exception when I try to connect to it:
Root exception is javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested targe
Apache Directory Studio also warns me about unknown certificate, but allows to ignore the check it and eventually to connect and read the data required.
There are plenty of questions and answers here about how to implement LDAP over SSL, but no one of them provide full solution. I've got two opportunities: to make the certificate trusted or to disable certificate check at all. No matter which way I choose, I can't figure out how to use the mechanism with Spring Security:
If I choose to use keytool and make the certificate trusted, I can't figure out how JVM / Tomcat / Spring Security will figure out which password I have defined (-keypass changeit).
If I choose to disable the certificate validation, I can't figure out what is the place the code should be placed.
I'm also curious on how Apache Directory Studio is able to make the certificate trusted for itself without that keytool import - which significantly reduces application portability? Solution like that would be perfect for my webapp, but I haven't found anything like that all.
Here is a solution I was able to use. The key thing I had to understand is that neither JVM, nor container with webapp needs to know alias and password. It's JVM headache to check all the certs registered, and this has nothing to do with your webapp. Unfortunately, the solution implies that you install the certificate for the whole JVM. That makes webapp less portable, but at least it works correctly. I've decided to provide following bash script with the webapp sources so other developers can install the cert easily on their machines:
SERVER="mydomain:636"
CRT_NAME="mydomain.crt"
CRT_ALIAS="mydomain_cert"
echo -n | openssl s_client -connect $SERVER | sed -ne '/-BEGIN
CERTIFICATE-/,/-END CERTIFICATE-/p' > $CRT_NAME
$JAVA_HOME/bin/keytool -import -alias $CRT_ALIAS -keystore $JAVA_HOME/lib/security/cacerts -file $CRT_NAME -storepass changeit
You may wish to add additional error checks, I've omitted them to simplify the script. You will need root priviledges to launch the second command.
I keep getting this error when adding this. Any ideas. I worked on other WSDL links and they are fine except this.
org.apache.xmlbeans.XmlException: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
The WSDL is on https, so you need to add the domain certificate to your cacerts on JRE which comes with SOAPUI installation (also could be probably that wsdl is published also on http so you can try to change the url for wsdl to http, first try this if not try steps below).
You have to download the server certificate (you can connect with the browser to the url of wsdl and save the certificate as an archive).
Then you can import this cert to your cacerts with keytool:
keytool -import -alias somealias -file serverCertificate.cer -keystore SOAPUI_HOME/jre/lib/security/cacerts
(default password for cacerts is "changeit").
With this steps you can use the WSDL and avoid the "PKIX path building failed" exception.
Hope this helps,
The Problem with the SOAP UI is it's using it's won JRE to execute programs...
To resolve the above exception follow the below steps.
Export the certificate from the key store or browser (which contain the public key)
Go to the SOAPUI installed directory and locate following directory \SmartBear\soapUI-4.0.1\jre\lib\security
Import the certificate in to cacerts trust store (Which is the default trust store)
Restart the SOAP UI and load the WSDL...
This appears to be a bug in SoapUI (at least as of 4.6.4). I just ran into the same issue and after making sure I had all of the CA certificates imported everywhere I found this post that mentions the same problem.
I installed the nightly build as mentioned in the post and I was able to get past the SSL handshake issue.
There is a sly detail here:
The SOAPui calls wsimport command with an OS system call to wsimport program. It does not load internal class com.sun.tools.internal.ws.WsImportto do the WSDL import.
If you are running SOAPui with the default JRE that comes with it but you also have a different JDK installed, then when using SOAPui tools to generate code, the wsimport command used is the one the OS knows better from the PATH and not the com.sun.tools.internal.ws.WsImport that comes with SOAPui.
In this case the called wsimport will not references the embedded cacerts in SOAPUI_HOME\jre\lib\security .
Instead it utilizes the default cacerts of the JDK the wsimport belongs.
SOAPui uses wsimport from a JDK as this picture shows
In that case the steps you have to follow are:
Download and save the server´s certificate to a file, say srv-certificate.txt
Import this certificate to the cacerts of the JDK used by the SOAPui tools:
C:\>keytool -import -alias somealias -file cmq-certificates.txt -keystore C:\software\jdk1.8.0.65\jre\lib\security\cacerts
where jdk1.8.0.65 is the JDK used by the SOAPui tools.
Hope it helps!
I've had the same problem (working with profesionnal computer behind a corporate proxy) :
It appeared that I just had to set proxy in SoapUI to None to solve it (neither manual - cntlm, in my case - nor automatic - windows settings, corporate proxy - did work :-/) !...
I'm making an cfhttp to connect to an encrypted page. Seems to work fine for some sites.
I/O Exception: Name in certificate `pro.test.com' does not match host name `go.test.com'
Is there a workaround to trust this certificate even if the host name doesn't match?
Think this is more Java question, and workaround should be affecting the JRE.
Not sure if this will work in your case, but possible solution is to import this certificate into the JRE keystore.
Generic description can be found at Sun website. Though process is pretty simple.
First you should navigate the needed HTTPS URL with your browser and export the cert using SSL properties (don't remember how it is done in IE, but in Firefox something like Security > View cert > Details > Save as -- still not sure because using non-English licalization), any X.509 type should work.
Next you should import it using keytool. Navigate to the current CF JRE's bin, execute the following command (replace arguments with your values) and restart CF:
keytool -keystore <path to keystore> -import -file <path to certificate> -alias <alias>
BTW, there is a UI tool for this, but I haven't used it so can't say if it works fine.
The sites that are probably working have a valid SSL Certificate from a trusted authority.
If you have control of pro.test.com, the preferred answer would be to get a valid cert for pro.test.com installed. But if that is not possible for some reason, I see two other options:
1) Do a try/catch where you try to connect via https, and fall back on http in the event of an SSL error. Obviously this would eliminate encryption for the failed connection.
or
2) Use Sergii's solution to import the key for that site into the Java keystore.
If go.test.com is just a development server, in that case you can create a self-signed certificate and import it into Java keystore. That way you can save up on cost by not paying to CA and get a quicker turnaround to resolve the issue