Introduction

TLS configuration is usually something developers do once and rarely think about again. That changes when a service removes support for a cryptographic configuration that an application, proxy, or security appliance depends on.

GitHub has announced a change affecting GitHub Enterprise Cloud with data residency. Beginning October 7, 2026, those endpoints will no longer accept TLS connections from clients that offer only the X25519 key-agreement group. GitHub will continue to support the FIPS-approved P-256 and P-384 groups.

For most developers, this should not require any changes. Modern browsers, operating systems, GitHub CLI versions, and commonly used TLS libraries already support P-256. The issue mainly affects environments where TLS has been explicitly restricted to X25519.

That means the important question is not whether your application uses X25519 somewhere in its TLS stack. The question is whether the client is configured to offer only X25519.

What Is Changing?

TLS uses a key-agreement mechanism during connection establishment. The client and server negotiate a compatible group before establishing the encrypted session.

X25519 is one such elliptic-curve Diffie-Hellman key-agreement group.

GitHub's upcoming change affects clients that offer only X25519 when connecting to GitHub Enterprise Cloud with data residency.

After October 7, an X25519-only client will not be able to establish an HTTPS connection to the affected endpoints.

The supported FIPS-approved groups include:

GitHub specifically recommends ensuring P-256 is enabled and removing X25519-only configurations. P-384 can also be enabled.

This change does not mean X25519 is being removed from TLS generally. It means the affected GitHub endpoints will no longer accept a client that has restricted its available key-agreement groups to X25519 alone.

Who Is Actually Affected?

Most developers are unlikely to be affected.

The environments worth checking are those where TLS settings have been manually hardened or restricted.

Examples include:

A normal application using an up-to-date runtime with default TLS settings will typically negotiate a compatible group automatically.

The risk increases when an administrator has configured something similar to:

X25519 only

rather than allowing multiple compatible groups.

Why Developers Should Care

A TLS failure can look like an application outage even though the application code itself has not changed.

For example:

Application
    |
    v
Corporate Proxy
    |
    v
GitHub Enterprise Cloud

If the application supports P-256 but the corporate proxy restricts the connection to X25519, the connection can still fail.

This is why simply upgrading application code may not resolve the problem.

The TLS negotiation can happen across several layers:

Application
    |
Runtime
    |
TLS Library
    |
Operating System
    |
Proxy / Security Appliance
    |
Network
    |
GitHub

The component enforcing the restriction may be outside the application repository entirely.

X25519 vs P-256

The issue becomes easier to understand when looking at the available key-agreement groups.

Group

Description

Relevant to the change

X25519

Elliptic-curve key agreement based on Curve25519

Supported, but X25519-only clients will fail

P-256

NIST P-256 / secp256r1

Must be available for affected clients

P-384

NIST P-384 / secp384r1

Also supported

X25519 + P-256

Multiple negotiation options

Better compatibility

The problem is therefore not simply "X25519 is unsupported."

The problem is an overly restrictive client configuration.

Check Whether Your Application Uses HTTPS

Start by identifying applications and infrastructure that connect to GitHub using HTTPS.

Common examples include:

GitHub API clients
GitHub CLI
Git clients using HTTPS remotes
CI/CD integrations
Package publishing tools
Deployment services
Internal developer tools

Check Git remotes with:

git remote -v

An HTTPS remote might look like:

https://github.example.com/team/project.git

SSH remotes are different:

[email protected]:team/project.git

The X25519 TLS change discussed here concerns HTTPS connections. GitHub's announcement specifically states that SSH connectivity is not affected by this October 7 change.

Check Your Runtime and TLS Library

The next step is identifying the TLS implementation used by your application.

For a .NET application, TLS behavior generally depends on the runtime and operating system's cryptographic stack.

A useful first check is to determine the runtime version:

dotnet --info

Also inspect the operating system and container image used by the application.

For example:

cat /etc/os-release

On Linux environments, OpenSSL is commonly part of the TLS stack used by applications.

