GitHub GHE.com Ends X25519-Only TLS on October 7, 2026: Enable P-256

This isn't a Patch Tuesday-sized problem. For the small number of organizations that locked a proxy, appliance or custom app down to a single curve, though, their Git-over-HTTPS traffic, API calls and CLI sessions to GHE.com will stop working that morning.

What's changing​

According to GitHub's changelog, after the cutoff:

• Refused: TLS clients whose key-agreement offer contains X25519 and nothing else.
• Still supported: P-256 (secp256r1) and P-384 (secp384r1), which GitHub calls FIPS-approved groups.
• Symptom: clients that offer only X25519 can't open HTTPS connections to the affected endpoints.
• Scope: GitHub Enterprise Cloud with data residency only. GitHub says SSH connectivity is not affected.

The notice doesn't mention GitHub.com, GitHub Enterprise Server or standard (non-data-residency) Enterprise Cloud, so don't assume those services are changing too. GitHub also gives no reason for the change and doesn't call X25519 broken or deprecated. Anyone describing this as "GitHub bans Curve25519" has misread the notice.

One oddity: the web address of the changelog post mentions September 15, but the headline and body both say October 7, 2026. Plan around October 7, the date the text states.

Section summary: GitHub is dropping support for X25519-only clients, not for X25519 itself, and only on GHE.com HTTPS endpoints.

Who is GHE.com, again?​

GitHub's documentation describes GHE.com as the dedicated subdomain where an enterprise lives once it adopts data residency. Customers choose where their code and data are stored, and the listed regions are the EU, Australia, the US and Japan. These enterprises run on Enterprise Managed Users. According to GitHub's docs, API integrators send requests to the enterprise's own hostname (an api.<subdomain>.ghe.com pattern) instead of api.github.com.

The customers are mostly regulated, compliance-minded organizations. They're also the ones most likely to have strict TLS inspection proxies and hardened cryptographic policies in the path, which is exactly where an X25519-only setting could be hiding.

Why "only" matters​

In a TLS handshake, the client uses the supported_groups extension to list the key-exchange groups it will accept, in order of preference. If none of those groups overlap with the server's, the handshake fails. X25519 and P-256 are separate entries in that list.

A typical modern ClientHello offers several groups. One published TLS 1.3 handshake walkthrough shows a client offering x25519 (0x001d), secp256r1 (0x0017), secp384r1 (0x0018), secp521r1 (0x0019). A client like that can keep preferring X25519 and will still connect after October 7, because P-256 is also on its list. You get into trouble only when someone has cut the list down to X25519 alone.

Is that as rare as it sounds? Mostly, but it has come up before. A 2025 OpenSSL bug report found that an openssl server (s_server, nginx, or others) with default configuration cannot negotiate a connection with a TLS 1.2 client (openssl or other implementations) offering only X25519 in supported groups. The reporter noted that it works when the client hello contains at least P-256... in any position, whether it gets negotiated or not. The same X25519-only clients can negotiate an X25519-only connection with Google or Cloudflare (both BoringSSL), but not with OpenSSL servers.

That's useful context. The OpenSSL issue says nothing about GitHub's servers, but it shows that X25519-only clients already have trouble with plenty of servers. Keeping P-256 on the list is the safe choice across the ecosystem, not only for GitHub.

Section summary: a client passes if its group list includes P-256, wherever P-256 appears in that list.

Who might actually be affected​

GitHub names four places where an X25519-only setting could be lurking:

1. Applications with a hard-coded TLS group list, such as custom automation, CI tooling or internal bots that call the GHE.com API.
2. Proxies, especially forward proxies that open their own outbound TLS connections to GHE.com.
3. Security appliances, including TLS-inspecting firewalls and secure web gateways.
4. TLS libraries that have been explicitly set to offer a single group.

The proxy and appliance cases catch people out. If a TLS-inspecting middlebox sits between developers and GHE.com, it makes its own connection to GitHub, and that connection is the one GitHub sees. Your developers' browsers can be fine while the appliance behind them fails the handshake.

GitHub's checklist before October 7​

GitHub's recommendations, which it says to finish before the deadline:

1. Update operating systems, runtimes, GitHub CLI, proxies and TLS libraries to supported versions.
2. Remove any setting that restricts key agreement to X25519 alone.
3. Make sure P-256 (secp256r1) is enabled. You can also enable P-384 (secp384r1).
4. Contact GitHub Support if you need help checking your TLS configuration.

GitHub says current browsers, operating systems, GitHub CLI releases and common TLS libraries already support P-256. It doesn't list version numbers, configuration file names, test commands or a test endpoint.

A practical verification pass (general guidance, not GitHub's)​

These steps come from general TLS administration practice, not from GitHub:

• Take inventory first. List everything that talks HTTPS to your *.ghe.com hostnames: build agents, scripts, integrations, mirrors, proxies and inspection devices.
• Search your configs for group or curve restrictions. Look for directives that set "groups", "curves" or "ECDH curves". A list containing only X25519 (or x25519) is the thing to fix. Adding P-256 or prime256v1 next to it is enough; you don't need to remove X25519.
• Test with OpenSSL. On a machine with OpenSSL 1.1.1 or later, running openssl s_client -connect <yoursubdomain>.ghe.com:443 -groups P-256 checks whether a P-256-only handshake succeeds from that network path. Running the same command with -groups X25519 shows whether a client limited to X25519 would work. After October 7, that second test should fail.
• Windows machines: Schannel supports P-256 by default. On Windows 10 / Server 2016 and later, the PowerShell Get-TlsEccCurve cmdlet lists the enabled curves. Also check whether a Group Policy "ECC Curve Order" setting has trimmed that list on managed endpoints.
• Ask your appliance vendor how to view or change the key-exchange groups the device uses for outbound connections, which is often a separate setting from the one for client-facing connections.

Section summary: checking every intermediary between your code and GHE.com matters more than checking your developers' laptops.

Analysis: small change, easy to miss​

GitHub describes P-256 and P-384 as the "FIPS-approved" groups, and that label is the likely reason for the change. My read, which is an inference and not something GitHub has said, is that GitHub wants every GHE.com connection to be able to land on a FIPS-approved group. That's a reasonable goal for a product sold largely on compliance. The irony is that the customers most likely to have tweaked their TLS settings are those same compliance-focused organizations, some of whom may have limited their clients to X25519 because it's widely seen as a strong, modern choice.

The thing to criticize is the timing. A seven-day notice for a change that can break connections leaves little room for change-control boards, appliance firmware updates or vendor tickets. GitHub is probably right that most customers won't notice. For the few who will, the first sign may be a failed CI pipeline on October 7.

To sum up: before October 7, make sure every HTTPS path to your GHE.com enterprise, including proxies and inspection appliances, can offer P-256. SSH access isn't affected by this change.