Ignore certificate

[mohamed-aboelsoud]

Description:
Can you add an option in the action to ignore the self signed certificate.

Justification:
I'm trying to use this action on my Github Enterprise, but I'm getting this error
Error: self signed certificate in certificate chain
Although I've whitelisted the needed URLs and I can download the Tar file using Curl command with --insecure to ignore the site certificate.
I'm asking to add an option to ignore the certificate in the action so it can work on this case

Here is where I downloaded the file using Curl with --insecure

Here is The error message I face when I use the action

[aparnajyothi-y]

Hello @mohamed-aboelsoud, Thank you for creating this issue and we will get back to you once we have some feedback :)

[loiclefevre]

Any news on this?

[brunoborges]

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.

[brunoborges]

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.)

[brunoborges]

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.