Check the installed OpenSSL version:

openssl version -a

The exact TLS behavior depends on the runtime, operating system, TLS library, and configuration, so the version alone does not prove whether a client is affected.

Look for Explicit X25519 Configuration

Search application and infrastructure configuration for TLS group restrictions.

For example, look for settings containing terms such as:

X25519
secp256r1
P-256
supported groups
elliptic curves
TLS groups

Search a repository on Linux or macOS with:

grep -Rni "X25519" .

On Windows PowerShell:

Get-ChildItem -Recurse -File | Select-String "X25519"

Remember that the configuration might not be inside the application source code.

A proxy, load balancer, gateway, container image, or operating-system configuration may be responsible.

The Most Important Fix: Remove X25519-Only Restrictions

If your environment explicitly allows only X25519, change the configuration so that P-256 is also available.

Conceptually, the configuration should move from:

X25519

to something similar to:

X25519
P-256
P-384

The exact configuration depends on the TLS implementation or security appliance.

Do not blindly copy a cipher or curve configuration from another system. TLS configuration syntax differs between OpenSSL, application runtimes, proxies, load balancers, and security products.

The goal is simple:

Ensure the client can negotiate P-256 instead of restricting negotiation to X25519.

Example: Testing TLS Negotiation

OpenSSL can be useful for inspecting TLS connectivity.

A basic connection test can be performed with:

openssl s_client -connect example.github-host.com:443

For a specific elliptic-curve test, OpenSSL supports configuration options depending on the installed version.

For example:

openssl s_client \
  -connect example.github-host.com:443 \
  -groups P-256

The exact command-line options can vary by OpenSSL version.

The purpose of this test is to determine whether the endpoint can establish a TLS connection when P-256 is offered.

Do not treat a successful test from one workstation as proof that every production client is compatible. The production proxy, runtime, operating system, and network path may be different.

Test the Application Path, Not Just the Developer Machine

One common mistake is testing TLS from a developer laptop and assuming the production environment behaves identically.

Consider this architecture:

Developer Laptop
      |
      v
Internet
      |
      v
GitHub

Production may look like:

Application
      |
      v
Container
      |
      v
Corporate Proxy
      |
      v
Security Gateway
      |
      v
GitHub Enterprise Cloud

The second path contains additional components that can modify TLS negotiation.

Therefore, production validation should happen from the same network path and runtime used by the application.

Updating Older Components

GitHub recommends updating the operating system, runtime, GitHub CLI, proxy, and TLS libraries to supported versions when necessary.

A practical upgrade sequence is:

  1. Identify the affected application or integration.

  2. Record its runtime and operating-system versions.

  3. Identify the TLS library.

  4. Inspect proxy and gateway configuration.

  5. Look for X25519-only restrictions.

  6. Enable P-256.

  7. Test against the affected GitHub endpoint.

  8. Deploy the configuration to a staging environment.

  9. Validate the complete production network path.

  10. Roll out the change before October 7.

Avoid upgrading unrelated infrastructure simply because it is old. First identify the component controlling TLS negotiation.

What About GitHub CLI?

The GitHub announcement states that current GitHub CLI releases support the required configuration.

If your organization pins an old CLI version, upgrading it should be part of the compatibility review.

Check the installed version:

gh --version

Then test the GitHub operations used by your environment.

For example:

gh auth status

A successful command does not necessarily test every network path used by your application, but it can help identify obviously outdated client environments.

What About Git Over HTTPS?

Git operations that use HTTPS depend on the TLS stack underneath the Git client.

Check the configured remote:

git remote -v

If it uses HTTPS, verify that the Git client and its TLS backend are current.

Check the Git version:

git --version

Then test a repository operation:

git fetch

If the application works but Git operations fail, the problem may be specific to the Git client, its TLS backend, or an intermediary proxy.

Troubleshooting TLS Connection Failures

If connections fail after the change, work from the outside inward.

1. Check the Endpoint

