This REST plugin talks to Jenkins from the outside over the REST API (HTTP Basic auth + JSON/XML endpoints) and reports credential metadata only. Because Jenkins redacts all secret material, results are classified by the Jenkins credential type, not by content: a Certificate-type credential maps to secret, as does a certificate stored as a Secret file or Secret text — the certificate PEM body is never available in either case. The separate script plugin runs privileged Groovy on the Jenkins controller itself, giving it in-process access to decrypted credential contents; it can inspect the bytes, detect a certificate regardless of how it was stored, and emit a full cert result with cert_pem. Choose the REST plugin for agentless, least-privilege inventory; choose the script plugin when you need certificate material and can run controller-side scripts.

How it works

The plugin authenticates to the Jenkins REST API using HTTP Basic authentication (username + API token) and performs the following steps:

  1. System credentials — GET {baseUrl}/credentials/store/system/api/json?depth=100 Iterates every domain (the _ domain is Global; other keys are named domains) and each credential within it.
  2. Folder discovery — GET {baseUrl}/api/json?tree=jobs[name,url,_class] Any job whose _class is one of the known AbstractFolder implementations (com.cloudbees.hudson.plugins.folder.Folder, jenkins.branch.OrganizationFolder, org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject) is treated as a folder. Each folder is visited ({folderUrl}api/json?tree=jobs[name,url,_class]) to discover sub-folders, breadth-first, with a cycle guard and a depth cap of 25 levels. If a folder at depth 26 or deeper is encountered, or if any individual folder listing or credential store cannot be read, the scan terminates with a partial-scan error and does not write a state record.
  3. Folder credentials — GET {folderUrl}credentials/store/folder/api/json?depth=10 for every discovered folder/sub-folder.
  4. Per-credential detail — for each credential, the plugin fetches its config.xml to enrich the result with scope, username, and the implementation class:
    • System, global domain: {baseUrl}/credentials/store/system/domain/_/credential/<id>/config.xml
    • System, named domain: {baseUrl}/credentials/store/system/domain/<domain>/credential/<id>/config.xml
    • Folder / sub-folder: {folderUrl}credentials/store/folder/domain/<domain>/credential/<id>/config.xml

If a config.xml cannot be fetched or parsed, the credential is still reported using the metadata from the store listing.