Ana içeriğe geç

Web Sitenizde SSL Uyarıları Nasıl Önlenir

· 5 dakikalık okuma
Customer Care Engineer

25 Temmuz 2026 tarihinde yayımlandı

Web Sitenizde SSL Uyarıları Nasıl Önlenir

SSL uyarıları genellikle gizemli bir tarayıcı sorunu değil, sertifika, DNS veya dağıtım uyumsuzluğudur. SSL uyarılarının nasıl önleneceğini öğrenmek için HTTPS'yi operasyonel bir hizmet olarak ele alarak başlayın: sertifika adını, yenileme durumunu, tam zinciri ve istekleri gerçekten yanıtlayan sunucuyu doğrulayın. Gözden kaçan tek bir ayar, bir müşteri ile işletmeniz arasına büyük kırmızı bir uyarı sayfası koyabilir.

Bir tarayıcı, ulaştığı web sitesinin sertifikanın düzenlendiği web sitesi olduğunu kanıtlayamadığı için uyarı gösterir. Ziyaretçilerin teknik nedeni bilmesine gerek yoktur. Bir güvenlik uyarısı görürler, tereddüt ederler ve çoğu zaman ayrılırlar. Bir çevrimiçi mağaza, SaaS girişi, ajans müşteri sitesi veya şirket portalı için bu, destek talebine dönüşmeden önce bir güven sorunudur.

Sertifikayı değiştirmeden önce nedeni bulun

Teslim yolunu kontrol etmeden bir sertifikayı değiştirmek yaygın bir zaman kaybıdır. Yeni sertifika geçerli olabilir, ancak tarayıcı yine de bir yük dengeleyici, CDN, reverse proxy veya güncel olmayan bir DNS kaydının arkasındaki başka bir sunucudan eski bir sertifika alabilir.

Önce uyarı metnini kontrol edin. Tarayıcılar genellikle yararlı bir ipucu sağlar: süresi dolmuş sertifika, ad uyumsuzluğu, güvenilmeyen düzenleyici veya geçersiz tarih. Ardından hangi ana makine adının başarısız olduğunu doğrulayın. `example.com`, `www.example.com`, `app.example.com` ve `api.example.com`, sertifika bunların hepsini içermedikçe ayrı adlardır.

Sertifikanın tam ana makine adını kapsadığını doğrulayın

Bir sertifika, Subject Alternative Name listesinde ziyaretçinin girdiği ana makine adını içermelidir. `www.example.com` için olan bir sertifika, `example.com` öğesini otomatik olarak korumaz. Wildcard sertifikalar `shop.example.com` gibi birinci seviye alt alan adlarını korur, ancak kök alan adını ve `eu.shop.example.com` gibi daha derin adları korumaz.

Bu, yayına alma günündeki birçok sorunu ortaya çıkarır. Bir ekip `www` öğesini test eder, daha sonra bir yönlendirme ekler ve ardından kök alan adına doğrudan gelen trafiğin bir uyarı ürettiğini fark eder. Her genel ana makine adını sertifika planına dahil edin veya yalnızca kök alan adı için geçerli bir sertifika hazır olduktan sonra yönlendirme yapın.

Bir CDN veya bulut proxy kullanıyorsanız, onun SSL modunu da kontrol edin. Ziyaretçilere sunulan edge sertifikası ile proxy ve sunucunuz arasında kullanılan origin sertifikası ilişkilidir ancak ayrıdır. Geçerli bir origin sertifikası geçersiz bir edge sertifikasını düzeltmez, bunun tersi de geçerlidir.

Süre sonunu ve otomatik yenilemeyi kontrol edin

Sertifika süresinin dolması, önlenmesi en kolay SSL uyarısıdır. Genel sertifikaların geçerlilik süreleri nispeten kısadır, bu nedenle manuel yenileme gereksiz, tekrarlayan bir risk oluşturur. Mümkün olan her yerde yenilemeyi otomatikleştirin ve bu otomasyonun gerekli alan adı doğrulamasını tamamlayabildiğini doğrulayın.

HTTP tabanlı doğrulama için yenileme süreci, 80 numaralı port üzerinden doğru web sunucusuna ulaşmalıdır. DNS tabanlı doğrulama için gerekli DNS kaydı yetkili bölgede oluşturulmalıdır. DNS bir sağlayıcı tarafından, web sunucusu başka biri tarafından yönetildiğinde ve önünde bir CDN bulunduğunda bu durum daha ilginç hale gelir. En güzel DNS durumu değil, ancak sahiplik net olduğunda kontrol altındadır.

Yalnızca bir yenileme başarı mesajına güvenmeyin. Yenilemeden sonra yeni sertifikanın yüklendiğini ve herkese açık olarak sunulduğunu doğrulayın. Yenileme diskte başarılı olabilirken Nginx, Apache, bir kontrol paneli veya bir yük dengeleyici, yapılandırması yeniden yüklenene kadar eski sertifikayı sunmaya devam edebilir.

