GHE.com X25519 TLS Change: What to Check Before October 7

GitHub Enterprise Cloud with data residency is changing its accepted TLS key-agreement groups on October 7, 2026. After that date, affected endpoints will no longer accept clients that offer only X25519. GitHub says P-256 (`secp256r1`) and P-384 (`secp384r1`) remain supported, and most current browsers, operating systems, GitHub CLI releases, and TLS libraries already offer P-256. See the official changelog for the exact scope.

Most teams do not need to change anything. The risk is in an application, proxy, security appliance, or TLS library explicitly configured with an X25519-only group list. If you operate GitHub Enterprise Cloud with data residency, use the remaining time to test the actual path used by your automation instead of assuming the laptop browser represents every client.

What is changing

TLS clients propose key-agreement groups during the handshake. Some clients or middleboxes are configured to offer only X25519. Beginning October 7, GitHub Enterprise Cloud with data residency will reject that narrow offer. A client that can also offer P-256 can negotiate a supported connection.

This is a TLS change, not an SSH change. GitHub explicitly says SSH connectivity is unaffected. It also does not apply to every GitHub endpoint: the announcement scopes it to GitHub Enterprise Cloud with data residency.

Who should investigate

Prioritize environments with custom cryptography or network controls:

• outbound proxies and TLS inspection gateways;
• firewalls and security appliances with custom cipher or group policies;
• old containers, operating systems, and language runtimes;
• GitHub CLI or API clients pinned in build images;
• Java, Go, Rust, or C/C++ services with an explicitly configured TLS group list;
• self-hosted CI runners and deployment hosts using a different network path than developers.

Check the real connection path

Use a hostname for the GitHub Enterprise Cloud with data residency endpoint your environment actually calls. Replace `HOST` below with that hostname. Run the test from the runner, container, proxy segment, or host that performs the production request.

# Inspect the HTTPS path and negotiated TLS details
curl -v https://HOST/ -o /dev/null

# Offer modern groups explicitly, including the fallback GitHub documents
openssl s_client -connect HOST:443 -servername HOST \
  -groups X25519:P-256:P-384 </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

# Check the GitHub CLI version in the actual runner image
gh --version

These checks do not replace a test through your production proxy or appliance. A direct OpenSSL request can succeed while an intercepted connection fails because the middlebox has its own group policy. Capture the client, proxy, and destination versions without logging credentials or full request headers.

The safe fix

Update the operating system, runtime, GitHub CLI, proxy, or TLS library to a supported version. Remove an X25519-only configuration and enable P-256. You may also enable P-384. Keep certificate verification enabled; changing trust validation is not a compatibility fix and creates a larger security problem.

If the group list is inherited from a managed security appliance, update the appliance policy rather than adding a per-application workaround. If the client uses a library pinned inside a vendor product, upgrade that product or ask the vendor for its supported TLS configuration.

A short rollout checklist

1. Confirm whether your enterprise uses GitHub Enterprise Cloud with data residency.
2. Inventory clients, proxies, and appliances that connect to its HTTPS endpoints.
3. Search configuration for an X25519-only group list.
4. Enable P-256 and upgrade old TLS components.
5. Test GitHub CLI, API calls, package downloads, and release automation through the real network path.
6. Monitor handshake failures before and after October 7.
7. Keep SSH checks separate because SSH is not affected by this change.

Do not widen every cryptographic setting without review. Enable the documented fallback groups, test the affected services, and keep the change scoped to the client or network component that needs it.

The short version

The October 7 change is narrow but easy to miss behind a proxy or old runtime. If a client offers only X25519, make P-256 available, update the component that owns the TLS policy, and test the production path. Most current clients are already fine; the important work is finding the exceptions.