A GitHub connection can work perfectly from a developer's laptop and still fail from an enterprise build server, proxy, or security appliance. The difference is often not Git itself. It is the TLS configuration underneath the connection.

GitHub Enterprise Cloud with data residency has now stopped accepting HTTPS connections from clients that offer only the X25519 key-agreement group. The change took effect on October 7, 2026. Clients that support P-256 (secp256r1) or P-384 (secp384r1) can continue connecting normally. GitHub says most modern browsers, operating systems, GitHub CLI releases, and commonly used TLS libraries already support P-256.

For most developers, nothing should change. For organizations running older operating systems, custom TLS stacks, restrictive proxies, or security appliances with explicitly configured cipher or key-exchange policies, however, this can turn into a connection failure that initially looks like a GitHub outage.

The important part is understanding what is actually changing and where to look if an HTTPS connection suddenly stops working.

What Is X25519 in TLS?

X25519 is an elliptic-curve Diffie-Hellman key-agreement mechanism used during TLS handshakes.

It allows a client and server to establish shared key material without transmitting the final secret directly across the network. Modern TLS implementations commonly support several key-agreement groups so that the client and server can negotiate one they both understand.

A simplified handshake looks like this:

Code
Client
  |
  | Supported key-exchange groups
  | X25519, P-256, ...
  |
  v
GitHub
  |
  | Select mutually supported group
  |
  v
TLS session established

The important detail is that X25519 is not the same thing as TLS itself, nor is it the encryption algorithm used for the entire HTTPS session. It is one component of the TLS key-exchange process.

That distinction becomes important when troubleshooting because an error involving X25519 does not necessarily mean the application, Git client, or credentials are broken.

What Is Changing?

Beginning October 7, 2026, GitHub Enterprise Cloud with data residency no longer accepts TLS connections from clients that offer only X25519 for key agreement. GitHub continues to support the FIPS-approved P-256 (secp256r1) and P-384 (secp384r1) groups.

The affected configuration looks conceptually like this:

Code
Client TLS configuration

Supported groups:
    X25519

After the change, the server has no compatible key-exchange group to negotiate.

A compatible client could instead offer:

Code
Supported groups:
    X25519
    P-256
    P-384

The client and server can then select P-256 or another mutually supported option.

This is why most current systems are expected to continue working without changes. The problem is specifically with clients or network infrastructure that restrict negotiation to X25519.

Why Would Anyone Configure X25519 Only?

Modern TLS libraries usually support several key-exchange groups automatically. Developers generally do not need to configure them manually.

The problem appears when an organization deliberately restricts cryptographic algorithms.

This can happen in:

  • Enterprise proxies

  • TLS inspection appliances

  • Security gateways

  • Custom application runtimes

  • Older operating systems

  • Custom OpenSSL configurations

  • Hardened server images

  • Compliance-oriented cryptographic policies

For example, a proxy might have been configured years ago with an explicit list:

Code
Allowed groups:
    X25519

That configuration may have worked as long as every destination supported it.

When the remote service changes its accepted algorithms, the previously valid configuration becomes a compatibility problem.

This is a common pattern with security infrastructure. Explicit restrictions can improve control, but they also create maintenance responsibilities.

Why P-256 Matters

GitHub specifically identifies P-256, also known as secp256r1, as a supported FIPS-approved group for the affected endpoints. P-384 is also supported.

For an enterprise environment, the practical fix is therefore not to disable TLS security or revert to older cryptographic algorithms.

Instead, the client or intermediary should support a modern mutually compatible group.

A configuration that allows multiple groups is generally more resilient:

Code
Supported groups:
    X25519
    P-256
    P-384

This lets TLS negotiation choose an appropriate group instead of making the connection dependent on one algorithm.

The exact configuration depends on the TLS library or network appliance being used, so developers should avoid copying a configuration intended for a different runtime.

Who Is Actually Affected?

Most users will not notice this change.

GitHub says current browsers, operating systems, GitHub CLI releases, and commonly used TLS libraries already support P-256.

