Is Your CI/CD Pipeline Ready for GitHub’s SHA-1 Changes?

A GitHub change that looks small on paper can become a real problem when it reaches a CI/CD environment.

GitHub disabled SHA-1 in HTTPS/TLS connections for GitHub.com and partner CDNs. GitHub Enterprise Server is not affected by this specific change.

For developers using a current workstation, this may not require any action. The bigger question is what happens inside your build servers, self-hosted runners, old containers, proxies, and automation systems.

A CI/CD pipeline is rarely just one application. It is a chain of operating systems, Git clients, TLS libraries, runner software, network components, and build tools.

If one part of that chain is outdated, a pipeline can fail even though the application code itself has not changed.

This article walks through what teams should check and how to test their CI/CD environments.

What the SHA-1 Change Means for CI/CD

The first thing to understand is that this is about SHA-1 used in HTTPS/TLS connections.

It is not the same thing as Git commit IDs.

Your CI server may perform operations such as:

GitHub
   |
   | HTTPS
   v
CI Runner
   |
   +-- Clone repository
   +-- Download actions
   +-- Call GitHub APIs
   +-- Download releases
   +-- Upload artifacts

All of these operations can depend on working HTTPS communication.

If an old runner or network component depends on retired cryptographic behavior, the pipeline can start failing.

GitHub's CI system supports both GitHub-hosted and self-hosted runners, so the amount of infrastructure you need to check depends on which model your organization uses.

Why CI/CD Is Different From a Developer Laptop

A developer usually notices when Git stops working.

A CI server is different.

A pipeline may run automatically at:

2 AM
During a release
After a pull request
When a tag is created
When another repository triggers a workflow

There may not be a developer watching the machine when the failure happens.

There is another problem: CI environments are often long-lived.

A self-hosted runner may have been installed months or years ago and continue running without anyone checking its underlying software.

For example:

Self-hosted Runner
       |
       +-- Old OS
       +-- Old Git
       +-- Old TLS libraries
       +-- Corporate proxy
       +-- Custom certificates
       +-- Build tools

Updating only one component may not solve the problem.

GitHub-Hosted Runners vs Self-Hosted Runners

Before checking your environment, identify which type of runner your pipeline uses.

GitHub-Hosted Runners

GitHub manages the underlying runner environment.

Your workflow might contain:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - run: dotnet build
      - run: dotnet test

The infrastructure behind the hosted runner is maintained by GitHub.

That reduces the amount of operating-system maintenance your team needs to perform.

It does not mean you can ignore the workflow itself. Actions, dependencies, custom scripts, proxies, and external services can still introduce failures.

Self-Hosted Runners

With a self-hosted runner, your organization owns much more of the environment.

For example:

Your Organization
       |
       v
Self-Hosted Machine
       |
       +-- Operating System
       +-- Git
       +-- Runner
       +-- TLS
       +-- Certificates
       +-- Proxy
       +-- Build Tools

GitHub requires self-hosted runners to establish outbound HTTPS connections and communicate with the required GitHub endpoints.

This makes self-hosted runners the first place many organizations should investigate.

Start With Your Runner Inventory

Before changing anything, create a list of your CI/CD environments.

For example:

Environment	Runner Type	OS	Git	Runner Version	Proxy
Development	GitHub-hosted	Linux	Managed	Managed	No
Production CI	Self-hosted	Linux	2.x	2.x	Yes
Windows Build	Self-hosted	Windows	2.x	2.x	Yes
Release Server	Self-hosted	Linux	2.x	2.x	No

You do not need complicated tooling to start.

The purpose is simply to find machines that nobody has checked recently.

Check the Git Version

On a self-hosted runner, start with:

git --version

For example:

git version 2.x.x

The exact version you should use depends on your operating system and organization policy.

The important thing is to avoid treating Git as the only dependency.

Git can rely on HTTPS/TLS components provided by the operating system or its packaging environment.

So this:

Current Git
+
Old operating system

