Ignore certificate #640

Activity

1. mohamed-aboelsoud

   added

   feature requestNew feature or request to improve the current logicNew feature or request to improve the current logic

   needs triage

   on Jun 27, 2024
2. v-aparnajyothi-y

   removed

   needs triage

   on Jun 28, 2024
3. v-aparnajyothi-y commented on Jun 28, 2024

   

   v-aparnajyothi-y

   on Jun 28, 2024

   Contributor

   More actions

   Hello @mohamed-aboelsoud, Thank you for creating this issue and we will get back to you once we have some feedback :)
4. loiclefevre commented on Jan 29, 2026

   

   loiclefevre

   on Jan 29, 2026

   More actions

   Any news on this?
5. brunoborges

   added

   securitySecurity fixes or vulnerability-related changesSecurity fixes or vulnerability-related changes

   on Jun 22, 2026
6. brunoborges commented on Jun 23, 2026

   

   brunoborges

   on Jun 23, 2026

   Contributor

   More actions

   Related (but distinct) to #1035. To clarify the two layers so they aren't conflated:

   • This issue (Ignore certificate #640) concerns the action's download-time TLS — the runner can't verify a self-signed/internal CA when downloading the JDK on GitHub Enterprise. The fix space is custom-CA / insecure-download handling for the action's HTTP client.
   • Support optional custom cacerts input for installed JDK #1035 concerns the installed JDK's runtime trust store (cacerts) so your Java apps trust custom CAs after setup.

   Keeping both open; cross-linking for context. Note: --insecure-style bypass is a security trade-off, so a custom-CA-bundle approach (e.g. honoring NODE_EXTRA_CA_CERTS) is the likely direction here.
7. brunoborges

   self-assigned this

   on Jun 23, 2026
8. brunoborges commented on Jun 23, 2026

   

   brunoborges

   on Jun 23, 2026

   Contributor

   More actions

   Recommended direction: trust the internal CA, don't disable verification

   The error self signed certificate in certificate chain means your GitHub Enterprise host (or a TLS-inspecting corporate proxy) presents a certificate signed by an internal/self-signed CA that isn't in the runner's trust store. The action downloads both version metadata (@actions/http-client) and the JDK archive (@actions/tool-cache) over Node's TLS, so it fails to verify that chain.

   Why we should not add an "ignore certificate" toggle

   A curl --insecure equivalent would disable certificate validation, which carries serious risks here:

   1. Supply-chain RCE via MITM — an on-path attacker (malicious proxy, DNS hijack) could serve a trojaned JDK, which then becomes the java used by the rest of your workflow, with access to GITHUB_TOKEN, secrets, and deploy credentials.
   2. No integrity fallback — setup-java doesn't verify a pinned checksum/signature of the archive, so TLS is effectively the only integrity guarantee on the download. Turn it off and there's none.
   3. Over-broad scope / blast radius — a single flag would disable verification for every host (metadata APIs, CDN redirects, the GHE host…), and a global NODE_TLS_REJECT_UNAUTHORIZED=0 implementation can leak into later workflow steps.
   4. It normalizes insecurity — the flag gets copy-pasted across repos and lingers long after the misconfig is fixed.

   The secure fix (no code change needed today)

   Add your internal CA to the trust store; verification stays on, you just extend trust:

   steps:
     # CA bundle already on the runner (or write it from a secret first)
     - name: Trust internal CA
       run: echo "NODE_EXTRA_CA_CERTS=/etc/ssl/certs/internal-ca.pem" >> "$GITHUB_ENV"
   
     - uses: actions/setup-java@v5
       with:
         distribution: 'temurin'
         java-version: '21'

   Node (and therefore @actions/http-client + tool-cache) honors NODE_EXTRA_CA_CERTS, so this typically resolves the error securely. For self-hosted runners you can also install the CA into the OS trust store so it applies to all tooling.

   I'm documenting this in docs/advanced-usage.md with a GitHub Enterprise–specific callout (PR incoming). If a first-class input is ever added, the safe shape is a custom CA bundle input (not a verification-off switch), optionally paired with a required sha256 checksum.

   (Note: this is the download/transport trust layer — distinct from #1035, which is about the installed JDK's runtime cacerts.)
9. brunoborges

   added the

   Feature

   issue type on Jun 23, 2026
10. brunoborges commented on Jun 23, 2026

    

    brunoborges

    on Jun 23, 2026

    Contributor

    More actions

    Documentation for the secure workaround is now in #1050, which adds a "Self-signed certificates and internal CAs (GitHub Enterprise)" section to docs/advanced-usage.md.

    Closing this issue: the secure resolution is to trust your internal CA via NODE_EXTRA_CA_CERTS (or the OS trust store on self-hosted runners), as documented there. We won't add a flag to disable TLS verification, since the JDK download has no checksum fallback and TLS is the only integrity guarantee. If you'd like a first-class custom CA bundle input in the future, please open a feature request describing that specific shape.
11. brunoborges

    closed this as completedon Jun 23, 2026
12. brunoborges

    added 2 commits that reference this issue on Jun 23, 2026

    docs: document self-signed certificate / internal CA handling for Git…

    ...

    a9a46fb

    docs: add post-install keytool import for the JDK cacerts trust store (…

    ...

    668c1ea