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.

```text
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/pst_DND2ari_-4wkfN84TnwRVw