does not necessarily mean the entire HTTPS stack is current.

Check the Operating System

On Linux, you can check the operating system with:

cat /etc/os-release

For example:

NAME="Ubuntu"
VERSION="..."

On Windows, check the installed Windows version and patch level.

The objective is to identify unsupported or heavily outdated systems.

This is particularly important for servers that were created from old VM images.

Check the TLS Stack

On Linux systems using OpenSSL, you can inspect the installed version with:

openssl version

For example:

OpenSSL ...

Do not use the version number alone to decide whether a system is compatible.

Git may use a different TLS implementation depending on how it was built.

The useful question is:

What TLS implementation is actually being used
by this Git installation on this machine?

That is more useful than simply asking whether OpenSSL is installed.

Check How Git Connects to GitHub

Look at the repository's remote:

git remote -v

You may see:

origin  https://github.com/company/project.git (fetch)
origin  https://github.com/company/project.git (push)

That means the repository uses HTTPS.

Or:

origin  [email protected]:company/project.git (fetch)
origin  [email protected]:company/project.git (push)

That means it uses SSH.

The SHA-1 HTTPS change specifically concerns HTTPS/TLS connections, so identifying the remote protocol is an important first step.

Test GitHub From the Runner

Do not wait for the production pipeline to fail.

Run a basic Git operation directly from the runner.

For example:

git ls-remote https://github.com/example/example.git

For a private repository, use a repository that the runner is authorized to access.

You can also test the actual workflow:

git fetch

If you have permission to push, test the complete path in a controlled branch.

The goal is to test from the actual CI machine, not from your laptop.

This distinction matters.

Your laptop and CI runner may have completely different:

Operating systems
Git versions
TLS libraries
Certificates
Proxies
Firewall rules

Test the GitHub Actions Runner

GitHub provides a runner diagnostic check for self-hosted runners.

From the runner installation directory, you can use:

./config.sh --check --url https://github.com/YOUR-ORG/YOUR-REPO --pat YOUR_TOKEN

On Windows:

config.cmd --check --url https://github.com/YOUR-ORG/YOUR-REPO --pat YOUR_TOKEN

The check tests runner services and reports PASS or FAIL. GitHub also provides diagnostic logs in the runner's _diag directory.

Use an appropriate token according to your organization's GitHub permissions and security practices.

Do not place long-lived credentials directly into scripts or source control.

Why Self-Hosted Runner Versions Matter

The HTTPS change is not the only maintenance issue facing self-hosted runners.

GitHub has also introduced minimum-version enforcement for self-hosted Actions runners.

GitHub's current guidance says that when automatic runner updates are disabled, organizations must keep the runner updated themselves. If a runner is not updated within the required window, GitHub can stop queuing jobs to it.

This gives organizations another reason to treat runners as maintained infrastructure rather than permanent virtual machines.

A runner should have a lifecycle.

Provision
   |
   v
Configure
   |
   v
Patch
   |
   v
Monitor
   |
   v
Update
   |
   v
Replace

Check Your CI Container Images

Many teams run CI jobs inside containers.

For example:

jobs:
  build:
    runs-on: self-hosted

    container:
      image: ubuntu:latest

    steps:
      - uses: actions/checkout@v4
      - run: dotnet build

In this situation, there are potentially multiple environments to consider.

Host
 |
 +-- Runner software
 |
 +-- Container runtime
 |
 v
CI Container
 |
 +-- Git
 +-- Certificates
 +-- TLS libraries
 +-- Build tools

Updating the host does not automatically update everything inside the container.

If your organization maintains its own CI images, review their base image and installed packages.

Check Custom Docker Images

A common pattern is:

FROM ubuntu:old-version

RUN apt-get update
RUN apt-get install -y git

The image may continue working for a long time after it was created.

That does not mean the image is still a good production dependency.

A better approach is to rebuild CI images regularly.

For example:

Base Image Update
       |
       v
