Android 12 ve Android 15'te HTTPS Hatalarını Hızlıca Nasıl Düzeltirsiniz

Kısa cevap: Android 12 ve 15, TLS gereksinimlerini sıkılaştırdı — varsayılan olarak zorunlu HTTPS, sıkı sertifika zinciri doğrulaması, eski algoritmaların yasaklanması ve kullanıcı CA'larına olan güvenin kısıtlanması. İşlevselliği geri kazanmak için: sunucuda zincir ve SNI kontrolü yapın, ortamlar için network_security_config ayarlayın, HTTP istemcilerini güncelleyin ve pinning ile hata ayıklama için güvenli yaklaşımlar kullanın.

Android 12 ve Android 15'te Ne Değişti

HTTPS bağlantılarının çalışmasını etkileyen temel değişiklikler:

• Açıkça izin verilmediği sürece zorunlu HTTPS ve düz HTTP'nin engellenmesi (CLEARTEXT not permitted).
• Sertifika zinciri daha sıkı kontrol ediliyor: ara sertifika eksikliği, iptal edilmiş veya süresi dolmuş kök sertifika artık daha sık hata veriyor.
• CN/SAN ve ana makine adı doğrulaması için katı gereksinimler (wildcard tam eşleşmelidir).
• Eski protokollerin/şifrelerin devre dışı bırakılması (TLS 1.0/1.1, zayıf şifreler) — özellikle Android 15'te.
• Kullanıcı tarafından eklenen (user‑added) CA'lara olan güvenin kısıtlanması — kurumsal proxy'ler ve kendi imzalanan CA'lar ek ayarlar olmadan çalışmayı durdurabilir.

Android 12, "varsayılan olarak güvenli" modelini güçlendirdi; Android 15 ise eski algoritmalar için filtreleme ekledi ve ara sertifikalar ile kullanıcı CA'ları konusunda politikayı sıkılaştırdı.

Sunucu ve Sertifika Tanılaması — Önce Neyi Kontrol Etmeli

Sunucuyu tarayıcının gördüğü gibi değil, mobil uygulamanın gördüğü gibi kontrol edin.

Kontrol adımları:

1. Zincir kontrolü: Sunucunun tüm ara sertifika setini gönderdiğinden emin olun. Birçok istemci sizin yerinize ara sertifikaları "çekmez".
2. Protokoller ve şifreler: Sunucu TLS 1.2+ desteklemelidir; TLS 1.0/1.1 ve zayıf şifre takımlarını devre dışı bırakın.
3. CN/SAN: SAN, istek alan adını (SNI) içermelidir. api.example.com adresine erişilirken sertifika wildcard olmadan example.com üzerinde olamaz.
4. Kök CA: Kök sertifika yetkilisi sistemdeki güvenilir CA deposunda bulunmalıdır; kendi imzalanan ve eski kökler CERTIFICATE_UNKNOWN hatasının nedenidir.
5. Testler: curl -v ile --tlsv1.2, openssl s_client -showcerts -servername ve çevrimiçi/CLI SSL kontrol araçları (bağlantı yok) gerçek zinciri gösterir.

Geliştirici Adımları: Nasıl Düzeltilir ve Güvenlik Bozulmaz

1. network_security_config Ayarlayın

• Debug derlemeleri için test CA'sı ekleyebilir ve yalnızca yerel ana makineler için HTTP'ye izin verebilirsiniz.
• Release sürümü için sıkı politika bırakın: yalnızca HTTPS, sıkı ana makine adı doğrulaması.

Minimal network_security_config örneği (debug yalnızca test CA'sı için):

<network-security-config>
  <domain-config cleartextTrafficPermitted="false">
    <domain includeSubdomains="true">api.example.com</domain>
    <trust-anchors>
      <certificates src="system"/>
    </trust-anchors>
  </domain-config>

  <!-- debug: yalnızca debug derlemesinde yerel CA'ya güven -->
  <debug-overrides>
    <trust-anchors>
      <certificates src="@raw/dev_ca"/>
    </trust-anchors>
  </debug-overrides>
</network-security-config>

2. HTTP İstemcisini ve Kripto Kütüphanelerini Güncelleyin

• OkHttp/Retrofit/Ktor'un güncel sürümlerine geçiş yapın; eski sürümler SNI, TLS 1.2+ veya yeni CA'ları desteklemeyebilir.
• Doğrulamayı devre dışı bırakan özel TrustManager'ları kaldırın. Gerekirse, kanıtlanmış kütüphaneleri ve standart API'leri kullanın.

3. Sertifikaların Doğru Hata Ayıklaması

• Debug için ayrı konfigürasyonlar kullanın; SSLHandshakeException hatalarını tam yığın iziyle günlüğe kaydedin.
• Sertifika pinning uyguluyorsanız — birkaç geçerli anahtar/sertifika hazırlayın (yedek pinler) ve rotasyon sürecini belgeleyin.

4. Sunucu Tarafı

• Tam zinciri gönderin; ara/kök sertifikanın süresinin dolup dolmadığını periyodik olarak kontrol edin.
• SNI desteğini etkinleştirin ve sanal ana makineleri kontrol edin.
• OCSP/CRL'yi (gerekirse) doğru şekilde yapılandırın, ancak temel doğrulama için yalnızca bunlara güvenmeyin.

Tablo: Yaygın Hatalar ve Hızlı Nedenler

Sık Yapılan Hatalar

• Performans için TrustManager'da kontrolleri devre dışı bırakmak — MITM saldırısına yol açar.
• Release derlemesinde test CA'ları kullanmak — istemciler güvenilmeyen merkezlere güvenmeye başlar.
• Yedek pinler olmadan güçlü pinning — sertifika rotasyonunda uygulama çalışmayı durdurur.
• Yerelde her şey çalışıyor ama hedef cihazlarda çalışmıyor: Hedef Android sürümünü (12/15) özellikle kontrol etmiyorsunuz.

SSS

• Her zaman genel CA'ya geçmek gerekir mi?
  Üretim ortamı için evet, güvenilir bir genel CA veya uygulamada belgelenmiş kurulumla doğru dağıtılmış dahili PKI kullanın.

• Kullanıcı CA'larını tamamen yasaklamak mümkün mü?
  Evet: network_security_config yalnızca sistem CA'larına güvenmeye ve kullanıcı tarafından eklenen CA'ları yok saymaya olanak tanır.

• Sertifika rotasyonundan sonra hatalar oluşursa ne yapılmalı?
  Yeni sertifikanın zincire dahil edildiğinden, doğru SAN'e sahip olduğundan ve pinning'in (varsa) yedek pinler kullanılarak önceden güncellendiğinden emin olun.

Adım adım ilerlerseniz — sunucu zincirini kontrol etmek, TLS/şifreleri düzenlemek, network_security_config'i ayarlamak ve istemcileri güncellemek — Android 12 ve 15'teki HTTPS sorunlarının çoğu hızlı ve güvenli bir şekilde çözülür.