Gradle use certificate authentication for repository - ssl

The Problem
I have a Android Gradle project which should pull a lib from my companys sonatype nexus server. The nexus server uses a certificate authentication. That means the client has a private certificate which authenticates and authorizes him against the nexus server.
The problem is how to configure gradle to use my certificate (which is in the osx keystore).
/app/build.gradle
repositories {
// some other repositorys...
...
maven {
credentials {
username = NEXUS_USERNAME
password = NEXUS_PASSWORD
}
url 'https://prefix.server.com/nexus/content/repositories/artifactid'
}
}
Without giving a certificate the nexus server respont with:
Error: Could not HEAD 'https://prefix.server.com/nexus/content/repositories/artifactid/de/komoot/android/kmt-material-showcase/0.0.1/kmt-material-showcase-0.0.1.pom'. Received status code 400 from server: Bad Request
My first solution was to try to configure the jvm to use the osx keychain for certificates. The same method helped me to push and publish libs/artifacts on the nexus server.
/app/gradle.properties
org.gradle.jvmargs=-Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=KeychainStore -Djavax.net.ssl.keyStorePassword=-
This doesn't work the gradle sync failed:
Error:NONE (No such file or directory)
It looks like the gradle expected to be 'NONE' of the paramter '-Djavax.net.ssl.keyStore'. I tryed several uper and lower case solutions but all failed.
The second approach was to try it with
org.gradle.jvmargs=-Djavax.net.ssl.keyStoreType=KeychainStore
But the server respond with 400 again. Looks like the JVM args haven't been used.
Any ideas or articles for this topic ?
Hope someone can help me.

The Problem was that the Java process didn't have the certificate for authentication.
In my first approach I came very close but I forgot to add the company's root CA cert. My company's private certificate belongs to the root CA, so both must be provided to java.
Solution:
First provide your private company certificate to the gradle process.
Edit your user gradle.properties and add
org.gradle.jvmargs=-Djavax.net.ssl.keyStore="/Users/myusername/certificates/my_private_company_cert.p12" -Djavax.net.ssl.keyStoreType=KeychainStore -Djavax.net.ssl.keyStorePassword=changeit
Then export your company's root ca cert to the java keystore.
sudo keytool -import -trustcacerts -alias root -file ./certificates/company_root_ca.crt -keystore $JAVA_HOME/jre/lib/security/cacerts
Thats it certificate authentication should now work.
This is used for example to make own android libary projects and push them to a artifact server.
https://medium.com/android-news/the-complete-guide-to-creating-an-android-library-46628b7fc879#.naboz7yng

My solution was by updating the ca certificates on the ubuntu/debian system.
update-ca-certificates -f

Related

How to Solve Jenkins Plugins Installation Problem?

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>

Charles Proxy for Mobile apps that use SSL Pinning

Charles Proxy website comments that:
Note that some apps implement SSL certificate pinning which means they specifically validate the root certificate. Because the app is itself verifying the root certificate it will not accept Charles's certificate and will fail the connection. If you have successfully installed the Charles root SSL certificate and can browse SSL websites using SSL Proxying in Safari, but an app fails, then SSL Pinning is probably the issue.
Just to be certain, is it possible to use an HTTP monitor like Charles Proxy (or another monitor) even though a mobile app uses SSL certificate pinning?
As Steffen said you might need to patch the app to disable certificate pinning.
Most mobile apps don't use it though :) Thus you just need to enable SSL
connections with self-signed certificate. To allow that with Android
application do following. First Download apktool. Then unpack APK file
(according to apktool 2.4.1):
java -jar apktool.jar d app.apk
Modify AndroidManifest.xml by adding this attribute to application element:
android:networkSecurityConfig="#xml/network_security_config"
Create file res/xml/network_security_config.xml with following content:
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<base-config>
<trust-anchors>
<certificates src="system" />
<certificates src="user" />
</trust-anchors>
</base-config>
</network-security-config>
Generate keys to sign APK:
keytool -genkey -alias keys -keystore keys -keyalg DSA
Build patched APK:
java -jar apktool.jar b app -o app_patched.apk --use-aapt2
Sign APK file:
jarsigner -verbose -keystore keys app_patched.apk keys
If necessary convert APK to JAR for further analysis: d2j-dex2jar.sh app.apk.
More information: Network security configuration.
Certificate pinning means that the application explicitly wants to get the original certificate. If you do have the original certificate and the associated private key (which usually means that the you control the server the application is using) then it is possible to be a man in the middle (i.e. HTTP monitor) even for applications using certificate pinning.
Of course your HTTP monitoring application must support specifying a fixed certificate. It looks to me like Charles Proxy does not support this. But mitmproxy supports providing a fixed certificate for specific domains.
If you don't have access to the expected certificate and the matching key then you cannot give the expected certificate to the application. The only hope is then to somehow disable the pinning in the application itself by somehow hacking the code. Use your favorite search engine and search for "bypass pinning android" or similar to get a variety of non-trivial ways how one can try to make the application believe that it got the expected certificate.

