GitHub’a erişen eski bir istemci bugün aniden TLS hatası veriyorsa sorun parolanızda, erişim belirtecinizde veya Git deposunda olmayabilir. GitHub, 15 Eylül 2026’da github.com ve ortak CDN’lerinde HTTPS bağlantıları için SHA‑1 kullanımını planlandığı gibi kapattığını açıkladı. GitHub Enterprise Cloud ile veri yerleşimli Enterprise Cloud da kapsamda; şirket içinde kurulu GitHub Enterprise Server ise bu değişiklikten etkilenmiyor.

Bu duyuru, Git nesnelerindeki SHA‑1’den veya commit kimliklerinden farklı bir katmanı anlatıyor. Konu, istemci ile GitHub arasındaki HTTPS/TLS bağlantısında eski SHA‑1 tabanlı imza algoritmalarının artık kabul edilmemesi. Modern tarayıcı, Git ve işletim sistemi sürümlerinde çoğu kullanıcı hiçbir şey fark etmeyecek. Asıl risk, yıllardır güncellenmeyen sunucu, ağ cihazı, gömülü istemci, kurumsal proxy ve eski CI kalıplarında.

Değişiklik tam olarak neyi kapsıyor?

GitHub’ın 15 Eylül tarihli kaydı kısa ve net: SHA‑1, github.com ve GitHub’ın ortak CDN’lerindeki HTTPS için devre dışı. Önceki duyuruda verilen takvim uygulanmış durumda. Bu nedenle “yakında olacak” diye ertelemek yerine, hata yaşayan sistemde TLS zincirini ve istemci yeteneklerini şimdi ölçmek gerekiyor.

Burada üç kavramı ayırın:

  • HTTPS/TLS imzası: Bu yazının konusu; bağlantı kurulurken kullanılan kriptografik yeteneklerdir.
  • Git commit kimliği: Depo geçmişindeki nesne adreslemesidir; bu duyuru commit hash’lerini dönüştürmez.
  • SSH bağlantısı: git@github.com biçimindeki erişim farklı protokol ve anahtarlarla çalışır. HTTPS kapatması, SSH’ı doğrudan değiştirmez.

Kimler önce test yapmalı?

Türkiye’de özellikle uzun ömürlü muhasebe, üretim ve kurum içi uygulamalara bağlı otomasyonlar riskli grupta. Eski Ubuntu/CentOS tabanlı container’lar, Java çalışma zamanı güncellenmemiş entegrasyonlar, TLS trafiğini yeniden imzalayan güvenlik cihazları ve yıllardır dokunulmayan self-hosted runner’lar listenin başında. Sorun kullanıcı bilgisayarında görünmese bile gece çalışan yedekleme veya dağıtım işi başarısız olabilir.

Beş dakikalık pozitif test

Aşağıdaki komutlar depo değiştirmez; istemci sürümünü ve HTTPS erişimini ölçer:

git --version
curl --version
curl -Iv https://github.com/
git ls-remote https://github.com/git/git.git HEAD

curl bağlantıyı kuruyor ve git ls-remote bir HEAD değeri döndürüyorsa temel HTTPS yolu çalışıyor demektir. Testi yalnız dizüstü bilgisayarınızda değil, gerçek CI runner’ında ve kullanılan container imajının içinde çalıştırın. Kurumsal proxy varsa aynı testi proxy açık ve mümkünse doğrudan ağda karşılaştırın.

Negatif kontrol neden gerekli?

Başarılı tek deneme, bütün sistemlerin sağlıklı olduğunu kanıtlamaz. En eski üretim imajınızı, felaket kurtarma sunucusunu ve nadiren çalışan zamanlanmış işleri ayrıca bulun. Envanterde son güncelleme tarihi, işletim sistemi, Git/cURL/OpenSSL sürümü ve GitHub’a çıkan ağ yolu yer alsın. Bu liste, “bende açılıyor” sonucunu kurumsal güvenceye dönüştürür.

