İki bağımsız müşteri, sertifikalarının geçerli ve doğru şekilde yüklenmiş olmasına rağmen Android kullanıcılarını etkileyen SSL hatalarını bildirdi. Masaüstü tarayıcıları hiçbir hata göstermezken, belirli mobil cihazlar bağlantıları güvenilmez olarak reddetti.
Vaka Çalışması Özeti
- Sorun: Yeni CA zincirleri eski Android cihazlar tarafından güvenilmiyordu.
- Etki: Mobil kullanıcılar geçerli sertifikalara rağmen SSL hatalarıyla karşılaştı.
- Kök neden: Android güven depoları CA zinciri geçişlerinin gerisinde kalıyor.
- Çözüm: Eski veya çapraz imzalı zincirler kullanarak yeniden düzenleme veya daha iyi mobil uyumluluğa sahip bir CA’ya geçiş.
- Ana görüş: SSL güveni sadece sertifika geçerliliğine değil, istemci platformlara da bağlıdır.
Bir SSL sertifikası teknik olarak geçerli olabilir ama yine de üretimde başarısız olabilir. Sertifika geçerliliği sadece düzenlendiğini ve kriptografik olarak sağlam olduğunu doğrular. Tüm cihazlarda evrensel güven sağladığını garanti etmez.
CA zinciri geçişleri sırasında tam olarak bunlar yaşanıyor. Certificate Authority’ler güvenlik, uyumluluk ve uzun vadeli sürdürülebilirlik için kök ve ara sertifikaları döndürüyor.
Ancak istemci platformları, özellikle mobil işletim sistemleri, güven depolarını çok daha yavaş ve tutarsız bir şekilde güncelliyor. Sonuç olarak modern sertifika altyapısı ile eski cihaz güveni arasında bir kırılma oluşuyor.
Bu vaka çalışmasında, CA zinciri değişikliklerinin geçerli SSL sertifikalarının Android cihazlarda başarısız olmasına neden olduğu iki gerçek olayı inceliyoruz. Bu hataların üretimde nasıl ortaya çıktığını, standart tanılamaların neden hemen nedeni ortaya çıkarmadığını ve farklı çözüm yollarının her vakada mobil uyumluluğu nasıl geri getirdiğini gösteriyoruz.
Xamisoft: Sunucu Yükseltmesi Android Güvenini Nasıl Bozdu
Xamisoft masaüstü ve mobil platformlarda kullanılan dil öğrenimi uygulamaları geliştiriyor. Altyapıları Windows Server 2019 üzerinde SSL sorunları yaşamadan çalışıyordu. Masaüstü tarayıcıları ve Android cihazlar normal çalışıyor, sertifika dağıtımı standart IIS kurulumu takip ediyordu. Sorun sadece rutin bir yükseltmeden sonra ortaya çıktı.
Sorun
Ortamlarını Windows Server 2019’dan Windows Server 2025’e geçirdiler ve SSL sertifikasını daha önce çalışan aynı yöntemle yeniden yüklediler. Sunucu perspektifinden her şey doğruydu.
Sertifika yüklendi, kök ve ara sertifikalar mevcuttu ve masaüstü tarayıcıları hiçbir uyarı göstermiyordu. Hiçbir şey bozuk bir SSL yapılandırması önermiyor du.Sonra Android kullanıcıları hata bildirmeye başladı. Eski Android sürümlerinde, özellikle Android 6’da, site şu hatayı gösteriyordu: “Bu sertifika güvenilir bir otoriteden değil.”
Bazı durumlarda, benzer hatalar daha yeni Android yapılarında bile görünüyordu. Bu durum yorumlanmasını zorlaştırıyordu. İlk bakışta, yanlış yapılandırılmış bir sunucu veya eksik sertifika dosyası gibi görünüyordu.
Müşteri açısından durum hiç mantıklı değildi:
- Aynı sertifika Windows Server 2019’da hiçbir sorun yaşamıyordu.
- Şimdi Windows Server 2025’te başarısız oluyordu.
- Masaüstü tarayıcıları hala çalışıyordu.
- Sadece mobil kullanıcılar engellenmişti.
Kök Neden Analizi
Bu klasik “her şey geçerli, yine de kullanıcılar kilitli” senaryosuydu. Bu noktada iki teknik boyut ortaya çıkmaya başladı.
1. CA Zincirinin Kendisi
Windows Server 2019’da sertifika daha eski Sectigo RSA Domain Validation Secure Server CA hiyerarşisi altında düzenlenmişti. Bu zincir eski sürümler de dahil olmak üzere geniş çapta güveniliyordu.
Windows Server 2025’te aynı sertifika artık şu zincire bağlanıyordu: Sectigo Public Server Authentication CA DV R36.
Bu Sectigo’nun daha yeni güven hiyerarşisinin bir parçasıydı. Geçerli ve modern sistemler tarafından güveniliyordu, ancak bazı Android güven depoları henüz bunu içermiyordu. Bu cihazlar için sertifika zincirinin güvenilir bir çıpası yoktu.
2. Sertifika Zinciri Teslimi
Windows Server 2019 sistem deposunu kullanarak eksik ara sertifikaları tamamlıyor. IIS ara sertifikaları perde arkasında alabilir ve yönetici her bileşeni açıkça yüklememiş olsa bile istemcilere tam bir zincir sunabiliyordu. Windows Server 2025 bu davranışı değiştirdi. Tam zincirin açıkça yapılandırılmasını gerektiriyordu. Herhangi bir ara sertifika eksik veya yanlış sıralanmışsa, tarayıcılar AIA (Authority Information Access) getirme yoluyla zinciri kurtarabilse bile bazı istemciler doğrulamada başarısız oluyordu.
Bu Xamisoft’un örtüşen iki sorunla uğraştığı anlamına geliyordu:
- Bazı Android cihazları yeni Sectigo hiyerarşisine güvenmiyordu.
- Bazı istemciler sunucudan tam zinciri doğru şekilde alamıyordu.
Her iki sorun tek başına SSL’i bozabilir. Birlikte gerçek nedeni gizlerler.
Bu şunları açıklıyordu:
- Masaüstü tarayıcıları hala çalışıyordu.
- SSL test araçları çoğunlukla yeşil sonuçlar gösteriyordu.
- Android cihazlar sürüm ve üretici yapısına bağlı olarak öngörülemez şekilde başarısız oluyordu.
Tanımımız
İlk olarak Android cihazların asla sunucunun güven deposunu kullanmadığını açıkladık. Windows’a kök sertifikaları yüklemek Android için hiçbir şey yapmaz. Güven kararı tamamen cihaz üzerinde verilir.
İkinci olarak Windows Server 2025’in açık zincir tamamlılığı gerektirdiğini açıkladık. Sunucunun şunları sunması gerekiyordu:
- Sunucu sertifikası
- Doğru ara sertifikalar
- Doğru sırada
Örtülü alma işlemine güvenmek artık sürdürülebilir değildi.
Çözüm
IIS’i bunu güvenilir şekilde halletmeye zorlamaya çalışmak yerine, Xamisoft yapısal bir düzeltme uyguladı. IIS’in önüne Nginx’i proxy olarak yerleştirdiler ve Nginx’i tam sertifika zincirini açıkça sunacak şekilde yapılandırdılar.
Bu iki şey başardı:
- Tam zincir her istemciye tutarlı şekilde teslim ediliyordu.
- Hiyerarşinin eski kısımlarına hala güvenen Android cihazları doğru şekilde doğrulayabiliyordu.
Değişiklikten sonra SSL hataları ortadan kalktı ve Android 6 cihazları siteye tekrar erişebildi. Sertifikanın kendisinde herhangi bir değişiklik gerekmedi.
Bu vaka SSL hatalarının genellikle tek bir hatadan kaynaklanmadığını, CA zinciri evrimi, platform güven depoları, sunucu yazılımı davranışı ve sertifika teslim mekaniği arasındaki etkileşimlerden ortaya çıktığını vurguladı. Xamisoft’un düzeltmesi modern CA altyapısı ile eski istemci güveni arasındaki teslim yolunu tamir etti.
Coppernic: Sertifika Yeniden Düzenlemesinden Sonra Android 6 Başarısız Oldu
Coppernic kimlik, erişim kontrolü ve veri toplama sistemleri için profesyonel mobil donanım ve yazılım çözümleri tasarlayıp geliştiren Fransız bir teknoloji şirketidir.
Sorun
Sorun sadece eski Android cihazlarda rutin sertifika değişimi sırasında ortaya çıktı. Coppernic mevcut bir SSL sertifikasından yeni sipariş edilene geçiş sürecindeydi.
Kurulumun kendisi beklendiği gibi gitti. Masaüstü tarayıcıları sertifikayı uyarı vermeden kabul etti. Sunucu tarafında görünür bir yanlış yapılandırma yoktu. Yine de Android 6.0.1 terminalleri artık güvenilir bir bağlantı kuramıyordu.
Sertifika geçerli, düzgün yüklenmiş ve meşru bir Certificate Authority tarafından düzenlenmişti, yine de bu cihazlar onu reddediyordu. Önceki sertifika çalışmıştı. Altyapıda başka hiçbir şey değişmemişti.
Kök Neden Analizi
Tek fark zincirdi. Yeni sertifika Sectigo’nun güncellenmiş hiyerarşisi altında, R46 ara sertifikası kullanılarak düzenlenmişti. Bu zincir Sectigo’nun kök geçiş sürecinin bir parçasıydı. Uyumlu ve modern platformlar tarafından güveniliyordu, ancak birçok eski Android güven deposu onu doğrulamak için gereken çıpaları içermiyordu.
Coppernic durumu tam olarak tespit etti:
“Görünüşe göre yeni CA sertifikası (R46) gömülü değil.”
USERTrust sertifikasını ekleyerek uyumluluğu geri getirmeye çalıştılar, ancak bu yardımcı olmadı. Android cihazları hala zinciri reddediyordu. Sorun sunucudaki eksik dosyalar değil, cihazların kendilerinde uyumlu bir güven yolunun yokluğuydu.
Bu noktada soru kurulumdan uyumluluğa kaydı.
Tanımımız
Destek ekibimiz davranışın Sectigo’nun CA zinciri geçişi ile eşleştiğini doğruladı. 2025’in ortalarından itibaren yeni sertifikalar varsayılan olarak R46 zinciri de dahil olmak üzere güncellenmiş hiyerarşiler altında düzenleniyordu. Modern platformlar tarafından geçerli ve güvenilir olsa da bu güven yolu birçok eski Android güven deposunda mevcut değildi.
Ayrıca USERTrust gibi sertifikaları eklemenin Android cihazları etkilemeyeceğini açıkladık. Android güveni yalnızca kendi dahili deposuna karşı doğrular. Cihaz düzenleyen yolu tanımıyorsa hiçbir sunucu tarafı değişikliği hatayı geçersiz kılamaz.
Çözüm
Pratik çözüm sertifikayı çapraz imzalı CA kullanarak yeniden düzenlemekti.
Coppernic Sectigo ile iletişime geçtikten sonra sertifika, eski ve hala güvenilir bir köke giden bir yolu koruyan çapraz imzalı zincir altında yeniden düzenlendi. Altyapı değişikliği gerekmedi. Sadece güven yolu ayarlandı.
Yeniden düzenlenen sertifika dağıtıldıktan sonra:
- Android 6.0.1 cihazları normal şekilde bağlandı.
- Masaüstü platformları sertifikaya güvenmeye devam etti.
- Uyumsuzluk hemen ortadan kalktı.
Bu vaka önemli çünkü sorunu tek bir değişkene izole ediyor. Sunucu geçişi veya zincir teslimi tutarsızlığı yoktu. Her iki sertifika da geçerliydi, ancak sadece biri üretimde kullanılabilirdi.
Coppernic’in deneyimi bir Certificate Authority varsayılan düzenlemeyi ileriye taşıdığında uyumluluğun ne kadar hızlı çökebileceğini gösteriyor. Daha yeni bir güven yolu otomatik olarak daha geniş bir yol değildir. Hala eski Android filolarına bağımlı ortamlarda daha dar ve kırılgan olabilir.
Cihazlar Bir Sertifikaya Güvenip Güvenmeme Kararını Nasıl Verir
Bir cihaz bir SSL sertifikasını kontrol ettiğinde, site sertifikasından bir veya daha fazla ara sertifika yoluyla güven deposunda zaten mevcut olan bir kök sertifikaya kadar bir güven yolu oluşturur. Cihaz güvendiği sertifikaları kullanarak bu yolu tamamlayamazsa, sertifikanın kendisi geçerli olsa bile bağlantı başarısız olur.
Android tasarım gereği parçalanmıştır. Üreticiler farklı sürümler gönderir, güncelleme programları değişir ve birçok cihaz değiştirilmeden çok önce sistem güncellemelerini almayı durdurur. Bir telefon son güvenlik veya güven deposu güncellemesinden yıllar sonra aktif kalabilir. Sertifika perspektifinden o cihaz bir zaman kapsülü haline gelir.
Güven depoları işletim sistemi içinde yaşar. OS güncellenmediyse güven deposu da güncellenmez. Bu bir cihazın yıllar önce güncel olan ancak artık modern Certificate Authority’lerin zincirleri nasıl düzenlediği ile uyumlu olmayan sertifika kökleri ve güven yollarına güvenmeye devam edebileceği anlamına gelir.
Bu Sorunların Teşhisi Neden Zor
Standart SSL tanılamaları sertifikanın geçerli olduğunu, zincirin tam olduğunu ve sunucunun onu düzgün sunduğunu doğrular. Ekosistemdeki her istemci cihazın bu zincire güvenip güvenemeyeceğini doğrulamaz.
Vakalarımızda tüm geleneksel kontroller geçti. SSL test araçları yeşil sonuçlar verdi, sunucu yapılandırması doğruydu ve masaüstü tarayıcıları hatasız çalışıyordu. Altyapı açısından hiçbir şey bozuk değildi.
Hata geleneksel tanılamaların kapsamı dışında gerçekleşti. Sadece belirli cihaz sınıfları (güncellenmiş güven depoları olmayan eski Android sürümleri) etkilendi. Çoğu doğrulama iş akışı cihaz düzeyinde güven uyumluluğu testini içermediğinden, sorun gerçek kullanıcılar karşılaşana kadar görünmez kaldı. Bu bir tanılama kör nokta yaratır: bir sertifika geçerli, doğru yüklenmiş ve tamamen uyumlu olabilir, yine de şüphelenmeyen kullanıcılar için hatalar verebilir.
Sorunu Nasıl Teşhis Ettik
Sorunu model tanıma yoluyla tespit ettik.
Geçerli bir sertifika masaüstü platformlarda çalışırken belirli mobil ortamlarda başarısız olduğunda, sunucu yapılandırmasından uzaklaşıp güven deposu uyumluluğuna işaret eder. CA geçişleri ve platform düzeyinde güven davranışına önceki maruziyet olmadıkça bu açık değildir.
Yeni tanıtılan bir CA zinciri ile birlikte Android’e özel hataların ortaya çıkması araştırma kapsamını hemen daralttı. Sorun artık “SSL neden bozuk” değil, “hangi güven depoları artık bu güven yolunu kabul etmiyor” oldu.
Bu genellikle karıştırılan iki kavramı ayırmayı gerektirir:
- sertifika geçerliliği (kriptografik doğruluk)
- cihaz güveni (platform kabulü)
Bu farkı tanımak sorunu hızlı ve doğru bir şekilde teşhis etmemizi sağladı.
Sunduğumuz Çözüm Yolları
Güven uyumluluğu sorunu doğrulandıktan sonra, çözmek onarım değil strateji meselesi haline geldi. Her seçenek kısa vadeli istikrar ile güven ekosistemi ile uzun vadeli uyum arasında farklı bir denge temsil ediyordu.
- Eski zinciri kullanarak yeniden düzenleme: Bu eski Android cihazlarla uyumluluğu hemen geri getirdi. Kullanıcıya yönelik hatalarını kaldırmanın ve üretim trafiğini stabilize etmenin en hızlı yoluydu.
- Kısmi uyumluluğu kabul etme: Bazı ortamlar modern platformları önceliklendirmeyi ve eski cihazların SSL hataları ile karşılaşacağını kabul etmeyi seçiyor. Bu altyapıyı basitleştirir, ancak kitle erişimini sınırlar.
- Farklı bir Certificate Authority’ye geçmek: Başka bir CA’ya geçmek daha uzun vadeli mobil uyumluluk sağlayabilir ve geçişsel güven zincirlerine bağımlılığı azaltabilir.
Aşamalı geçiş planla: Geçici olarak eski zincir kullanılırken bile uzun vadeli planlama gereklidir. Temel güven modeli gelişmeye devam edecek ve web site yöneticileri uyumluluğu yapısal olarak ele almalıdır.
Sertifikayı Yeniden Düzenlemek Neden Kalıcı Bir Çözüm Değil
Eski veya çapraz imzalı zincirle yeniden düzenleme uyumluluk sorununu erteler; kaldırmaz. Bu zincirler geçişlere köprü olmak için var olur, modern güven yollarını değiştirmek için değil.
Certificate Authority’ler hiyerarşilerini modernize etmeye devam ettikçe, eski ara sertifikalar ve uyumluluk yolları emekli edilecektir. Bu gerçekleştiğinde, sistemler onlara bağımlı kalmaya devam ederse aynı hata kalıpları geri dönecektir.
Bu nedenle yeniden düzenleme bir stabilizatördür, çözüm değil. Zaman kazandırır. Uzun vadeli istikrar güven ekosistemlerinin nasıl evrildiği ile uyum gerektirir, onlara direnç değil.
Her iki vaka çalışmasının ardındaki yapısal ders budur.
Son Düşünceler: “Geçerli” Sertifikalar 2026’da Neden Hala Başarısız Oluyor
Bu vaka SSL/TLS’in 2026’da pratikte nasıl çalıştığını gösteriyor. Certificate Authority’ler hızlı hareket ediyor. Zincirleri döndürüyor, güven yollarını modernize ediyor ve yeni güvenlik gereksinimlerine yanıt veriyor. Cihazlar öyle değil. Akıllı telefonlarda birçok kullanıcı mevcut CA altyapısının yıllar gerisindeki güven modellerine saplanmış durumda.
Bu nedenle “geçerli” artık otomatik olarak “kullanılabilir” anlamına gelmiyor.
Kuruluşlar SSL’i tek seferlik kurulum olarak görmemeli. Şunlar arasında bir uyumluluk katmanı olarak yönetilmeli:
- Certificate Authority’ler
- İşletim sistemleri
- Cihaz yaşam döngüleri
- Kullanıcı ortamları
Bu şu demek:
- Sadece test ettiğiniz tarayıcıları değil, kullanıcılarınızın gerçekte çalıştırdığı cihazları bilmek.
- Sertifikaları eski Android sürümleri de dahil olmak üzere gerçek mobil platformlara karşı test etmek.
- CA duyurularını ve zincir geçişlerini arka plan gürültüsü değil operasyonel riskler olarak takip etmek.
- Mümkün olduğunda tek güven yoluna veya tek CA’ya bağımlılıktan kaçınmak.
Esneklik bir güvenlik özelliği haline geliyor. Ve destek, sadece yardım masası işlevi değil, istikrar katmanı haline geliyor.
SSL Dragon‘da destek ekibimiz ekosistem değişikliklerini eyleme dönüştürülebilir kararlara çeviriyor:
- güven uyumluluğu sorunlarını tanımak
- platform davranışını sunucu hatalarından ayırmak
- azaltma stratejileri seçmek
- mobil kullanıcı erişimini korumak
Standartlar ile üretim gerçekliği arasındaki boşluğu dolduruyoruz. Mobilde beklenmedik SSL sorunları yaşıyorsanız veya sertifikanızın canlı olarak nasıl davrandığını doğrulamak istiyorsanız, kullanıcılarınızın cihazlarının tam olarak ne gördüğünü görmek için domain’inizi SSL Checker‘ımızdan geçirin.
Bugün SSL Dragon’dan sipariş vererek SSL Sertifikalarında %10 indirimden yararlanın!
Hızlı düzenleme, güçlü şifreleme, %99,99 tarayıcı güvenilirliği, özel destek ve 25 günlük para iade garantisi. Kupon kodu: SAVE10
