I used Jenkins for the first time to create a ci / cd environment.
I set up jenkins with docker, registered the git repository, built it, and proceeded to the deployment stage. Use maven's tomcat7-maven-plugin as the deployment method However, there was an unexpected error.
com.sun.jersey.api.client.ClientHandlerException: 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
I got an error, so I asked google teacher as usual.
Roughly speaking, I found out that I was getting an error because the SSL certificate of the site I was trying to communicate with was not trusted. It seems that the oleore certificate or the certificate has expired.
However, the server I was trying to deploy wasn't my certificate, and it hadn't expired yet. Furthermore, even if I accessed it with a browser, I was able to communicate firmly via https. However, this "accessible with a browser" later complicated the problem.
I searched a lot, but I couldn't find any useful information. It just says that none of the sites trust the certificate, so add it to the trust list with keytool. .. .. .. However, I don't need that because it's not my certificate! I thought about various other factors.
My SSL certificate was issued by let's encrypt. Isn't java not trusting let's encrypt itself? I thought, and searched.
There was a person who was investigating here. I see, did you still trust let's encrypt itself?
However, as I read this article, the following description
Let ’s Encrypt certificate seems to be supported from Java 8 Update 101. There was.
Is there an error because the java version used by Jenkins is less than Java 8 Update 101! If you list the java version, it will be solved!
I thought. .. .. .. ..
As I wrote above, I thought it was due to the java version, so I went to check the version used by jenkins. I found out that the java version is written in the system information of Jenkins, so I went.
java.version 1.8.0_171
・ ・ ・ ・ ・ ・ ・ ・ ・
I'm sure the java version of jenkins is different from the java version when it is actually executed, so I ran java -version in the job.
java -version openjdk version "1.8.0_171" OpenJDK Runtime Environment (build 1.8.0_171-8u171-b11-1~deb9u1-b11) OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode)
・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・
why? Wasn't it due to the java version? I don't know anymore
I decided to deploy locally for the first time here. I tried the command that was being executed by jenkins as it is locally.
com.sun.jersey.api.client.ClientHandlerException: 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
seriously.
Requests that normally come to http are redirected to https
I don't know what the cause is, so I tried deploying it by making it accessible via http instead of https to isolate the problem.
You can deploy it properly.
Deploying with maven tomcat7-maven-plugin doesn't work. The ssl certificate seems to be a problem, but there is no problem even if you access the site from a browser. let's encript gives an error depending on the version of java, but it is not the version currently used. Jenkins itself isn't a problem, as you'll get similar errors locally. Since you can do it with http, the command is correct and it is unlikely that there is a problem on the client side
To be honest, I have no idea where the problem is. I started to think that it would be faster to register the certificate using keytool around here.
As you will see later, registering with keytool does not solve the error. So, as a result, it was the correct answer.
There is a site that you can search on google with a suitable word. I found this comment in security-provider-certpath-suncertpathbuilderexception-unable-to-find-valid-certification-path-to-requested-target / 28283).
Your problem has nothing to do with java! Your site is returning an incomplete chain of certificates! So we need to change it to return the full certificate chain (fullchain.pem)!
what. .. ..
Certainly I had cert1.pem loaded. As it was written on the site, load fullchain.pem. .. ..
The error disappeared instantly and I was able to deploy without any problems! !! !! !!
I just changed the SSL certificate file to be read from cert1.pem to fullchain.pem. Access from the browser is fine, and if you get an error when accessing from java, please check it.
The file that read the SSL certificate was written on some site, and I thought it was okay because it worked with the SSL certificate without any problems. Because of that belief, I put off checking if SSL was okay.
I still think that if you have fullchain1.pem, you don't need cert1.pem, right? It wouldn't have happened with only fullchain1.pem. .. .. If anyone knows why cert1.pem is needed, please let me know