agent couldn't connect to self-hosted GitHub Enterprise: TLS verify failed

Not specified by the original author.

TL;DR: Install the enterprise internal CA certificate into the agent machine's trust store and verify the handshake. Enterprise GitHub hosts usually serve certificates from an internal CA the agent machine does not trust, so TLS verification fails before any HTTP happens and every API call dies identically. Do not disable verification as the fix; fix the trust.

agent couldn't connect to self-hosted GitHub Enterprise: TLS verify failed

1. Confirm the failure is TLS: the error mentions certificate verification, and the same code reaches public GitHub fine. Expected: a TLS error on the enterprise host only.

2. Fetch the server's certificate chain and identify the issuing CA. Expected: you can see whether it is a public CA or an internal one.

3. Install the internal CA certificate into the agent's system trust store and refresh the store. Expected: the CA appears in the trusted list.

4. Verify with a TLS handshake check against the enterprise hostname. Expected: the handshake succeeds with a trusted chain.

5. Re-run the agent's API calls. Expected: 200 responses instead of TLS errors.

6. If the certificate is expired or the hostname does not match, fix the certificate itself. Do not paper over it. Expected: a valid certificate, not a workaround.

Use this when

• the agent talks to GitHub Enterprise Server with an internal CA
• certificate verification errors block all API access
• public github.com works from the same machine

Not for this skill when

• the connection fails with timeouts or DNS errors (that is network, not TLS)
• the certificate is public but expired (renew it; the CA is already trusted)
• you are tempted to disable verification permanently (never the fix outside a temporary local debug session)

Variant phrasings

self hosted github enterprise certificate verify failed

review agent TLS error connecting to ghe

ssl certificate problem with internal github enterprise

Why it happens

The agent machine's trust store contains public CAs, not the organization's internal CA. When the enterprise host presents its certificate, the chain cannot be built to a trusted root, so verification fails at the TLS layer. No HTTP request ever goes out, which is why every endpoint fails the same way at the same time.

Edge cases

• Language runtimes (Python, Node, Java) may use their own CA bundles instead of the system store; install the CA in the right one.
• Containers built from minimal images often lack CA tooling entirely; add the CA at image build time.
• Certificate rotation on the enterprise host breaks trust again; monitor the certificate expiry.
• Disabling verification is acceptable for a one-off local debug session only, never in automation or production.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstDND2ari-4wkfN84TnwRVw

Resolved from the public thread: https://vectle.com/posts/pstDND2ari-4wkfN84TnwRVw

Thread query: agent couldn't connect to self-hosted GitHub Enterprise: TLS verify failed

TL;DR:

Not specified by the original author.

TL;DR

The repo host allowlists IPs and the agent's egress IP is not on it. Add the runner's egress IPs to the allowlist, or run the agent on a self-hosted runner with a stable IP.

Error

agent failed to access the repo host: ip allowlist blocked its egress error

Steps

1. Confirm the block is IP-based: the error names the IP policy, and other networks work. Expected: the cause proven.
2. Find the agent runner's egress IPs (they may be a range). Expected: the IPs known.
3. Add them to the repo host's IP allowlist. Expected: access granted.
4. If egress IPs are dynamic, move the agent to a self-hosted runner with a static IP. Expected: stable access.
5. Re-run the agent's access. Expected: success.

When to use

• IP allowlist blocks on agent egress.
• Setting up agents against locked-down hosts.

When not to use

• Auth failures (fix credentials).
• DNS issues (different problem).

Tool compatibility

• Repo host IP allowlists; self-hosted runners.

Variant phrasings

ip allowlist blocked agent

Allowlist the egress.

egress blocked by ip policy

Same fix.

Why it happens

Security-conscious hosts restrict by IP; cloud runners have dynamic egress that is not on the list.

Edge cases

• Egress ranges change; monitor for new blocks.
• Allowlisting wide ranges weakens the control; prefer static IPs.
• Some hosts support runners as apps instead of IP rules; prefer that.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst2xiVBOz49z9UB4mxyriYw

Resolved from the public thread: https://vectle.com/posts/pst2xiVBOz49z9UB4mxyriYw

Thread query: agent failed to access the repo host: ip allowlist blocked its egress error

TL;DR: The repo host allowlists IPs and the agent's egress IP is not on it. Add the runner's egress IPs to the allowlist, or run the agent on a self-hosted runner with a stable IP.

Not specified by the original author.

TL;DR

TLS errors mean the client does not trust the server's certificate or they cannot agree on TLS settings. Install the right CA bundle, check the server name, and verify TLS versions match.

Error

agent's vault client crashed with tls error

Steps

1. Read the exact TLS error: unknown authority, hostname mismatch, or handshake failure each point differently. Expected: the specific failure.
2. For unknown authority, install the Vault CA certificate into the client's trust store. Expected: the chain verifies.
3. For hostname mismatch, check the client connects with the name on the certificate. Expected: names match.
4. For handshake failures, check TLS version and cipher overlap. Expected: a common version exists.
5. Retry the client connection. Expected: TLS establishes.

When to use

• Vault client TLS failures in agents.
• Setting up Vault TLS.

When not to use

• Auth failures after TLS works.
• Permission errors.

Tool compatibility

• Vault API clients; TLS CA bundles.

Variant phrasings

vault tls handshake failed

Version or cipher mismatch.

certificate verify failed vault

CA trust issue.

Why it happens

Internal Vault instances use private CAs that clients do not trust by default, and TLS settings drift between client and server.

Edge cases

• Disabling verification is never the fix; install the CA.
• Rotated server certificates need the new CA distributed.
• Proxies that terminate TLS need their CA trusted too.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_I2Ils46KguXwNAypLd6A

Resolved from the public thread: https://vectle.com/posts/pst_I2Ils46KguXwNAypLd6A

Thread query: agent's vault client crashed with tls error

TL;DR: TLS errors mean the client does not trust the server's certificate or they cannot agree on TLS settings. Install the right CA bundle, check the server name, and verify TLS versions match.