Verify that the application is connecting to the intended GitHub Enterprise Cloud endpoint.

2. Check the Network Path

Determine whether a proxy, firewall, or TLS inspection device sits between the application and GitHub.

3. Check TLS Groups

Look for an X25519-only configuration.

4. Check P-256

Confirm that secp256r1 or P-256 is enabled.

5. Check the Runtime

Determine whether the runtime and operating system are supported.

6. Check the TLS Library

Inspect the version and configuration of the TLS implementation.

7. Test Outside the Application

Use appropriate TLS diagnostic tools to determine whether the problem occurs before application-level communication begins.

8. Compare Environments

Compare development, staging, and production configurations.

A useful troubleshooting table is:

Symptom

Possible Cause

TLS handshake fails

Unsupported or restricted key-agreement groups

Developer machine works, production fails

Proxy or gateway configuration

Git operations fail

Git/TLS backend issue

API client fails

Runtime or TLS library configuration

All applications fail

Shared network or security appliance

Only one application fails

Application-specific TLS settings

Common Mistakes

Assuming X25519 Is Being Removed Everywhere

The change is specifically about clients that offer only X25519 to the affected GitHub Enterprise Cloud with data residency endpoints.

It is not a general removal of X25519 from TLS.

Changing Cipher Suites Instead of TLS Groups

Cipher suites and key-agreement groups are related to TLS negotiation but are not the same configuration concept.

Changing unrelated cipher settings may not fix an X25519-only group restriction.

Testing Only From a Laptop

Production infrastructure can have completely different TLS behavior.

Disabling TLS Security

Do not solve compatibility problems by weakening TLS verification or disabling certificate validation.

The goal is to expand compatible key-agreement options, not reduce transport security.

Waiting Until the Deadline

Infrastructure changes involving proxies and security appliances often require change management, testing, and deployment windows.

The October 7 deadline leaves little reason to postpone compatibility checks if your environment uses custom TLS configuration.

Best Practices

  1. Keep operating systems and TLS libraries supported.

  2. Avoid unnecessary TLS group restrictions.

  3. Ensure P-256 is available where required.

  4. Document custom TLS configurations.

  5. Treat proxies and security appliances as part of the application's network dependency chain.

  6. Test production network paths, not only developer machines.

  7. Include TLS compatibility tests in infrastructure changes.

  8. Keep GitHub CLI and Git clients current.

  9. Avoid disabling certificate validation as a workaround.

  10. Record TLS configuration changes in infrastructure-as-code where possible.

  11. Validate changes in staging before production.

  12. Review other external services when making shared TLS changes.

What Developers Should Do Before October 7

For most teams, the review can be relatively small.

Use this checklist:

[ ] Identify applications connecting to GitHub Enterprise Cloud with data residency
[ ] Check GitHub CLI and Git versions
[ ] Check runtime and OS versions
[ ] Identify TLS libraries
[ ] Identify proxies and TLS inspection devices
[ ] Search for X25519-only configuration
[ ] Enable P-256 where required
[ ] Test HTTPS connectivity
[ ] Test Git/API operations
[ ] Validate the production network path
[ ] Deploy before October 7

If your environment uses standard, current TLS defaults, there may be nothing to change.

If your organization deliberately restricted TLS groups, this is the configuration worth investigating first.

Summary

GitHub's October 7 TLS change is primarily a compatibility issue for clients that have been configured to offer only X25519 when connecting to GitHub Enterprise Cloud with data residency.

Modern clients generally already support P-256, so many developers will not need to make changes. The environments that deserve attention are those with custom TLS policies, older runtimes, security appliances, proxies, or manually restricted cryptographic settings.

The practical fix is not to disable security or remove TLS protections. Instead, review the TLS negotiation configuration, ensure P-256 is available, update outdated components where necessary, and test the complete production connection path.

For teams with customized enterprise networking, checking this before October 7 is much simpler than discovering a TLS handshake failure during a deployment or GitHub integration outage.