Altyapınız genelinde SSL uyarıları nasıl önlenir

Kalıcı çözüm, tam HTTPS yolu etrafında kontroller oluşturmaktır. Alan adı kaydınız, proxy'niz, yük dengeleyiciniz, uygulama sunucunuz, sertifika dosyalarınız ve yönlendirmeleriniz birbiriyle uyumlu olmalıdır. Bir sertifika, bir kez yükleyip sonra unuttuğunuz bir dosya değildir.

Geçişler sırasında DNS'yi doğru tutun

SSL uyarıları genellikle bir site taşındıktan sonra ortaya çıkar. Eski A veya AAAA kayıtları hâlâ önceki bir ana bilgisayara işaret ediyor olabilirken yeni sunucu doğru sertifikaya sahip olabilir. Bazı ziyaretçiler yeni ortama ulaşır, diğerleri eski olana gider ve raporlar rastgele görünür. Rastgele değiller; DNS şimdi aynı hikâyeyi anlatıyor.

Geçişten önce IPv6 kayıtları da dahil olmak üzere tüm genel kayıtların envanterini çıkarın. Gözden kaçan bir AAAA kaydı, IPv6 destekli ziyaretçileri artık yönetmediğiniz bir sunucuya gönderebilir. Ayrıca `www`, uygulama alt alan adları, posta ile ilgili web arayüzleri ve yanlışlıkla herkese açık hale gelmiş olabilecek hazırlık adları için CNAME kayıtlarını da inceleyin.

DNS yayılımı tamamlanana ve eski uç nokta ya doğru sertifikayı sunana ya da artık genel trafik almayana kadar önceki sunucuyu erişilebilir tutun. Planlı bir geçişten önce DNS TTL değerini düşürmek yardımcı olabilir, ancak bu her ağdaki önbelleği anında silmez.

Tam sertifika zincirini yükleyin

Bir sertifika zinciri, sunucu sertifikanızın güvenilir bir sertifika yetkilisi tarafından düzenlendiğini kanıtlar. Sunucu gerekli ara sertifikaları sağlamazsa, site kendi bilgisayarınızda çalışsa bile bazı tarayıcılar ve işletim sistemleri bir uyarı gösterebilir.

Sertifika yetkiliniz veya barındırma paneliniz tarafından belirtilen full-chain sertifika dosyasını kullanın. Modern bir masaüstü bilgisayardan yapılan tek bir başarılı testin evrensel uyumluluğu kanıtladığını varsaymayın. Eski cihazlar, kurumsal ağlar, mobil uygulamalar ve gömülü istemciler farklı davranabilir.

Nginx, Apache ve managed panels için, sertifika dosyalarını tahmin yürüterek birleştirmek yerine o platformun beklediği yapılandırmayı izleyin. Özel anahtar izinleri kısıtlı kalmalı ve özel anahtar yüklü sertifikayla eşleşmelidir. Bir uyumsuzluk genellikle hizmetin düzgün başlamasını engeller; bu en azından dürüsttür ama pek de rahatlatıcı değildir.

Yönlendirmeleri ve kanonik adları bilinçli hale getirin

Her genel HTTP isteği, web sunucusu ana makine adını geçerli bir sertifikayla yanıtlayabildikten sonra HTTPS'ye yönlendirilmelidir. Tercih edilen bir ana makine adı seçin; bu genellikle ya kök alan adı ya da `www` olur ve diğer sürümü tutarlı şekilde yönlendirin.

Bir CDN ile origin sunucusu arasında yönlendirme döngülerinden kaçının. Bunlar, proxy origin'e isteğin HTTP olduğunu söylerken ziyaretçi zaten HTTPS kullanıyorsa veya uygulama düzeyindeki yönlendirmeler web sunucusu kurallarıyla çakışıyorsa meydana gelir. Mümkünse yönlendirme mantığını tek bir yerde gözden geçirin, ardından kök alan adını, `www`, temel alt alan adlarını ve yaygın yolları test edin.

Ayrıca sertifika uyarılarını mixed-content uyarılarından ayırın. Mixed content, bir HTTPS sayfası script'leri, görselleri, yazı tiplerini, frame'leri veya API çağrılarını HTTP üzerinden yüklediğinde ortaya çıkar. Sertifika geçerli olabilir, ancak tarayıcı yine de sayfayı daha az güvenli olarak işaretler veya önemli kaynakları engeller. Uygulama URL'lerini, ortam değişkenlerini, CMS ayarlarını ve sabit kodlanmış varlık başvurularını HTTPS olarak güncelleyin.

Yalnızca sunucudan değil, dışarıdan test edin

