I have an old Glassfish v2 installation that uses cert8.db truststore. I ve set up a new Installation of glassfish v3 to import the old one. I found out tha the v3 uses jks trustore (cacerts.jks).
Is it neccesery to change the trustore to *.db files ? If yes how?
Thank you in advance
Related
I am still new to JBOSS EAP and I have trouble configuring the server to use my let's encrypt certificate. I have tried to import the certificate into a pkcs12 file and then to a Keystore in my EAP/standalone/configuration folder. Moreover, I followed the steps found in this documentation: https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html-single/how_to_configure_server_security/index. However the configuration does not see me be working and ie inside the server shows me the error attached to the screenshot.ie error. Any help will be greatly appreciated.
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>
I'm currently deploying a .net-core web-api to an docker container on rhel 7.1.
Everything works as expected, but from my application I need to call other services via https and those hosts use certificates signed by self-maintained root certificates.
In this constellation I get ssl-errors while calling this services (ssl-not valid) and therefore I need to install this root-certificate in the docker-container or somehow use the root-certificate in the .net-core application.
How can this be done? Is there a best practice to handle this situation? Will .net-core access the right keystore on the rhel-system?
Since .NET Core uses OpenSSL on linux, you need to set up your linux environment in the container so that OpenSSL will pick up the certificate.
This is done by (+ Dockerfile examples):
Copying the the certificate .crt file to a location that update-ca-certificates will scan for trusted certificates - e.g. /usr/local/share/ca-certificates/ or on RHEL /etc/pki/ca-trust/source/anchors/:
COPY myca.crt /usr/local/share/ca-certificates/
Invoking update-ca-certificates:
RUN update-ca-certificates
I am trying to enable TLS 1.1 on my xampp apache server, but it seems like the version of OpenSSL is too old for that. (Error: SSLProtocol: Illegal protocol 'TLSv1.1')
Can anyone help me how I can upgrade OpenSSL? or something easier approach? I need to keep PHP version as 5.3.1.
My configuration is Apache/2.2.14 (Win32) DAV/2 mod_ssl/2.2.14 OpenSSL/0.9.8l mod_autoindex_color PHP/5.3.1.
Thank you so much!
Download the 1.0.2k zip file from this site.
https://indy.fulgan.com/SSL/
Extract the files.
Stop the Apache service.
Make a backup of these 3 files in C:\xampp\apache\bin
ssleay32.dll
libeay32.dll
openssl.exe
Copy the same 3 files from the extract files location to C:\xampp\apache\bin
Start the Apache service.
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 :-/) !...