Hata çıktısında neye bakılır?

handshake failure, unsupported signature algorithm, certificate verify failed veya güvenli bağlantı kurulamaması gibi iletiler görülebilir. Ancak aynı belirtiler, yanlış saat, eksik kök sertifika, TLS incelemesi yapan proxy veya bozuk sertifika zincirinden de kaynaklanabilir. Hata mesajını tek başına “SHA‑1 sorunu” diye etiketlemeyin.

Önce saat ve kök sertifika deposunu kontrol edin; ardından aynı URL’yi farklı güncel bir istemciyle deneyin. Kurumsal proxy sertifikayı yeniden imzalıyorsa, tarayıcıdaki sertifika düzenleyenini ve komut satırındaki TLS ayrıntılarını karşılaştırın. GitHub’ın sertifikası yerine kurum içi bir sertifika görünüyorsa sorunun çözüm noktası proxy olabilir.

Güvenli düzeltme sırası

  1. Etkilenen istemciyi ve gerçek ağ yolunu kaydedin.
  2. İşletim sistemi, Git, cURL/OpenSSL ve kök sertifika paketlerini desteklenen sürüme yükseltin.
  3. Container kullanıyorsanız yalnız üst etiketi değiştirmeyin; imajı önbelleksiz yeniden üretip aynı komutları içeride çalıştırın.
  4. TLS sonlandıran proxy veya güvenlik cihazının SHA‑2 destekli sertifika ve imza yapılandırmasını üretici belgesiyle doğrulayın.
  5. Başarılı testin tarihini, imaj etiketini ve sürümleri kayıt altına alın.

Türkiye’de kurumsal ağ için örnek senaryo

Bir yazılım ekibi İstanbul’daki ofiste güncel dizüstü bilgisayarlardan GitHub’a sorunsuz erişirken veri merkezindeki eski runner hata verebilir. İki sistem aynı depoyu kullansa da ofis trafiği doğrudan, runner trafiği TLS incelemesi yapan farklı bir güvenlik cihazından geçiyor olabilir. Bu durumda erişim belirtecini yenilemek sonucu değiştirmez. Runner üzerinde curl -Iv çıktısındaki sertifika düzenleyenini kaydedin, aynı testi güncel bir imajla tekrarlayın ve ağ ekibinden cihazın desteklediği imza algoritmalarını doğrulamasını isteyin. Böylece uygulama, işletim sistemi ve ağ katmanlarını birbirine karıştırmadan ilerlersiniz.

Doğrulamayı kapatan seçenekler, sertifika denetimini atlamak veya rastgele bir sertifikayı güvenilir depoya eklemek çözüm değildir. Bunlar aradaki adam saldırılarına karşı korumayı zayıflatır. GitHub CLI paket anahtarı geçişinde olduğu gibi, kriptografik sorunlarda kestirme yol yerine kaynağı ve güven zincirini doğrulamak gerekir. İlgili kontrol adımları için GitHub CLI imza anahtarı rehberine de bakabilirsiniz.

Kısa kontrol listesi

  • HTTPS kullanan GitHub entegrasyonlarının envanteri çıkarıldı mı?
  • En eski runner ve container imajı gerçek ortamda test edildi mi?
  • Git, cURL/OpenSSL ve kök sertifika paketleri desteklenen sürümde mi?
  • Kurumsal proxy bağlantıyı yeniden imzalıyor mu?
  • Düzeltme sonrası curl ve git ls-remote birlikte başarılı mı?
  • Sertifika doğrulamasını kapatan geçici seçenekler temizlendi mi?

Çoğu güncel sistem için bu geçiş görünmez olacak. Fakat tek bir eski runner bile dağıtımı durdurabileceği için en değerli adım, hatayı beklemek değil en eski istemciyi bugün ölçmektir.

Kaynak

İlgili rehber: SSL sertifika zincirini uç, ara ve kök sertifikalarla kontrol etme.