On Friday, November 19, 2021 at 12:35:36 PM UTC-7 you wrote:
> Mark, > > Thank you for your response. > > Yes I'm running Linux. (sorry for missing this information) > > I suspected the Let's Encrypt certificates earlier, so I've already added > ISRG Root X1 (the issuer of Let's Encrypt) to the cacerts file. > Nevertheless I just replaced my cacerts file with the one in the most > recent java 8 release, restarted jenkins but did not help. The first plugin > was downloaded successfully, the second failed as before. > > Actually what I don't understand is how downloading the very first plugin > succeeds. It's consistently the first plugin which succeeds and the others > fail. > If downloading the other plugins fail due to a missing/expired Let's > Encrypt certificate, the first one should also fail. It should not be able > to connect to updates.jenkins.io at all. > > If there are multiple Jenkins mirrors that are roughly the same distance to you, then the mirrorbits response from https://get.jenkins.io might redirect the second request to a different HTTP server than the first request. However, if you confirmed that they are all working, that seems unlikely to be the cause. > Also, I have a standalone application which I use to check the HTTP > redirects and certificates, and this never fail to download the plugins > (the URLs are taken from Jenkins log), even though I use the very same jre > instance on the very same machine. > I assume that curl or wget from that machine will successfully retrieve https://updates.jenkins.io/latest/antisamy-markup-formatter.hpi and https://updates.jenkins.io/latest/ant.hpi and https://updates.jenkins.io/latest/adoptopenjdk.hpi. If not, then the issue is related to something outside of Java (like the ca-certs file). > My application use HttpsUrlConnection to download the files. I don't know > whether Jenkins use the same or some framework. > > The other thing I don't see is how the "CN=Kubernetes Ingress Controller > Fake Certificate, O=Acme Co" comes into the picture. According to the logs > (see my original e-mail) the SSL handshake fails on this certificate, but I > don't really see which server this certificate comes from. > > I thought that certificate could be reported when a request is made to the IP address of an HTTP server hosted in Kubernetes. The Kubernetes server needs the hostname in order to use the correct SSL certificate (or something like that). > I've also checked the mirrorlist as you suggested. All mirrors listed in > the response look good, that is have a valid certificate chain according to > my cacerts file. > Unfortunately, I'm out of ideas if one of those do not resolve the issue. Mark Waite -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8ab8f80e-cc61-4ec9-a4f4-5581f4876adan%40googlegroups.com.