Rebuild CI Image
       |
       v
Run Test Pipeline
       |
       v
Deploy New Runner Image

This also makes security patching easier.

Corporate Proxies Need Attention

A corporate network may place a proxy between your runner and GitHub.

The connection can look like this:

CI Runner
    |
    v
Corporate Proxy
    |
    v
Firewall
    |
    v
Internet
    |
    v
GitHub

Some organizations also perform TLS inspection.

That means the runner may not communicate directly with GitHub's TLS endpoint.

If the same workflow succeeds on a GitHub-hosted runner but fails on a self-hosted runner, compare the network path.

The difference may be the proxy rather than Git itself.

Check Custom Certificate Authorities

TLS inspection and corporate proxies often require custom CA certificates.

GitHub's documentation notes that self-hosted runners may need appropriate certificates installed in the operating system certificate store. For Actions Runner Controller environments, custom CA certificates may also need to be injected into the runner and controller trust stores.

A typical containerized setup might look like:

Corporate CA
     |
     v
Runner Trust Store
     |
     v
TLS Connection
     |
     v
GitHub

If the certificate chain is incomplete, HTTPS connections can fail even when the cryptographic algorithms are otherwise compatible.

Do Not Disable TLS Verification

When a pipeline starts showing TLS errors, somebody may suggest disabling certificate verification.

For example:

git config --global http.sslVerify false

Do not use this as a permanent fix.

It removes an important security check.

GitHub also warns against disabling TLS certificate verification for self-hosted runners. Its documentation recommends installing the required GitHub certificate in the operating system certificate store instead.

The correct approach is:

TLS Error
   |
   v
Find the cause
   |
   +-- Old TLS support
   +-- Old certificate store
   +-- Proxy problem
   +-- Firewall problem
   +-- DNS problem
   +-- Git configuration
   |
   v
Fix the actual problem

Check GitHub Actions Network Access

A CI runner needs more than access to one GitHub URL.

Depending on the workflow, runners may need to communicate with GitHub and other services used to download actions, releases, dependencies, or tools.

GitHub's documentation lists github.com, api.github.com, and *.githubusercontent.com among the endpoints commonly required by Actions workflows. Additional endpoints can be required by particular ecosystems and actions.

If your organization uses a strict outbound firewall, review the allowlist rather than assuming that github.com alone is sufficient.

Watch for Download Failures

A pipeline can successfully check out your repository and still fail later.

For example:

Checkout
   |
   v
Success
   |
   v
Download Action
   |
   X
TLS / Network Failure

Or:

Checkout
   |
   v
Build
   |
   v
Download Dependency
   |
   X
Network Failure

This is why testing only:

git clone

is not always enough.

Run a complete representative workflow.

Use a Small CI Health Check

You can add a diagnostic step to a controlled workflow.

For example:

steps:
  - name: Check Git
    run: git --version

  - name: Check OS
    run: cat /etc/os-release

  - name: Check OpenSSL
    run: openssl version

  - name: Check GitHub connectivity
    run: git ls-remote https://github.com/example/example.git

For Windows runners, use PowerShell commands appropriate to the environment.

Do not expose credentials or sensitive infrastructure information in the workflow logs.

The goal is to make infrastructure problems visible before they become release failures.

Check Self-Hosted Runner Auto-Updates

GitHub Actions self-hosted runners normally update automatically when a new runner version is available.

Organizations can disable automatic updates with the --disableupdate option, but GitHub requires those installations to be maintained manually. GitHub states that runners with updates disabled still need to be updated regularly.

If your environment uses:

./config.sh --disableupdate

make sure there is an explicit process for:

Tracking runner releases
Testing new versions
Updating runner images
Replacing old runners
Monitoring failed updates

If nobody owns that process, the configuration becomes technical debt.

Build a Runner Upgrade Process

A simple process can look like this:

Step 1: Inventory

List every self-hosted runner.

Step 2: Identify Dependencies

Record:

