GitHub 15 Eylül 2026’da SHA-1 HTTPS Desteğini Kapatıyor: Kurumsal Geçiş Rehberi
GitHub ve iş ortağı CDN’lerinde SHA-1 tabanlı HTTPS/TLS desteğinin kaldırılmasından önce Git istemcileri, otomasyonlar, proxy’ler ve eski işletim sistemleri nasıl test edilmeli?
15 Eylül’de ne değişiyor?
GitHub, HTTPS ve TLS bağlantılarında SHA-1 desteğini 15 Eylül 2026 tarihinde GitHub ile iş ortağı CDN’lerinde tamamen kapatacağını duyurdu. Değişiklik modern istemcileri etkilememeli; ancak eski işletim sistemleri, güncelliğini yitirmiş TLS kitaplıkları ve kurumsal ara katmanlar bağlantı sorunu yaşayabilir.
Bu çalışma Git commit imzalarındaki SHA-1 tartışmasıyla karıştırılmamalıdır. Buradaki kapsam, GitHub’a HTTPS üzerinden bağlanan tarayıcıların, Git istemcilerinin, API entegrasyonlarının ve otomasyonların TLS el sıkışmasıdır.
Hangi sistemler risk altında?
Eski OpenSSL, GnuTLS, libcurl veya işletim sistemi şifreleme bileşenlerini kullanan Git kurulumları öncelikli kontrol grubundadır. Güncellenmeyen yapı sunucuları, gömülü cihazlar, eski konteyner imajları ve uzun süredir değiştirilmeyen otomasyon makineleri görünür envanterin dışında kalabilir.
Trafiği sonlandıran kurumsal proxy, güvenlik ağ geçidi veya TLS inceleme ürünü de istemci modern olsa bile eski algoritmayı yeniden kullanabilir. Bu nedenle test yalnızca geliştirici dizüstü bilgisayarlarında yapılmamalıdır.
- GitHub’a HTTPS ile bağlanan tüm otomasyonları listeleyin.
- Git, curl ve TLS kitaplığı sürümlerini kaydedin.
- Proxy ve TLS inceleme katmanlarını envantere ekleyin.
- Eski konteyner ve self-hosted runner imajlarını ayrı kontrol edin.
Güvenli test nasıl yapılır?
GitHub, modern HTTPS yapılandırmasını sınamak için https://github.dev adresini öneriyor; bu uç noktada SHA-1 zaten devre dışıdır. Aynı ağ yolu ve kimlik doğrulama ortamından bu adrese erişim, istemci zincirinin yeni yapılandırmayla çalışabildiğine dair pratik bir işaret sağlar.
Tarayıcı testi tek başına Git otomasyonunu kanıtlamaz. Kaynak kodu çeken, API çağrısı yapan ve paket indiren süreçler kendi çalışma hesabı, proxy ayarı ve gerçek çalışma ortamında ayrıca sınanmalıdır.
- Temsilî istemcilerden github.dev bağlantısını doğrulayın.
- Salt okunur bir depoda HTTPS klonlama ve çekme testi yapın.
- API ve paket kayıt defteri entegrasyonlarını çalıştırın.
- Başarısızlıkları istemci, proxy ve TLS kitaplığına göre sınıflandırın.
Güncelleme ve geri dönüş planı
Başarısız istemcilerde desteklenen işletim sistemi, güncel Git ve modern TLS kitaplıklarına geçiş yapılmalıdır. Sadece sertifika doğrulamasını kapatmak veya güvenli olmayan algoritmaları yeniden etkinleştirmek kalıcı çözüm değildir.
Üretim otomasyonlarında değişiklik önce pilot runner veya test iş akışında uygulanmalıdır. Geri dönüş planı eski ve güvensiz algoritmaya dönüş yerine, çalışan son imajı koruma ve iş yükünü güncel bir ortama taşıma üzerine kurulmalıdır.
15 Eylül günü izleme
Değişiklik günü GitHub bağlantı hataları, TLS el sıkışma uyarıları, depo klonlama başarısızlıkları ve API hata oranları merkezi olarak izlenmelidir. Hata mesajları zaman, istemci sürümü ve ağ yolu bilgisiyle kaydedilmelidir.
Başarısız bağlantıda SSL doğrulamasını kapatmayın. Bu yaklaşım aktarım güvenliğini zayıflatır; doğru çözüm desteklenen şifreleme zincirine geçmek ve ara katman yapılandırmasını düzeltmektir.
Kapanış kanıtı
Kapanış raporunda test edilen istemciler, otomasyonlar, proxy’ler ve sonuçları bulunmalıdır. İstisna kalan sistemlerin iş sahibi, telafi edici kontrolü ve kesin yenileme tarihi kayıt altına alınmalıdır.
Değişiklik tamamlandıktan sonra kullanılmayan eski runner ve konteyner imajları kaldırılmalı, temel imaj politikaları güncellenmelidir. Böylece benzer kriptografik geçişlerde aynı teknik borç yeniden oluşmaz.