Windows Based Jenkins just started having certificate problems while attempting to run updates

Based on the error message below, we had to reconfigure the Java keystore to include the chain of certificates produced by the update site “https:// updates. jenkins. io” (Spaces added on purpose)
This has not solved the problem while attempting multiple ways to add the certificate or the whole chain using PEM and .crt files for it. The updates were working fine up until Mid to end of September 2025. Current version is 2.516.2 can’t update any further unless is attempted to be done manually, that creates other sets of problems, we have 2 different environments and the one we haven’t attempted to do updates is still working as expected but falling out of compliance due to vulnerabilities in the plugins. Assistance is needed!

sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:148)
at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:129)
at java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:383)
Caused: sun.security.validator.ValidatorException: PKIX path building failed
at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:388)
at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:271)
at java.base/sun.security.validator.Validator.validate(Validator.java:256)
at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:230)
at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132)
at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1302)
Caused: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:130)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:378)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:316)
at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1318)
at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1195)
at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1138)
at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:393)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:476)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:447)
at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:201)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1506)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1421)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:586)
at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:187)
at java.base/sun.net.www.protocol.http.HttpURLConnection.followRedirect0(HttpURLConnection.java:2909)
at java.base/sun.net.www.protocol.http.HttpURLConnection.followRedirect(HttpURLConnection.java:2818)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1929)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1599)
at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:223)
at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1365)
Caused: java.io.IOException: Failed to load https:// updates.jenkins. io/download/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi to E:\Tools\JenkinsData\jenkins_home\plugins\azure-keyvault.jpi.tmp
at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1380)
Caused: java.io.IOException: Failed to download from https:// updates.jenkins .io/download/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi → https:// get.jenkins .io/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi
at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1407)
at hudson.model.UpdateCenter$DownloadJob._run(UpdateCenter.java:2059)
at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:2387)
at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:2033)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:121)
at java.base/java.lang.Thread.run(Thread.java:1583)

Hi, Jenkins Infrastructure SRE here :waving_hand:

We have not changed anything related to certificates on https://updates.jenkins.io in the past 3 months (except that the certificate was renewed automatically by LetsEncrypt on September 21 like every 3 months).

However we enforced TLS 1.2 on the download mirrors behind https://updates.jenkins.io last week: Enforce at least TLS 1.2 in our webservices · Issue #4847 · jenkins-infra/helpdesk · GitHub.

The error you have is unexpected: it is a HTTP client-side error.
Let’s start step by step: can you try the URL https://updates.jenkins.io/download/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi with the Powershell Invoke-WebRequest:

What are the results, from the Windows machine where you have Jenkins and the errors you mentions, of the 2 following commands?

Invoke-WebRequest https://updates.jenkins.io/download/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi -Verbose

and

Invoke-WebRequest -Verbose https://updates.jenkins.io/download/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi -MaximumRedirection 0