OS
Git
Runner
TLS
Certificates
Proxy
Container Runtime
Build Tools

Step 3: Test

Run a representative workflow.

Step 4: Update

Upgrade outdated components.

Step 5: Test Again

Run build, test, package, and deployment workflows.

Step 6: Replace Old Infrastructure

Remove runners that cannot be maintained.

This is much safer than updating every production runner at the same time.

A Practical CI/CD Readiness Checklist

Before considering your environment ready, verify:

Area	Check
Git	Current supported version
Runner	Current supported version
OS	Supported and patched
TLS	Modern cryptographic support
Certificates	Trust store is current
Proxy	TLS inspection is compatible
Firewall	Required GitHub endpoints are reachable
Containers	Base images are maintained
Actions	Dependencies are maintained
Testing	Real CI workflow has passed
Monitoring	Runner failures are visible
Rollback	Previous runner image/version is available

This checklist is especially useful for organizations with several self-hosted runners.

A Simple Test Workflow

For a controlled environment, you can create a small workflow to verify basic connectivity and runner information:

name: Runner Health Check

on:
  workflow_dispatch:

jobs:
  health-check:
    runs-on: self-hosted

    steps:
      - name: Check Git
        run: git --version

      - name: Check OpenSSL
        run: openssl version

      - name: Check GitHub connectivity
        run: git ls-remote https://github.com/example/example.git

      - name: Check repository
        uses: actions/checkout@v4

      - name: Test build
        run: dotnet build

Replace the example repository and build command with values appropriate for your project.

The purpose is not to create a universal compatibility test.

It is to give your infrastructure team a repeatable way to test the complete runner environment.

What If the Pipeline Is Already Failing?

Do not immediately change the workflow.

First determine where the failure occurs.

Use this sequence:

Pipeline Failure
      |
      v
Checkout failure?
      |
      +-- Yes --> Check Git / TLS / Proxy
      |
      +-- No
      |
      v
Action download failure?
      |
      +-- Yes --> Check GitHub endpoints / TLS
      |
      +-- No
      |
      v
Dependency download failure?
      |
      +-- Yes --> Check package source/network
      |
      +-- No
      |
      v
Build or test problem

This keeps the investigation focused.

A TLS-related failure during checkout should not lead to changing application code or dependency versions.

What Teams Should Avoid

Do Not Assume GitHub-Hosted and Self-Hosted Runners Are Identical

They are not.

A GitHub-hosted runner and a self-hosted runner can have completely different infrastructure.

Do Not Update Only Git

A modern Git executable does not guarantee that every component of the HTTPS stack is current.

Do Not Ignore Container Images

An old container can contain old Git, certificates, and TLS libraries even when the host machine is fully patched.

Do Not Disable TLS Verification

It may hide the problem while weakening connection security.

Do Not Wait for Production

Run the checks before a release depends on the affected environment.

Summary

GitHub's SHA-1 HTTPS change is a good reminder that CI/CD infrastructure needs regular maintenance.

The application source code may be perfectly fine while the pipeline fails because an old runner, operating system, TLS library, certificate store, container image, or proxy cannot establish the required HTTPS connection.

For most teams, the practical process is straightforward:

Inventory
   |
   v
Check runners
   |
   v
Check Git and OS
   |
   v
Check TLS and certificates
   |
   v
Check proxies and firewalls
   |
   v
Run a real pipeline
   |
   v
Update or replace old infrastructure

GitHub-hosted runners reduce the amount of infrastructure your team needs to maintain, while self-hosted runners require an explicit update and monitoring process. GitHub also continues to enforce supported runner versions, so keeping self-hosted runners current is important beyond this specific SHA-1 change.

The most useful lesson is not simply "update Git."

Treat the entire CI/CD runner as a software system. Keep the operating system, Git, runner software, TLS stack, certificates, container images, proxies, and network configuration maintained together.

That approach makes cryptographic changes like this much easier to handle without waiting for the next failed production deployment.