The risk is higher when a connection passes through enterprise infrastructure.

For example:

Code
Developer / CI Server
        |
        v
Corporate Proxy
        |
        v
GitHub Enterprise Cloud

Even if the Git client supports P-256, the proxy could interfere with negotiation if it is configured to offer only X25519.

The same issue can occur when an application uses an older or customized TLS library.

That is why simply checking the Git version may not always identify the problem. The entire connection path matters.

Git Over HTTPS Is the Important Case

This change concerns TLS connections to GitHub Enterprise Cloud with data residency. Git operations that use HTTPS can therefore be affected when their underlying TLS client cannot negotiate one of GitHub's supported groups.

For example:

Code
https://ghe.example.com/organization/repository.git

uses HTTPS and therefore depends on TLS.

A failed handshake happens before Git authentication and repository operations can proceed.

That means errors may appear as:

Code
Could not connect to server
TLS handshake failed
SSL connection error
Connection reset

The exact message depends on the operating system, TLS implementation, proxy, and Git configuration.

The important diagnostic clue is that the failure happens before Git can authenticate or transfer repository data.

SSH Is Not Affected by This Change

GitHub explicitly states that this X25519-only TLS change does not affect SSH connectivity.

That distinction is useful when troubleshooting.

If a repository is accessed using:

Code
https://...

you are dealing with HTTPS and TLS.

If it is accessed using:

Code
git@...

you are using SSH, which has a separate cryptographic negotiation process.

Do not start changing SSH keys or SSH algorithms when the failing connection is an HTTPS request. You can create an unrelated problem while leaving the actual TLS issue untouched.

How to Check Your Environment

Start by identifying the complete connection path.

1. Check the Git Remote

Run:

Code
git remote -v

If the remote begins with https://, the Git operation uses HTTPS.

If it uses an SSH-style remote, investigate SSH instead.

2. Check the Git Version

Run:

Code
git --version

An outdated Git installation is not automatically proof of the problem, but it is a useful starting point.

Git itself may rely on a TLS backend supplied by the operating system or built into the distribution. Therefore, updating Git may also involve updating the underlying OS libraries.

3. Check the TLS Backend

Depending on how Git was packaged, it may use different TLS implementations.

On many Linux systems, Git uses the system's TLS libraries. On other platforms, the implementation can differ.

This matters because:

Code
Git version
    ≠
TLS implementation
    ≠
TLS configuration

All three can influence the connection.

4. Check Corporate Proxies

If Git works outside the corporate network but fails inside it, investigate the proxy or TLS inspection layer.

The connection path may actually be:

Code
Git
 ↓
Corporate proxy
 ↓
TLS inspection
 ↓
GitHub

In that case, changing Git configuration alone may not fix the problem.

The proxy needs to offer a compatible key-exchange group.

A Useful Troubleshooting Strategy

When an HTTPS connection fails after a TLS policy change, avoid randomly changing cryptographic settings.

Work from the outside in:

Code
Git remote
   ↓
Git configuration
   ↓
TLS backend
   ↓
Operating system
   ↓
Corporate proxy
   ↓
Security appliance
   ↓
GitHub endpoint

First determine where the TLS connection terminates.

If a corporate proxy performs TLS inspection, the Git client may establish one TLS session with the proxy while the proxy establishes another with GitHub.

That means there can be two independent TLS negotiations:

Code
Git client
    |
    | TLS session #1
    v
Proxy
    |
    | TLS session #2
    v
GitHub

A developer may have a completely modern Git installation while the proxy still uses an incompatible cryptographic policy.

This is why enterprise troubleshooting sometimes requires the network team rather than the application team.

Common Mistakes

Updating Git Without Checking the Proxy

Installing the latest Git is a sensible first step, but it will not fix a proxy that explicitly restricts supported groups.

If the failure only happens on the corporate network, inspect the network path.

Disabling TLS Verification

A common reaction to HTTPS errors is to disable certificate verification.