=> Also, what is the JDK you are using (distribution, and exact version from java.exe --version?

Here is the output from the commands you provided, please let me know what else would you need:

PS E:\tools\Certificates> java --version
openjdk 21.0.1 2023-10-17 LTS
OpenJDK Runtime Environment Temurin-21.0.1+12 (build 21.0.1+12-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.1+12 (build 21.0.1+12-LTS, mixed mode, sharing)

PS E:\tools\Certificates> Invoke-WebRequest https:// updates.jenkins .io/download/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi -Verbose
VERBOSE: GET https:// updates.jenkins .io/download/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi with 0-byte payload
VERBOSE: received 77465-byte response of content type application/octet-stream
Invoke-WebRequest : The response content cannot be parsed because the Internet Explorer engine is not available, or Internet Explorer’s first-launch configuration is
not complete. Specify the UseBasicParsing parameter and try again.
At line:1 char:1

  • Invoke-WebRequest https:// updates.jenkins .io/download/plugins/azure-k …

    • CategoryInfo : NotImplemented: (:slight_smile: [Invoke-WebRequest], NotSupportedException
    • FullyQualifiedErrorId : WebCmdletIEDomNotSupportedException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

PS E:\tools\Certificates> Invoke-WebRequest -Verbose https:// updates.jenkins .io/download/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi -MaximumRedirection 0
VERBOSE: GET https:// updates.jenkins .io/download/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi with 0-byte payload
VERBOSE: received 267-byte response of content type text/html; charset=iso-8859-1
Invoke-WebRequest : The response content cannot be parsed because the Internet Explorer engine is not available, or Internet Explorer’s first-launch configuration is
not complete. Specify the UseBasicParsing parameter and try again.
At line:1 char:1

  • Invoke-WebRequest -Verbose https:// updates.jenkins .io/download/plugin …

    • CategoryInfo : NotImplemented: (:slight_smile: [Invoke-WebRequest], NotSupportedException
    • FullyQualifiedErrorId : WebCmdletIEDomNotSupportedException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

We are running Jenkins on Windows server 2022

Thanks @jpinto. Can you retry the same requests but add the flag -UseBasicParsing as hinted by the message from your output?

Also, can you try the URL in a webbrowser on the same machine if posible?

It looks a rather old version. Do you think it is possible to use the latest patch to rule out a JDK issue with expired certificate chains? Latest Adoptium JDK21 is there: Release jdk-21.0.9+10 · adoptium/temurin21-binaries · GitHub (and https://adoptium.net/fr/news/2022/07/gpg-signed-releases to check your downloads with their GPG key).

PS C:\Windows\system32> Invoke-WebRequest https://updates.jenkins.io/download/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi -UseBasicParsing

StatusCode : 200
StatusDescription : OK
Content : {80, 75, 3, 4…}
RawContent : HTTP/1.1 200 OK
Connection: keep-alive
Accept-Ranges: bytes
Content-Length: 77465
Content-Type: application/octet-stream
Date: Wed, 05 Nov 2025 16:49:03 GMT
ETag: “68e7b82a-12e99”
Last-Modified…
Headers : {[Connection, keep-alive], [Accept-Ranges, bytes], [Content-Length, 77465], [Content-Type,
application/octet-stream]…}
RawContentLength : 77465

I will try to update the JDK and test again

Updated the JDK to version:

PS C:\Windows\system32> java --version
openjdk 21.0.9 2025-10-21 LTS
OpenJDK Runtime Environment Temurin-21.0.9+10 (build 21.0.9+10-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.9+10 (build 21.0.9+10-LTS, mixed mode, sharing)

Attempted to re-run updates and i’m still seeing the same exact certificate path failure

Let’s continue the analysis step by step (My guess is still that the problem is related to TLS.12 which seems to be causing issues with Windows but we have to confirm it is the root cause before working on solutions):

  • After the JDK upgrade (which was useful for you in any case as if fixed many CVEs and bugs), we can rule it out if you are 100% sure it is the one used by Jenkins (you can check that in the UI in the “Manage Jenkins” → “System Information” → Click on the “Show Values” and check that the path of the property java.home is the path toe the new JDK 21. Also check that the property java.runtime.version reports 21.0.9+10-LTS).
  • So you see an HTTP/200 with the right Content size. I’m assuming you ran this command on the same exact server. Still on the same machine, could you open Mirrorlist /plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi in a webbrowser (or retireve the HTML) and share it here? The goal for me is to identify which download mirror you are redirected to. In my case:


You can see the complete set of redirections in the following excerpt I ran from my machine (but on Linux):

# Initial Request to the Update center which detects it's a plugin file to be downloaded from the "download mirror". It issues a redirect to get.jenkins.io, our download mirror service
$ curl -L -I https://updates.jenkins.io/download/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi
HTTP/2 302 
date: Thu, 06 Nov 2025 08:49:11 GMT
content-type: text/html; charset=iso-8859-1
location: https://get.jenkins.io/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi
strict-transport-security: max-age=2592000; includeSubDomains; preload

# The get.jenkins.io "download mirror service" detects the geolocation of your request (based on our outbound IP and its ASN) and issues a redirection to the closest download mirror
HTTP/2 302 
date: Thu, 06 Nov 2025 08:49:11 GMT
content-type: text/html; charset=utf-8
location: https://ftp.halifax.rwth-aachen.de/jenkins/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi
cache-control: private, no-cache
link: <https://ftp.belnet.be/mirror/jenkins/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi>; rel=duplicate; pri=1; geo=be
strict-transport-security: max-age=2592000; includeSubDomains; preload

# In my case, the closest mirror picked was Aachen University in germany: we are redirected to this one. The file weight ~77kb, exact same size as your PowerShell request.
HTTP/2 200 
server: nginx/1.26.3
date: Thu, 06 Nov 2025 08:49:12 GMT
content-type: application/octet-stream
content-length: 77465
last-modified: Thu, 09 Oct 2025 13:27:06 GMT
accept-ranges: bytes

Oh I missed this one. The URL which causes issue seems to be the download service, not the original request.

What is the result of:

Invoke-WebRequest https://get.jenkins.io/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi -UseBasicParsing -Verbose

?

Hello Damien,

Here are the answers to you rquestions:

@jpinto your post is missing the answers :wink:

Thanks @lemeurherve , seems that the email didn’t go through, i’ll post directly here.

@dduportal here are the answers to your questions:

  1. Check that the path of the property java.home is the path toe the new JDK 21. Also check that the property java.runtime.version reports 21.0.9+10-LTS).

  1. Mirrors:

  1. Curl output:

PS C:\temp> curl.exe -L -I https://updates.jenkins.io/download/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi

HTTP/1.1 302 Found

Date: Fri, 07 Nov 2025 00:27:29 GMT

Content-Type: text/html; charset=iso-8859-1

Connection: keep-alive

Location: https://get.jenkins.io/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi

Strict-Transport-Security: max-age=2592000; includeSubDomains; preload

HTTP/1.1 302 Found

Date: Fri, 07 Nov 2025 00:27:29 GMT

Content-Type: text/html; charset=utf-8

Cache-Control: private, no-cache

Link: https://mirror.xmission.com/jenkins/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi; rel=duplicate; pri=1; geo=us

Link: https://ftp-chi.osuosl.org/pub/jenkins/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi; rel=duplicate; pri=2; geo=us

Location: https://ftp-nyc.osuosl.org/pub/jenkins/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi

Strict-Transport-Security: max-age=2592000; includeSubDomains; preload

Connection: keep-alive

HTTP/1.1 200 OK

Date: Fri, 07 Nov 2025 00:27:30 GMT

Server: Apache

Last-Modified: Thu, 09 Oct 2025 13:27:06 GMT

ETag: “12e99-640b9c1e45052”

Accept-Ranges: bytes

Content-Length: 77465

Content-Type: application/octet-stream

PS C:\temp>

  1. Powershell invoke-webrequest output:

PS C:\temp> Invoke-WebRequest https://get.jenkins.io/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi -UseBasicParsing -Verbose

VERBOSE: GET https://get.jenkins.io/plugins/azure-keyvault/327.v3f37dc30312a_/azure-keyvault.hpi with 0-byte payload

VERBOSE: received 77465-byte response of content type application/octet-stream

StatusCode : 200

StatusDescription : OK

Content : {80, 75, 3, 4…}

RawContent : HTTP/1.1 200 OK

                Keep-Alive: timeout=5, max=100

                Connection: Keep-Alive

                Accept-Ranges: bytes

                Content-Length: 77465

                Content-Type: application/octet-stream

                Date: Fri, 07 Nov 2025 00:29:57 GMT

                ETag:...

Headers : {[Keep-Alive, timeout=5, max=100], [Connection, Keep-Alive], [Accept-Ranges, bytes], [Content-Length, 77465]…}

RawContentLength : 77465

Please let me know what else would you need to find a solution.