SSL Kurulu Ama Site Güvenli Değil Diyor: Mixed Content Çözümü

SSL kurulu olduğu hâlde tarayıcı "Güvenli değil" diyorsa önce sertifikanın kendisini eleyin: sayfa gerçekten https ile mi açılıyor, sertifikanın süresi ve adı doğru mu? Sertifika sağlamsa neden büyük olasılıkla karışık içeriktir (mixed content), yani https sayfanın görsel, betik, stil dosyası ya da form hedefi gibi bir parçasını hâlâ http ile çağırması. Güncel Chrome ve Firefox sürümleri görsel, ses ve videoyu https'e yükseltmeyi dener, betik ve stil dosyalarını ise engeller. Kalıcı çözüm, tarayıcı konsolunda bu adresleri bulup kaynağında https'e çevirmektir. WordPress'te bu iş veritabanı yedeğinden sonra WP-CLI search-replace ile, önce --dry-run denemesiyle yapılır.

Önce sertifikayı eleyin

Adres çubuğundaki simgeye tıklayın. Chrome'un açılan penceresi iki farklı durumu ayırır ve bu ayrım bütün teşhisin yönünü belirler. "Bağlantı güvenli değil" yazıyor ve adres http:// ile başlıyorsa sertifikanız çalışıyor olabilir ama sayfa ona hiç uğramadan açılmıştır. Eksik olan http'den https'e yönlendirmedir. Kurulum ve yönlendirme adımları cPanel'de SSL kurulumu ve HTTPS yönlendirmesi rehberinde.

Tam sayfa bir uyarı ve NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_COMMON_NAME_INVALID ya da NET::ERR_CERT_AUTHORITY_INVALID gibi bir kod görüyorsanız sorun sertifikadadır: süresi dolmuş, başka bir ad için düzenlenmiş ya da tarayıcının güvenmediği bir zincirle sunuluyordur. Bu durumda karışık içerik aramak boşa zaman kaybıdır. AutoSSL'in sertifika alamadığı ya da yenileyemediği durumlar için sıralı bir teşhis akışı var. Site Cloudflare arkasındaysa ve ekranda 525 ya da 526 görünüyorsa sorun ziyaretçi tarafında değil, Cloudflare ile kaynak sunucu arasındaki SSL ayarındadır.

Sayfa https ile açılıyor, sertifika geçerli görünüyor, ama kilit eksik ya da sayfanın bir kısmı bozuk geliyorsa doğru yerdesiniz.

Karışık içerik nedir, tarayıcı bugün ne yapıyor?

MDN'nin tanımıyla karışık içerik, güvenli yüklenmiş bir sayfanın HTTP ya da başka bir güvensiz protokolle kaynak çekmesidir. Eski belgelerde iki sınıf vardı. Sayfanın geri kalanını değiştirebilen betik ve stil dosyaları etkin (active) içerikti ve engelleniyordu. Görsel, ses ve video ise edilgen (passive) içerikti ve tarayıcılar bunları uyarıyla gösterebiliyordu. Güncel tanım bu ayrımı "yükseltilebilir" (upgradable) ve "engellenebilir" (blockable) olarak yeniden kuruyor.

Davranış da değişti. Chromium belgesine göre Chrome 80. sürümden itibaren karışık içerikteki ses ve videoyu https'e yükseltmeyi deniyor, https'te yüklenemeyeni hiç yüklemiyor. Görseller için aynı adım ilk planlanan 81. sürümden sonraya ertelendi ve bugünkü Chromium belgesi görselleri de yükseltilen türler arasında sayıyor. Firefox ise 127. sürümle (Haziran 2024) aynı yola girdi: Mozilla'nın açıklamasına göre bu sürümden sonra karışık içeriğin tamamı ya yükseltiliyor ya engelleniyor.

Pratik sonucu şu: güncel bir tarayıcıda karışık içerik çoğu zaman kilit simgesini kaldırmaz, sitenin bir parçasını sessizce bozar. Görsel kaybolur, kaydırıcı çalışmaz, yazı tipi değişir. "Güvenli değil" uyarısını hâlâ görüyorsanız ya ziyaretçinin tarayıcısı eskidir, ya kullanıcı o site için güvensiz içeriğe izin vermiştir, ya da sayfada http'ye gönderilen bir form vardır. Chromium blogundaki duyuruya göre bu form uyarıları Chrome 86 için planlanmış, sonra Chrome 87'ye ertelenmişti.

