GitHub SHA-1 HTTPS 退場後連不上怎麼查？Git、API 與 CI 修復清單

先確認你遇到的是哪一層#

同樣一句「GitHub 連不上」，可能是完全不同的故障。先記錄失敗入口與錯誤時間，不要把四種環境的 workaround 混在一起：

如果瀏覽器正常但 CI 失敗，優先查 CI image 和 egress；如果 Git 與 API 同時失敗，優先查共用 TLS library 或代理；如果只有一個 repository 失敗，先查權限、URL 和 repository 狀態，不要直接歸因 SHA-1。

第一輪：收集版本與 TLS backend#

在問題環境執行以下指令，輸出可以貼進內部 issue，但要先確認沒有公司代理的敏感資訊：

1
git --version
2
git config --show-origin --get http.sslBackend || true
3
curl --version
4
openssl version -a

Git 可能透過 libcurl 使用 OpenSSL、Secure Transport 或其他 TLS backend；curl —version 的 Features 和 SSL 行會告訴你它實際連到哪套函式庫。不要只在自己的筆電更新 Git，就宣稱 production runner 已修好；CI 裡的 binary、CA bundle 和 proxy route 可能完全不同。

接著用不需要 token 的公開 repository 測 Git HTTPS：

1
GIT_CURL_VERBOSE=1 git ls-remote https://github.com/git/git.git HEAD

這會顯示連線與 TLS／HTTP 協商的診斷資訊，不會替公開 repository 取得寫入權限。若你的環境會把 verbose output 收進共享 log，仍應檢查 host name、代理資訊和自訂 header 是否包含內部細節；不要把含有 Authorization 的 clone URL 貼出來。

API 入口則先做不帶身份的 header request：

1
curl -I https://github.com
2
curl -I https://api.github.com

若 curl 回應 200、301 或 403，但 TLS 已成功建立，問題可能不是 SHA-1，而是 API rate limit、身份驗證、路徑或 proxy policy。這就是為什麼要先把「握手失敗」和「HTTP 層拒絕」分開。

瀏覽器與一般使用者的修復順序#

GitHub 的公告建議使用現代瀏覽器，並可用 https://github.dev 協助確認瀏覽器和 GitHub 的基本相容性。若瀏覽器完全打不開：

1. 先更新瀏覽器與作業系統，重新測試一般無痕視窗。
2. 暫時避開企業 TLS inspection 或受控網路，用可信任的行動網路做對照。
3. 檢查 OS 是否仍使用過期的根憑證與時間設定。
4. 若只有公司網路失敗，把瀏覽器錯誤、proxy 名稱和時間交給網路管理員，不要自行安裝來路不明的根憑證。

「無痕視窗成功」通常只代表 extension、cookie 或本地 policy 有影響，不代表 TLS 相容性已經修好；仍要回到公司實際登入與工作流程驗證。

Git client：更新工具，不要關掉憑證驗證#

舊 Git、舊 libcurl 或舊 OS 元件可能無法接受 GitHub 現在的 HTTPS 憑證鏈。修復要分成三件事：

• 更新 Git 到作業系統與團隊支援的現代版本。
• 更新 base image、libcurl、OpenSSL／Secure Transport 和 ca-certificates。
• 重新測試 Git credential helper、SSH fallback policy 和 HTTPS proxy。

不要用下面的設定當正式解法：

1
# 不要在個人或 CI 設定中保留
2
git config --global http.sslVerify false
3
export GIT_SSL_NO_VERIFY=1

它們只會把憑證驗證關掉，既不能修好舊 TLS backend，也會讓中間人攻擊更難被發現。若升級後仍失敗，請保留 GIT_CURL_VERBOSE=1 的必要片段，確認是否卡在 proxy CONNECT、certificate chain、TLS protocol，還是 GitHub 回傳的 HTTP status。

1
git --version
2
curl --version
3
git ls-remote https://github.com/git/git.git HEAD

API SDK 與 runtime：不要只更新 Git#

如果 Git clone 正常、瀏覽器也正常，但應用程式呼叫 GitHub API 失敗，問題常落在應用程式自己的 HTTP stack：

• Node.js、Python、Java 或 Go runtime 可能連結不同的 TLS／CA 實作。
• container 內的 CA bundle 可能和 host 不同。
• SDK 可能透過公司 proxy 或自訂 agent，繞過系統預設設定。
• 長期運行的 process 可能仍使用舊 container，更新 image 後要真的 rollout。

先在同一個 process environment 中測最小 HTTPS request，再跑完整 SDK workflow。不要為了通過 health check 把證書驗證改成 rejectUnauthorized=false、verify=False 或等效設定；這些是安全退化，不是相容性修復。

GHES 不要套用錯誤的結論#

GitHub 這次公告針對的是 github.com、GitHub Enterprise Cloud、Data Residency 和 partner CDN 的 HTTPS 服務；GitHub Enterprise Server（GHES）不受這次退場直接影響。如果只有自架 GHES 失敗，應查你們自己的 server certificate、反向代理、TLS policy、client trust store 和升級狀態，不能只照抄 github.com 的 workaround。

同理，GitHub CLI 的套件金鑰到期是另一條套件簽章鏈；可以參考GitHub CLI Linux 金鑰輪替的 APT／RPM 排查，但不要把 package signing key、HTTPS certificate chain 和 Git credential 混成同一個「GitHub 金鑰」問題。

建議的驗收矩陣#

修復後，請在真正會執行工作的環境驗證，而不是只在開發者筆電上開首頁：

若只有某一層仍失敗，把錯誤縮小到那一層再處理；不要為了讓一個舊 job 通過，把整個組織的 TLS 驗證關掉。

結論：先更新相容性，再保留驗證能力#

SHA-1 HTTPS 退場的正確處理方式，是把舊瀏覽器、Git／libcurl、API runtime、CA bundle、proxy 和 CI image 一層層更新，並用公開 repo 與 API 做最小可重現測試。先確認失敗發生在 TLS handshake 還是 HTTP／權限層，再決定修哪個元件；憑證驗證必須保留，GHES 也要依自己的部署邊界判斷，不要把 github.com 公告當成所有 GitHub 連線的通用錯誤碼。

常見問題#