That is the wrong fix for a key-exchange compatibility problem.

Settings such as:

Code
git config --global http.sslVerify false

do not solve an unsupported TLS key-exchange negotiation, and disabling certificate validation weakens connection security.

The correct approach is to fix the TLS compatibility problem rather than bypass TLS verification.

Assuming X25519 Must Be Removed Everywhere

GitHub is not saying that X25519 is universally insecure or that organizations should stop using it.

The issue is specifically clients that offer only X25519 to the affected GitHub Enterprise Cloud endpoints.

A client can continue to support X25519 while also supporting P-256 and P-384.

The better configuration is usually broader compatibility rather than removing a modern algorithm unnecessarily.

Changing Application Code First

If a Java, .NET, Go, Python, or other application suddenly cannot connect to GitHub, do not immediately change application-level code.

First establish whether the application is failing during the TLS handshake.

If the failure is in a proxy or system TLS library, modifying application logic will not address the underlying problem.

Production Considerations

Enterprise environments should treat cryptographic configuration as infrastructure that needs lifecycle management.

A TLS policy that works today can become incompatible later when a service removes older algorithms or changes its accepted groups.

This is not unique to GitHub. Public services regularly retire cryptographic algorithms that no longer meet current security or compliance expectations.

GitHub has already made other HTTPS security changes this year. For example, GitHub disabled SHA-1 in HTTPS on September 15, 2026, including GitHub Enterprise Cloud with data residency, while GitHub Enterprise Server was not affected.

That makes a broader engineering lesson clear: cryptographic compatibility should be treated as a maintained dependency, not a one-time configuration task.

Organizations using custom TLS policies should have a process for tracking upcoming cryptographic changes and testing them before the production cutoff.

Advantages and Disadvantages

Advantages

Stronger cryptographic policy: Requiring support for modern, approved key-exchange groups helps avoid dependence on narrow or outdated configurations.

Better compatibility with current security standards: Supporting P-256 and P-384 provides compatibility with the algorithms GitHub continues to accept for the affected endpoints.

Reduced reliance on a single algorithm: A TLS configuration that supports multiple appropriate groups is generally less fragile when a remote service changes its cryptographic requirements.

Disadvantages

Older infrastructure can break: Custom TLS stacks, proxies, and security appliances may require configuration or software updates.

Troubleshooting can cross team boundaries: The problem may involve Git, the operating system, a proxy, or a TLS inspection device, making ownership less obvious.

Explicit cryptographic policies require maintenance: Organizations that tightly restrict algorithms need to review those policies when external services change their supported configurations.

What Developers Should Do

If you use GitHub Enterprise Cloud with data residency and your environment uses HTTPS, the immediate action is straightforward.

Make sure your operating system, Git client, TLS libraries, proxies, and security appliances are current and do not restrict TLS key exchange to X25519 alone. GitHub recommends removing X25519-only configuration and ensuring P-256 (secp256r1) is enabled; P-384 can also be enabled.

For most developers using current software, no change is necessary.

For enterprise environments, however, the right question is not simply "Is Git updated?" It is "Can every TLS component in the connection path negotiate a group supported by GitHub?"

That includes the less visible components developers normally do not manage directly.

Summary

GitHub Enterprise Cloud with data residency has ended support for TLS clients that offer only X25519 for key agreement. P-256 and P-384 remain supported, and current browsers, operating systems, GitHub CLI releases, and common TLS libraries already support the required alternatives.

Most developers will not notice the change. The risk is concentrated in environments with explicitly restricted TLS configurations, older infrastructure, custom runtimes, or enterprise proxies and security appliances.

The practical fix is not to weaken HTTPS security or disable certificate validation. It is to update the relevant software and ensure the TLS connection can negotiate P-256 or another supported group.

For teams managing enterprise Git infrastructure, this is another reminder that cryptographic configuration has to be maintained just like any other production dependency. A configuration can remain stable for years and still become incompatible when a service removes support for a narrow or outdated negotiation path.