Karışık içeriği bulmak

Tarayıcı konsolu

En hızlı yol sorunlu sayfayı açıp geliştirici araçlarını (F12) açmaktır. Console sekmesinde "Mixed Content" ile başlayan satırlar, hangi adresin yükseltildiğini ya da engellendiğini tek tek yazar. Ana sayfa temiz diye site temizdir sanmayın. Yazı, ürün, kategori, iletişim ve ödeme sayfaları farklı şablonlar kullanır, her birini ayrıca açın.

Privacy and security paneli

Chrome geliştirici araçlarında eski adıyla Security, güncel adıyla Privacy and security paneli sayfanın güvenlik özetini verir. Panelde Non-secure origins altında güvensiz kökenler listelenir, View requests in Network panel bağlantısı da o isteklere doğrudan götürür. Panel sekmelerde görünmüyorsa Ctrl+Shift+P (macOS'ta Command+Shift+P) ile komut menüsünü açıp "privacy" yazmanız yeterli.

Kaynak kodda ve sunucuda arama

Konsol yalnız açtığınız sayfayı gösterir. Daha geniş bir tarama için sayfanın HTML'inde http ile başlayan adresleri listeleyin:

curl -s https://ornek.com.tr/ | grep -oE 'http://[^"]+' | sort -u

Çıktıda göreceğiniz her şey sorun değildir. Başka sitelere giden düz bağlantılar (<a href="http://...">) karışık içerik sayılmaz, çünkü sayfa yüklenirken çağrılmazlar. Bakmanız gerekenler src, stil dosyası ve form adresleridir. Sabit adresin temada ya da bir eklentide mi durduğunu görmek için sunucuda dosyaları da tarayabilirsiniz. WordPress kök dizininde şu komut, ilgili dosyaların adını listeler:

grep -rIl 'http://ornek.com.tr' wp-content/themes wp-content/plugins

Veritabanında arama için WP-CLI'nin salt okunur wp db search komutu işinizi görür. Hangi tabloda, hangi sütunda kaç eşleşme olduğunu gösterir ve hiçbir şeyi değiştirmez:

wp db search 'http://ornek.com.tr'

WordPress'te düzeltme sırası

Site adresi ayarları

Ayarlar > Genel ekranındaki WordPress Adresi (URL) ve Site Adresi (URL) alanları https:// ile başlamalıdır. Bu alanlar griyse adresler wp-config.php içinde WP_HOME ve WP_SITEURL sabitleriyle tanımlanmıştır. Değişikliği orada yapın. WordPress'in taşıma belgesi bu sabitlerin protokolü içermesini ve sonda eğik çizgi taşımamasını istiyor.

Veritabanındaki eski adresler: önce yedek, sonra deneme

Yazı içeriklerinde, widget'larda ve eklenti ayarlarında kalan http:// adresleri ayarlar ekranından değişmez. Bunlar için WP-CLI'nin search-replace komutu en güvenli araçtır. WordPress belgesine göre komut PHP'nin serileştirilmiş (serialized) verisini bozmadan değiştirir. Elle SQL ile REPLACE çalıştırmak ise serileştirilmiş dizilerin uzunluk bilgisini bozar ve eklenti ayarlarını kullanılamaz hâle getirebilir.

Bu adımdan önce mutlaka veritabanı yedeği alın. Komut yüzlerce satırı tek seferde değiştirir ve geri almanın tek temiz yolu bu yedektir:

wp db export yedek-https-oncesi.sql
wp search-replace 'http://ornek.com.tr' 'https://ornek.com.tr' \
  --skip-columns=guid --dry-run

--dry-run işlemi baştan sona çalıştırır, hangi tabloda kaç değişiklik olacağını raporlar ama veritabanına hiçbir şey yazmaz. Rapordaki sayılar beklentinizle uyumluysa aynı komutu --dry-run olmadan çalıştırın. --skip-columns=guid bilinçli bir tercih: WordPress'in taşıma belgesi yazıların GUID sütununa hiçbir koşulda dokunulmamasını açıkça söylüyor, çünkü akış okuyucuları içeriği bu kimlikle tanır.

İki varyantı unutmayın. Site eskiden www ile çalıştıysa http://www.ornek.com.tr için ayrı bir deneme yapın. Bazı sayfa oluşturucular veriyi JSON olarak, eğik çizgileri kaçışlı biçimde (http:\/\/ornek.com.tr) saklar. Düz arama bunları bulmaz, aynı adımı bu yazımla da deneyin. Çoklu site (multisite) kurulumlarında ağın bütün tablolarını kapsamak için --network seçeneği gerekir. --all-tables ise WordPress önekine bakmadan veritabanındaki her tabloya dokunur, ancak ne yaptığınızdan eminseniz kullanın.

Tema ve eklentilerdeki sabit adresler

Dosya taramasında çıkan sonuçlar genellikle bir tema şablonuna elle yazılmış logo yolu, alt temadaki bir CSS dosyası ya da eski bir eklentinin yüklediği betiktir. Alt temadaki adresi düzeltin, ana temaya ya da eklentiye doğrudan müdahale etmeyin, ilk güncellemede değişikliğiniz silinir. Sorun bir eklentinin kendi kodundaysa güncel sürümünü kurun, güncellenmiyorsa yerine başka bir eklenti düşünün.

Sayfa oluşturucu CSS'i ve önbellekler

Elementor gibi sayfa oluşturucular ürettikleri CSS'i dosya olarak saklar. Veritabanını düzelttiğiniz hâlde konsolda eski adresler görünmeye devam ediyorsa bu dosyaları yeniden ürettirmeniz gerekir. Elementor'da Tools ekranında hem adres değiştirme (Replace URL) hem de CSS dosyalarını yeniden üretme seçeneği bulunur, düğmenin adı sürüme göre değişebiliyor. Son adım önbelleklerdir: eklenti önbelleği, sunucu önbelleği ve varsa CDN. Temizledikten sonra sayfa önbelleğinin yeni sürümü sunduğunu HIT ve MISS başlıklarıyla kontrol edin, aksi hâlde düzelttiğiniz sayfanın eski kopyasına bakıyor olabilirsiniz.

HTTPS desteklemeyen dış kaynaklar

Eski bir sayaç kodu, başka bir sitedeki görsel ya da artık güncellenmeyen bir harita betiği https ile hiç sunulmuyor olabilir. Adresi https'e çevirip tarayıcıda açmayı deneyin. Açılmıyorsa üç seçeneğiniz var: kaynağın https sunan bir sürümünü bulmak, dosyayı kendi sunucunuza alıp oradan sunmak (lisansı izin veriyorsa) ya da kaldırmak. Bizce o kaynağa gerçekten ihtiyaç olup olmadığını sormak çoğu zaman en kısa yoldur.

Geçici önlemler: upgrade-insecure-requests ve Cloudflare

Binlerce eski yazısı olan bir sitede kaynakları tek tek düzeltmek zaman alır. Bu arada sayfaların bozuk görünmesini istemiyorsanız sunucuya bir CSP (Content Security Policy) yönergesi ekleyebilirsiniz. upgrade-insecure-requests, MDN'deki açıklamasıyla tarayıcıya sitenin bütün http adreslerini https'e çevrilmiş gibi ele almasını söyler. Apache ya da LiteSpeed'de .htaccess dosyasına, nginx'te sunucu bloğuna eklenir:

# Apache / LiteSpeed (.htaccess, mod_headers gerekir)
Header always set Content-Security-Policy "upgrade-insecure-requests"

# nginx
add_header Content-Security-Policy "upgrade-insecure-requests" always;

Sitede zaten bir CSP başlığı varsa ikinci bir başlık eklemek yerine yönergeyi mevcut başlığa ekleyin. Sınırlarını da bilin: https'te bulunmayan bir kaynak bu yönergeyle http'ye geri düşmez, doğrudan yüklenmez. Üstelik ana sorun yerinde durur, yönergeyi kaldırdığınız gün her şey geri gelir. Bunu bir bant olarak düşünün.

Site Cloudflare arkasındaysa Edge Certificates sayfasındaki Automatic HTTPS Rewrites seçeneği de benzer bir iş yapar. Cloudflare belgesine göre özellik yalnız https ile erişilebildiğini doğruladığı adresleri yeniden yazar. Belgede görseller gibi edilgen içeriğin bazı durumlarda yeniden yazılmadığı, JavaScript ya da CSS'in sonradan yüklediği kaynaklarda uyarıların sürebileceği de belirtiliyor. Yardımcı bir katmandır, temizliğin yerini tutmaz.

HSTS'ye acele etmeyin

Karışık içerik temizlenince akla gelen sıradaki adım çoğunlukla HSTS (Strict-Transport-Security) başlığıdır. Bu başlık tarayıcıya, belirlenen süre boyunca siteye yalnız https ile bağlanmasını söyler. Doğru kullanıldığında yararlıdır, ama geri alınması zahmetlidir. Tarayıcı süreyi bir kez öğrendiyse siz başlığı kaldırsanız bile süre dolana kadar http'yi denemez.

Preload listesi ise bambaşka bir taahhüttür. hstspreload.org listeye girmek için en az bir yıllık max-age, includeSubDomains ve preload yönergelerini şart koşuyor ve listeden çıkışın Chrome güncellemesiyle kullanıcılara ulaşmasının aylar sürdüğünü yazıyor. includeSubDomains, https sunmayan bir alt alan adınız varsa (eski bir panel adresi, test ortamı ya da yalnız http çalışan bir cihaz arayüzü) o adı da erişilemez hâle getirir. Aynı sayfa kademeli bir geçiş öneriyor: önce 5 dakika, sonra bir hafta, sonra bir ay. Her aşamada bozulan sayfa olup olmadığını izleyip mevcut sürenin tamamını bekledikten sonra bir sonrakine geçmek gerekiyor.

Bir şey ters giderse geri alma

Değiştirme sonrası site açılmıyor ya da bir eklentinin ayarları kaybolduysa önce aldığınız yedeği geri yükleyin:

wp db import yedek-https-oncesi.sql

Ardından önbellekleri yeniden temizleyin. CSP yönergesi eklediyseniz ve beklenmeyen bir şey kırıldıysa satırı kaldırmak yeterlidir. HSTS başlığını ise test süresinden uzun bir değerle yayımladıysanız geri dönüşün ziyaretçi tarayıcılarında o süre kadar gecikeceğini hesaba katın. Daha temiz bir yol, değişikliği önce bir hazırlık kopyasında denemektir. Siteyi başka bir sunucuya ya da alan adına aktarırken aynı arama değiştirme işi tekrar gerekir, o senaryonun ayrıntıları WordPress sitesini başka hostinge taşıma rehberinde.

Temizliğin tamamlandığını gösteren işaretler

• Farklı şablon kullanan sayfaların (ana sayfa, yazı, ürün, sepet, ödeme, iletişim) hiçbirinde konsolda "Mixed Content" satırı kalmadı.
• Privacy and security panelindeki özet sayfanın güvenli olduğunu söylüyor ve Non-secure origins listesi boş.
• wp db search 'http://ornek.com.tr' artık yalnız GUID sütununda eşleşme gösteriyor.
• HTML taramasında yalnız başka sitelere giden düz bağlantılar kaldı.
• Formların action adresi https ile başlıyor.
• Önbellekler temizlendikten sonra mobil cihazda da kilit simgesi görünüyor.

Sitenizdeki sertifika türünü yeniden değerlendirmek isterseniz DV, OV ve EV sertifikalar arasındaki farka bakabilir, ücretli seçenekleri SSL sertifikası sayfamızda inceleyebilirsiniz. Sorun sürüyorsa Netx müşteri panelinden destek talebi açın ve talebe sorunlu sayfanın adresini, konsoldaki "Mixed Content" satırlarının metnini ve hangi adımları uyguladığınızı ekleyin.

Sık sorulan sorular

Eski yazılarda başka sitelere giden http bağlantıları sorun yaratır mı?

Karışık içerik uyarısı yaratmaz. Ziyaretçi bağlantıya tıkladığında başka bir sayfaya gider, sizin sayfanız yüklenirken o adres çağrılmaz. Hedef site https destekliyorsa bağlantıyı güncellemek yine de iyi bir alışkanlıktır.

Adresleri https yerine protokolsüz (//ornek.com.tr/...) yazmak daha mı güvenli?

Gerek yok. MDN'nin önerisi kendi alan adınızdaki kaynaklar için göreli yollar ya da açıkça https adresleri kullanmaktır. Protokolsüz yazım http sayfada http'ye düşer, site tamamen https'e geçtiyse açıkça https:// yazmak hem okunur hem tutarlıdır.