Yerel bir yapılandırma kontrolü faydalıdır, ancak müşterilerin genel DNS, CDN önbellekleri ve ağ yolları üzerinden ne aldığını gösteremez. Her sertifika değişikliğinden, sunucu geçişinden, proxy ayarlamasından ve büyük uygulama sürümünden sonra harici test yapın.

Sertifika düzenleyicisini, son kullanma tarihini, ana makine adı kapsamını ve zinciri birden fazla tarayıcı veya SSL inceleme aracıyla kontrol edin. Müşteriler telefonları yaygın olarak kullanıyorsa mobil erişimi de test edin. API hizmetleri için, uygunsa özel portlar da dahil olmak üzere gerçek istemci bağlantı yolunu test edin.

İzleme, süre dolmadan önce uyarı vermeli; gerçekleştiği gün değil. Pratik bir takvim; sertifika süresinin dolmasından 30, 14 ve 7 gün önce uyarıları ve ayrıca herkese açık sertifika parmak izi beklenmedik şekilde değiştiğinde bir uyarıyı içerir. İkinci kontrol, kazara geri alma, bayat bir düğüm veya bir proxy yapılandırma değişikliğini ortaya çıkarabilir.

kodu.cloud'da bu tür harici hizmet doğrulaması, sunucu izleme ve yönetilen operasyonel destekle doğal olarak uyum sağlar. Yalnızca CPU'yu izlemek, müşterilerin bir sertifika uyarısı gördüğünü size söylemez. HTTPS kullanılabilirliğinin kendi kontrolüne ihtiyacı vardır.

Küçük bir SSL önleme rutini oluşturun

Çoğu işletme için kısa ve tekrarlanabilir bir rutin, kimsenin açmadığı karmaşık bir politika belgesinden daha güvenilirdir. Şu kontrolleri yürürlükte tutun:

  • Sertifika yenilemeyi otomatikleştirin ve doğrulama yöntemini, hesap erişimini ve DNS sahipliğini belgeleyin.
  • Sertifika süresinin dolmasını, HTTPS kullanılabilirliğini ve genel internetten sunulan sertifikayı izleyin.
  • Geçişlerden, CDN değişikliklerinden veya yük dengeleyici güncellemelerinden önce ve sonra DNS kayıtlarını ve TLS uç noktalarını gözden geçirin.
  • Yeni alt alan adlarının ya bir sertifika kapsamında olması ya da özel tutulması için bir ana makine adı envanteri tutun.
  • Uygulama sürümlerinden sonra, özellikle CMS, e-ticaret veya frontend değişikliklerinden sonra yönlendirmeleri ve mixed content durumunu test edin.

Ajanslar ve SaaS ekipleri için istemciye veya hizmet devrine ilişkin kontrol listesine sertifika sahipliğini ekleyin. Alan adı kayıt operatörü girişi, DNS sağlayıcısı, sertifika otomasyon hesabı ve sunucu erişimi yalnızca eski bir yüklenicinin parola yöneticisinde bulunmamalıdır. Bu düzen, cuma akşamı bir yenileme başarısız olana kadar kusursuz çalışır.

Bir uyarı zaten yayındaysa ne yapılmalı

Öncelikle aynı anda birkaç değişiklik yapmaktan kaçının. Etkilenen ana makine adını belirleyin ve tam tarayıcı mesajını kaydedin. Genel DNS'yi kontrol edin, sunulan sertifikayı inceleyin ve son kullanma tarihini ve adlarını hedeflenen yapılandırmayla karşılaştırın.

Sertifikanın süresi dolmuşsa onu yenileyin veya değiştirin, tam zinciri yükleyin, ilgili hizmeti yeniden yükleyin ve harici olarak doğrulayın. Ad yanlışsa, ana makine adını kapsayan bir sertifika düzenleyin veya DNS ve yönlendirme tasarımını düzeltin. Yalnızca bazı ziyaretçiler etkileniyorsa birden fazla IP adresi, bayat IPv6 kayıtları, CDN düğümleri veya farklı sertifika sürümleri sunan yük dengeli sunucular arayın.

Düzeltildikten sonra izlemeyi yerinde bırakın ve olaya neyin neden olduğunu kaydedin. Yararlı sonuç yalnızca uyarının kaybolması değildir. Asıl yararlı sonuç, aynı arızanın bir dahaki sefere saklanabileceği daha az yer olmasıdır.

Geçerli bir sertifika sessiz bir altyapıdır. Müşterilerin bunu asla düşünmek zorunda kalmaması gerekir ve sizin de bu yüzden uykunuz kaçmamalıdır. Yenilemeyi otomatik tutun, genel yolu test edin ve hizmetiniz sakin kalırken ayrıntıları birinin izlemesine izin verin.

Andres Saar Müşteri Hizmetleri Mühendisi