Spring Security with LDAP over SSL: need more details

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.

soapui WSDL error when adding

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 :-/) !...

Getting error in Curl - Peer certificate cannot be authenticated with known CA certificates

I am getting the below error while making ssl connection with self signed certificate.
"Peer certificate cannot be authenticated with known CA certificates"
It is working fine with CA signed certificate.
I am setting the below using curl_easy_setopt().
curl_easy_setopt(MyContext, CURLOPT_CAPATH, CA_CERTIFICATE_PATH)
curl_easy_setopt(MyContext, CURLOPT_SSL_VERIFYPEER,TRUE);
The curl version:
libcurl-7.19.7-26
Openssl version is:
0_9_8u
Please let me know how to solve this issue.
By default CURL will generally verify the SSL certificate to see if its valid and issued by an accepted CA. To do this, curl uses a bundled set of CA certificates.
If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. Here's an example:
curl --noproxy -k \* -D - https://127.0.0.1:443/some-secure-endpoint
Security issue: This answer disables a security feature. Do not use this in production!
For php it is possible to switch off curl's verification of the certificate (see warning below) e.g. for curl_exec
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
http://php.net/manual/en/function.curl-setopt.php
(evaluate the security risk yourself, in my case it was on a partner company's server and the file required contained no secure information - just happened to be on a secure server)
We fixed a similar issue on CentOS 6 by updating curl to the latest version available in the standard repositories and installing the newest ca-certificates bundle:
yum update curl
yum install ca-certificates
libcurl performs peer SSL certificate verification by default. This is done
by using CA cert bundle that the SSL library can use to make sure the peer's
server certificate is valid.
If you communicate with HTTPS or FTPS servers using certificates that are
signed by CAs present in the bundle, you can be sure that the remote server
really is the one it claims to be.
Until 7.18.0, curl bundled a severely outdated ca bundle file that was
installed by default. These days, the curl archives include no ca certs at
all. You need to get them elsewhere. See below for example.
For more to know about Peer SSL Certificate Verification visit http://curl.haxx.se/docs/sslcerts.html
Though this error happened in the case of using git clone rather than with using curl, I've recently stumbled across an identical error message:
Peer certificate cannot be authenticated with known CA certificates
Similar to Arth's findings, something that worked for CentOS 6 (in order to successfully use HTTPS URLs with git clone for related GitLab repositories) involved updating the trusted certificates on the server (i.e., the server that is using HTTPS), using the following steps:
sudo yum install ca-certificates
sudo update-ca-trust enable
sudo cp /path/to/your_new_cert.crt /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust extract
Perhaps the same certificate steps can be applied for the case of curl (or other similar scenarios) for users on CentOS in the future.
Security issue: This answer disables a security feature. Do not use this in production!
In 'C'
curl_easy_setopt(curl_handle, CURLOPT_SSL_VERIFYPEER, 0);
worked for me
As we checked and observed/ Found in Centos 8 .
Due to Proxy issue your packages not allowing you to get accessible to update or download any packages.
try to add sslverify=0 in file /etc/dnf/dnf.conf
Its worked for me.
Also make sure you must have proper internet acess on your server.