Issue
Managed controllers connected to a Custom Update Center hosted on operations center fail to load plugin and update information. The Plugin Manager shows "Last updated: N/A" indefinitely, and no action in the UI resolves it. The managed controller logs show a signature verification failure similar to:
SEVERE hudson.model.UpdateSite#updateData: ERROR: Signature verification failed in null: Algorithm constraints check failed on disabled algorithm: SHA1 used with certificate: CN=Jenkins Update Center Plugin By CloudBees (URL: https://jenkins.example.com/cjoc/updateCenters/updates/<update-center-id>/update-center.json)
The same underlying failure can also surface independently through the built-in tool-installer metadata downloader:
WARNING h.m.DownloadService$Downloadable#updateNow: signature check failed for https://jenkins.example.com/cjoc/updateCenters/updates/<update-center-id>/updates/hudson.tasks.Maven.MavenInstaller.json ERROR: Signature verification failed in downloadable 'hudson.tasks.Maven.MavenInstaller': Algorithm constraints check failed on disabled algorithm: SHA1 used with certificate: CN=Jenkins Update Center Plugin By CloudBees
This prevents affected managed controllers from installing or updating plugins through the Custom Update Center.
Related Issue(s)
-
BEE-75059 - Fix Stale SHA-1 Custom Update Center certificate rejected by RHEL 9
-
BEE-54736 - Update UC plugin to use SHA-512 instead of SHA-1
Explanation
The Custom Update Center’s self-signed certificate is generated once by SelfCertificationProvider and is normally only regenerated when it is about to expire.
CloudBees Update Center plugin version 942, included in CloudBees CI on modern cloud platforms 2.492.1.3, changed certificate generation to sign with SHA-512 instead of SHA-1.
This change only affects newly generated certificates: a Custom Update Center whose certificate was already generated by an earlier plugin version keeps that original SHA-1 certificate even after operations center is upgraded past 942.
Starting with CloudBees CI on modern cloud platforms 2.528.2.34846, the managed controller image is based on RHEL 9, whose default system-wide cryptographic policy makes the JVM reject SHA-1 in certificate chains. A managed controller running on this image that connects through a Custom Update Center with a pre-942 SHA-1 certificate fails the signature check described above.
A managed controller that also has cloudbees-update-center-installer-plugin installed does not automatically recover once the certificate on operations center is regenerated, because that plugin’s boot-time initializer re-asserts whatever update site configuration was baked into the already-installed plugin file, independent of the current state on operations center.
Resolution
A fix for this issue has been developed and merged. No released version of CloudBees CI contains this fix yet. See Workaround below for an interim fix.
Workaround
| This workaround is temporary until an upgrade containing the permanent fix is available. |
Run the following on the operations center instance hosting the affected Custom Update Center.
-
Navigate to on operations center.
-
Run the following script. This re-signs the existing certificate with SHA-512 while keeping the existing key pair:
import com.cloudbees.plugins.updatecenter.UpdateCenter import com.cloudbees.plugins.updatecenter.signature.SelfCertificationProvider import jenkins.model.Jenkins def d = Jenkins.get().getDescriptorByType(SelfCertificationProvider.DescriptorImpl) d.setInitialized(false) d.setCaCertificate(null) d.checkInitialized() Jenkins.get().getAllItems(UpdateCenter).each { it.save() } -
This resolves signature verification on every connected managed controller automatically, including controllers that have
cloudbees-update-center-installer-plugininstalled. That plugin trusts the certificate authority by its name and public key rather than by the certificate’s signature bytes, so it continues to trust the certificate once it is re-signed, as long as the key pair itself is unchanged. -
Connected managed controllers only recheck the update site on their next restart or the next scheduled update check. To force an immediate recheck without a restart, run the following as a Cluster Operations "Execute Groovy Script on Controller" step targeting the affected managed controllers:
jenkins.model.Jenkins.get().pluginManager.doCheckUpdatesServer()See CloudBees CI on modern cloud platforms - Cluster operations for how to create a Cluster Operations job.
Do not restore a previous backup of the SelfCertificationProvider.xml persisted state file after running this script.
Restoring it regenerates the old SHA-1 certificate and reintroduces this issue.
|
If a managed controller still fails after the certificate is re-signed
This can happen if the operations center certificate was previously regenerated with a brand-new key pair instead of being re-signed in place, for example by renaming SelfCertificationProvider.xml and restarting operations center.
A managed controller with cloudbees-update-center-installer-plugin installed before that key rotation keeps trusting the discarded key, and the re-sign script above cannot restore that key.
For each such managed controller, replace the installed plugin file directly and restart:
def url = '<CJOC URL>/updateCenters/plugin/<key>/custom-update-center-installer-plugin.hpi' def j = jenkins.model.Jenkins.get() new File(j.pluginManager.rootDir, 'cloudbees-update-center-installer-plugin.jpi').bytes = new URL(url).bytes j.safeRestart()
Replace <CJOC URL> with the operations center URL and <key> with the affected Custom Update Center item’s ID.
If running this as a Cluster Operations "Execute Groovy Script on Controller" step, remove the j.safeRestart() line and add a separate "Safe Restart" step after it instead.