SSL Sertifika Hataları Rehberi: Mixed Content, Not Secure ve Tarayıcı Uyarılarını Hosting Tarafında Çözmek

SSL sertifikanız yüklü, tarayıcıda kilit simgesini görmeyi bekliyorsunuz ama karşınızda “Not Secure” yazısı, kırmızı uyarılar veya konsolda dolup taşan “Mixed Content” hataları var. Özellikle e-ticaret ya da kurumsal bir projeyi yayına alırken bu uyarılar, kullanıcı güvenini ve dönüşüm oranlarını doğrudan vuruyor. İşin daha can sıkıcı tarafı ise, sorun çoğu zaman yalnızca kod tarafında değil; hosting ve sunucu yapılandırmasında yapılan küçük hatalardan kaynaklanıyor.

Bu rehberde, DCHost ekibinde karşılaştığımız gerçek senaryolardan süzülmüş bir perspektifle; “Mixed Content” nedir, neden “Not Secure” uyarısı alırsınız, tarayıcı sertifika hatalarını nasıl yorumlarsınız ve tüm bunları özellikle hosting tarafında nasıl çözüme kavuşturursunuz sorularını adım adım ele alacağız. Apache/Nginx yapılandırmalarından HSTS başlıklarına, cPanel/Plesk panellerinden WordPress ayarlarına kadar pek çok noktaya teknik ama yalın bir dille değineceğiz. Amacımız, yalnızca hataları geçici olarak susturmak değil, altyapınızı kalıcı olarak güvenli, tutarlı ve bakımı kolay hale getirmeniz için net bir yol haritası sunmak.

SSL sertifika hataları neden bu kadar görünür oldu?

Tarayıcılar son yıllarda kullanıcı güvenliğini önceleyen çok daha agresif bir politika izliyor. Eskiden sadece geçersiz sertifikalarda gördüğümüz uyarılar bugün:

• Hiç SSL olmayan sitelerde “Not Secure” ibaresi,
• Yanlış yapılandırılmış HTTPS’te kırmızı kilit veya uyarı sayfaları,
• HTTP üzerinden çağrılan görsel, JS ve CSS dosyalarında “Mixed Content” uyarıları
• Eski protokol ve şifrelemelerde “Connection is not fully secure” benzeri mesajlar

şeklinde karşımıza çıkıyor.

Özellikle ödeme alan, kullanıcı verisi işleyen veya giriş formu barındıran sitelerde bu uyarılar, hem hukuki uyumluluk hem de SEO açısından ciddi risk. Daha önce yayınladığımız “SSL Sertifikası Nedir?” rehberinde temelleri anlatmıştık; bu yazıda o temellerin üzerine, günlük operasyonlarda karşınıza çıkan somut hataları ve çözüm adımlarını yerleştireceğiz.

Tarayıcı uyarılarını doğru okumak: “Not Secure” ne demek, ne demek değil?

Önce tarayıcının verdiği mesajları doğru anlamak gerekiyor. Çünkü her “Not Secure” aynı kökten kaynaklanmıyor ve çözüm de ona göre değişiyor.

En sık görülen uyarı tipleri

• Adres çubuğunda “Not Secure” (HTTP): Site tamamen HTTP üzerinden yayın yapıyor veya HTTPS zorunlu değil. Çözüm: SSL kurulumu ve HTTPS’e zorunlu yönlendirme.
• “Your connection is not private” / sertifika uyarı sayfası: Genellikle sertifika süresi dolmuş, alan adı eşleşmiyor ya da sertifika zinciri eksik.
• Gri/kırmızı kilit ve “This page is not fully secure” mesajı: Sitenin ana isteği HTTPS, fakat içeride HTTP üzerinden yüklenen görsel, JS, CSS veya iframe gibi kaynaklar var; klasik Mixed Content vakası.
• Protokol/şifreleme uyarıları: Eski TLS sürümleri (TLS 1.0/1.1) veya zayıf şifre takımları kullanıldığında ortaya çıkabiliyor.

Bu uyarıların her biri, barındırma altyapısında farklı bir ayara işaret ediyor. Örneğin sertifika süresi ile ilgili bir hata, çoğu zaman otomatik yenileme (ACME) sürecinin çalışmamasına; mixed content ise daha çok uygulama ve reverse proxy katmanında eksik kalan ayarlara işaret ediyor.

SSL varken bile neden “Not Secure” görebilirsiniz?

“HTTPS kurduk ama tarayıcı hâlâ mızmızlanıyor” cümlesini DCHost destek ekibinde çok duyarız. En yaygın sebepler:

• Yanlış host adına kesilmiş sertifika: Sertifika www.ornek.com için alınmış ama siteyi https://ornek.com üzerinden açıyorsunuz (veya tam tersi).
• Sertifika zinciri eksik: Sunucuda sadece sunucu sertifikası yüklenmiş, ara sertifikalar (intermediate) eksik.
• Mixed content: HTML HTTPS, içindeki bazı linkler HTTP.
• Eski TLS yapılandırması: Tarayıcı, kullanılan şifre takımlarını veya protokol sürümünü artık kabul etmiyor.

Bu tip hataların önemli bir kısmı, doğru hazırlanmış bir sunucu tarafı kontrol listesi ile baştan önlenebilir. Örneğin TLS 1.3 ve modern şifreler rehberimizde hem protokol hem de HSTS gibi kritik başlıkları ayrıntılı işlemiştik.

Mixed Content hatası nedir, nasıl tespit edilir?

Mixed Content, sayfanızın ana HTML isteği HTTPS iken, içindeki bazı kaynakların (görsel, JS, CSS, font, iframe vb.) HTTP üzerinden çağrılmasıdır. Tarayıcı bunu, güvenli bir sayfa içinde güvensiz parçalar var şeklinde yorumlar ve:

• Modern tarayıcılarda aktif içerikleri (JS, XHR vs.) bloklayabilir,
• Pasif içerikleri (görseller) yüklemeye devam etse bile “Not fully secure” uyarısı verebilir,
• Konsolda “Mixed Content” şeklinde detaylı uyarılar gösterir.

Mixed content kaynaklarını tespit etme

İlk adım, hangi kaynakların HTTP üzerinden çağrıldığını bulmak:

1. Tarayıcıda sayfanızı açın ve geliştirici araçlarını açın (Chrome için F12).
2. Console sekmesinde “Mixed Content” uyarılarını arayın. Tarayıcı, HTTP üzerinden yüklenmeye çalışan tam URL’leri listeler.
3. Network sekmesinde protokol sütununu veya istek URL’lerini kontrol ederek http:// ile başlayan istekleri filtreleyin.
4. Kaynak kodda (View Source) sabit yazılmış http:// linkleri arayın.

Bu adımlar sonunda elinizde genelde üç tip problemli bağlantı olur:

• Eski tema/plugin veya statik HTML içinde sabitlenmiş HTTP linkleri,
• CDN, harici servisler veya eski alan adı üzerinden çekilen kaynaklar,
• Yanlış base URL veya site adresi ayarları.

WordPress ve PHP uygulamalarında mixed content çözümü

WordPress ve benzeri CMS’lerde mixed content çoğu zaman temel URL ayarlarının yanlış olmasından veya veritabanına HTTP’li linklerin kaydedilmiş olmasından kaynaklanır:

• Site adresi ayarı: WordPress’te Ayarlar > Genel bölümünde Site Adresi (URL) ve WordPress Adresi (URL) alanlarının https:// ile başladığından emin olun.
• Veritabanında HTTP linkleri: Eski sitede http:// ile oluşturulmuş içerikler, görsel URL’leri ve iç linkler yeni HTTPS siteye taşındığında mixed content üretir. Bu durumda, dikkatli bir arama-değiştir (search-replace) işlemi gerekir.

Örnek bir SQL arama-değiştir (önce mutlaka yedek alın):

UPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://ornek.com', 'https://ornek.com');

Benzer işlemi wp_postmeta, tema seçenekleri tablosu ve eklenti ayarları için de tekrarlamak gerekebilir. Bu tip işlemlere başlamadan önce 3-2-1 yedekleme stratejisi rehberimizde anlattığımız gibi sağlam bir yedek planınız olduğundan emin olun.

Nginx/Apache ile mixed content’e sunucu tarafı müdahale

Kod tarafında temizlik yapmak idealdir ama özellikle büyük projelerde tüm HTTP linklerini temizlemek zaman alabilir. Bu aşamada sunucu tarafında iki yaklaşım işe yarar:

1) HTTP isteklerini HTTPS’e zorla yükseltmek

Statik dosyalarınız aynı sunucuda ve aynı alan adı altında ise, HTTP’den gelen istekleri 301 ile HTTPS’e yönlendirebilirsiniz.

Apache (.htaccess) örneği:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx örneği:

server {
    listen 80;
    server_name ornek.com www.ornek.com;
    return 301 https://$host$request_uri;
}

Bu yöntem, HTML içinde hâlâ http:// yazsa bile isteğin sunucuya HTTPS üzerinden gelmesini sağlar. Ancak farklı domain’lerdeki harici kaynaklar (örneğin bir üçüncü parti analitik script’i) için işe yaramaz.

2) Content-Security-Policy ile “upgrade-insecure-requests” kullanmak

Modern tarayıcılarda, HTTP olarak yazılmış istekleri otomatik HTTPS’e yükseltmek için şu başlığı ekleyebilirsiniz:

Content-Security-Policy: upgrade-insecure-requests

Bu başlık, “http:// yazılmış olsa bile eğer aynı kaynağın HTTPS versiyonu varsa tarayıcının onu tercih etmesini sağlar. CSP konusunda daha detaylı bir kurulum için CSP’yi doğru kurma rehberimize göz atabilirsiniz.

Unutmayın: Bu iki yaklaşım geçişi kolaylaştırmak için faydalıdır ama uzun vadede kaynak kodundaki HTTP referanslarını temizlemek en sağlıklı çözümdür.

“Not Secure” ve sertifika zinciri hatalarını hosting tarafında düzeltmek

Mixed content dışında en çok baş ağrıtan konu, tarayıcının sertifikanızı kabul etmemesi veya alan adınızla eşleştirememesidir. Bu bölümde, DCHost tarafında en sık gördüğümüz sertifika kaynaklı hataları ve çözüm adımlarını toparlayalım.

1) Sertifika süresi dolmuş (expired certificate)

Tarayıcı genellikle “NET::ERR_CERT_DATE_INVALID” gibi hatalar gösterir ve kullanıcıyı büyük bir uyarı sayfası ile karşılar. Çözüm:

• cPanel/Plesk veya sunucu panelinizden sertifikanın bitiş tarihini kontrol edin.
• ACME/otomatik yenileme kullanıyorsanız cron veya systemd timer’ın gerçekten çalıştığından emin olun.
• Elle yenileme yapıyorsanız, yeni sertifikayı yükledikten sonra eski sertifikanın tüm vhost’lardan tamamen kaldırıldığından emin olun.

Otomasyon tarafında daha ileri senaryolar için ACME otomasyonunda yedekli CA kullanımı makalemizde detaylı bir örnek akış bulabilirsiniz.

2) Alan adı uyuşmazlığı (common name / SAN hataları)

Tarayıcı hatası genelde “certificate for example.com doesn’t match www.example.com” gibidir. Sebep:

• Sertifika sadece ornek.com için alınmıştır, siz www.ornek.com üzerinden erişiyorsunuz (veya tam tersi).
• Sertifika yanlış alan adına bağlanmış vhost altında kullanılıyor.
• Wildcard sertifika beklerken tek alan adına kesilmiş bir sertifika yüklenmiş.

Çözüm tarafında iki kritik nokta var:

1. Doğru sertifika türünü seçmek: ornek.com ve www.ornek.com için SAN (Subject Alternative Name) içeren tek bir sertifika veya wildcard (*.ornek.com) tercih etmek mantıklı olabilir.
2. Doğru vhost’a bağlamak: Apache/Nginx yapılandırmasında, ilgili server_name veya ServerName/ServerAlias direktifleri ile sertifikanızı eşleştirin.

Hangi senaryoda DV, OV, EV veya wildcard sertifika tercih etmeniz gerektiği konusunda kararsızsanız, DV, OV, EV ve Wildcard SSL rehberimiz karar aşamasında iyi bir referans olacaktır.

3) Sertifika zinciri eksik (intermediate CA yüklenmemiş)

Bazen sertifikanız doğru alan adına kesilmiştir, süre geçerli görünür ama bazı tarayıcılarda veya mobil cihazlarda yine de güven hatası alırsınız. Çoğu zaman sebep:

• Sunucuya yalnızca sunucu sertifikası yüklenmiş,
• CA’nın verdiği intermediate (ara) sertifikalar yüklenmemiş veya yanlış sırada birleştirilmiş.

Çözüm için:

1. Sertifika sağlayıcınızın panelinden fullchain veya bundle dosyasını indirin.
2. Apache kullanıyorsanız SSLCertificateFile ve SSLCertificateChainFile (veya direkt SSLCertificateFile ile birleşik fullchain) ayarlarını kontrol edin.
3. Nginx’te ssl_certificate direktifinin fullchain’i işaret ettiğinden, ssl_certificate_key’in ise private key’i gösterdiğinden emin olun.

4) SNI ve birden fazla site barındırma sorunları

Aynı IP üzerinde birden fazla HTTPS site barındırıyorsanız, SNI (Server Name Indication) desteğinin hem sunucuda hem de istemci tarafında olması gerekir (modern tarayıcılarda standarttır). Yanlış yapılandırılmış vhost’lar veya eksik SNI desteği, yanlış sertifikanın sunulmasına yol açar.

cPanel, Plesk ve modern web sunucularında SNI varsayılan olarak etkin gelir. Ancak manuel Nginx/Apache yapılandırmalarında, server_name / ServerName ayarlarının doğruluğu ve dinlediğiniz IP/port kombinasyonlarının çakışmaması önemli.

HTTPS’i kalıcı hale getirmek: Yönlendirmeler, HSTS ve güvenlik başlıkları

Sertifikanız doğru, mixed content temizlenmiş olsa bile HTTP üzerinden erişime izin veriyorsanız, tarayıcılar ve kullanıcılar hâlâ risk altında olabilir. Bu aşamada devreye kalıcı yönlendirmeler ve HTTP güvenlik başlıkları giriyor.

HTTP → HTTPS yönlendirme stratejisi

Hedefiniz şu olmalı: Kullanıcı http:// ile de yazsa, her zaman tek bir kanonik HTTPS adresine düşmeli.

• Tüm http://ornek.com istekleri → https://ornek.com
• Tüm http://www.ornek.com istekleri → https://ornek.com (veya tam tersi, hangi yapıyı kanonik seçtiyseniz)

Apache örneği:

RewriteEngine On
# www'den köke yönlendirme
RewriteCond %{HTTP_HOST} ^www.ornek.com [NC]
RewriteRule ^(.*)$ https://ornek.com/$1 [L,R=301]

# HTTP'den HTTPS'e yönlendirme
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://ornek.com/$1 [L,R=301]

Nginx örneği (özet):

server {
    listen 80;
    server_name ornek.com www.ornek.com;
    return 301 https://ornek.com$request_uri;
}

HSTS ile tarayıcıya “bu site hep HTTPS” dedirtmek

HSTS (HTTP Strict Transport Security), tarayıcıya “bu alan adına bir daha asla HTTP üzerinden bağlanma” demenin standart yoludur. Doğru kullanıldığında:

• Downgrade (HTTPS → HTTP) saldırılarını engeller,
• Yanlışlıkla HTTP link tıklamalarını HTTPS’e yükseltir,
• Tarayıcı tarafında önemli bir güven sinyali üretir.

Basit bir HSTS başlığı örneği:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Bu başlığı kullanırken dikkatli olun; özellikle includeSubDomains ve preload parametreleri, yanlış yapılandırılmış alt alan adlarında problem yaratabilir. HSTS ve diğer güvenlik başlıklarını ayrıntılı anlattığımız HTTP güvenlik başlıkları rehberimize mutlaka göz atın.

DCHost tarafında pratik senaryolar: paylaşımlı hosting, VPS ve dedicated

DCHost olarak hem paylaşımlı hosting hem de VPS/dedicated ve colocation tarafında çok farklı SSL senaryoları görüyoruz. Hangi ortamda çalıştığınıza göre atmanız gereken adımlar biraz değişiyor.

Paylaşımlı hosting üzerinde SSL hatalarını düzeltmek

Paylaşımlı hosting hizmetlerinde genellikle:

• Kontrol paneli (cPanel, Plesk vb.) üzerinden otomatik SSL (ACME tabanlı) sağlanır,
• “HTTPS’e zorla yönlendir” gibi hazır seçenekler bulunur,
• Temel HSTS ve güvenlik başlıklarını ayarlayabileceğiniz arayüzler veya .htaccess erişimi vardır.

Bu ortamda yapılacaklar özetle:

1. Alan adınızın DNS kayıtlarının (A/AAAA) doğru sunucuyu gösterdiğinden emin olun.
2. Panelden SSL sertifikasının başarıyla kurulup kurulmadığını ve bitiş tarihini kontrol edin.
3. “Force HTTPS” benzeri seçeneği etkinleştirin veya kendi .htaccess yönlendirme kurallarınızı yazın.
4. WordPress / CMS tarafında site URL’sini https:// ile güncelleyin.

VPS ve dedicated sunucularda daha ince ayarlar

VPS veya fiziksel sunucuda tam yetki sizde olduğu için, SSL ve TLS tarafında çok daha ince ayarlar yapabilirsiniz ama bu aynı zamanda daha fazla sorumluluk da getirir:

• Doğru ACME istemcisini (örneğin acme.sh) kurup otomatik yenileme kurgulamak,
• Nginx/Apache’de modern TLS profilleri, OCSP stapling ve HTTP/2/3 desteğini etkinleştirmek,
• Reverse proxy, container (Docker/Kubernetes) veya load balancer arkasında doğru sertifikayı doğru katmanda sonlandırmak.

Bu konuların çoğunu daha önce parça parça işledik; örneğin:

• Nginx’te TLS 1.3, OCSP stapling ve Brotli kurulumu
• Let’s Encrypt wildcard SSL otomasyonu ve DNS-01 senaryoları
• ACME challenge türleri (HTTP-01, DNS-01, TLS-ALPN-01)

Bu rehberleri, burada anlattığımız genel prensiplerle birleştirdiğinizde, VPS ve dedicated sunucularınızda SSL ile ilgili hemen her senaryoyu yönetebilecek seviyeye gelirsiniz.

Sık yapılan hatalar ve gerçek dünya senaryoları

DCHost tarafında sahada en çok gördüğümüz birkaç tipik senaryoyu ve hosting tarafından nasıl çözümlediğimizi özetleyelim.

1) HTTP’den HTTPS’e geçişte unutulan CDN ve medya alan adları

Birçok projede statik dosyalar cdn.ornek.com gibi alt alan adlarından veya tamamen farklı bir alan adından servis edilir. Ana siteyi HTTPS’e taşıyıp sertifika alırsınız ama CDN alan adı için sertifika unutulur. Sonuç: Tüm görseller ve statik dosyalar HTTP kalır ve tarayıcı mixed content uyarısı verir.

Çözüm:

• CDN alt alanı için de sertifika alın ve sunucu/CDN tarafında tanımlayın.
• Uygulamanızın “asset URL” veya “base URL” ayarlarını HTTPS’e güncelleyin.
• Gerekirse veritabanında CDN URL’lerini de https:// ile güncelleyin.

2) Alan adı değişimi + HTTPS geçişi aynı anda

Yeni alan adına geçerken aynı zamanda HTTPS’e geçmek yaygın ama riskli bir kombinasyon. Hem yönlendirme hem de SSL tarafında iki kat hata ihtimali ortaya çıkıyor. Bu süreçte SEO kaybı yaşamamak için alan adı değiştirirken SEO kaybetmeme rehberimizi de mutlaka gözden geçirin.

Özet kontrol listesi:

• Eski domain için de geçerli bir SSL sertifikası bulundurun (en azından geçiş sürecinde).
• Eski domain’in hem HTTP hem HTTPS isteklerini yeni domain’in HTTPS kanonik adresine yönlendirin.
• Mixed content’i tetikleyebilecek eski domain referanslarını temizleyin.

3) Sertifika güncellemeleri hep son dakikaya kalıyor

Sertifika süresi dolmadan birkaç gün önce gelen uyarı e-postaları çoğu zaman gözden kaçıyor. Özellikle manuel yenileme yapılan ortamlarda, son gün fark edilen bir sertifika bitişi, birkaç saatlik “Not Secure” dönemine yol açabiliyor. Bu durumu neden sık yaşadığımıza ve operasyonel olarak nasıl önleyebileceğimize dair detaylı bir analiz için SSL sertifika güvenlik güncellemeleri yazımıza bakabilirsiniz.

Adım adım genel çözüm rehberi

Tüm anlattıklarımızı toparlayan pratik bir checklist ile bitirelim. Elinizde “Not Secure” veya mixed content uyarısı veren bir site olsun; DCHost tarafında tipik adım sıralamamız şöyle:

1. Alan adı ve DNS kontrolü: A/AAAA kayıtları doğru sunucuyu gösteriyor mu? Yanlış sunucuda eski bir sertifika kalmış mı?
2. Sertifika durumu:
   • Geçerlilik süresi kontrolü (bitmiş mi, yakında mı bitecek?),
   • Alan adı eşleşmesi (CN/SAN alanları),
   • Fullchain / intermediate sertifikaların yüklenip yüklenmediği.
3. HTTP → HTTPS yönlendirmeleri:
   • Tek bir kanonik HTTPS adresine 301 ile yönlendirme,
   • www / non-www tercihini netleştirme.
4. Mixed content taraması:
   • Tarayıcı konsolundan HTTP kaynakları listeleme,
   • CDN veya harici servis URL’lerini gözden geçirme,
   • Veritabanı ve tema/plugin ayarlarında HTTP referanslarını düzeltme.
5. Güvenlik başlıkları ve protokol:
   • HSTS, X-Content-Type-Options, X-Frame-Options vb. başlıkları ekleme,
   • TLS sürümlerini ve şifre takımlarını güncel tutma.
6. Otomasyon ve izleme:
   • ACME/otomatik yenileme süreçlerini kurma ve test etme,
   • Log ve izleme araçlarıyla sertifika yenileme hatalarını takip etme.

Sonuç: SSL hatalarını susturmak değil, altyapıyı kalıcı olarak sağlama almak

SSL sertifika hataları, tarayıcının ön yüzünde görünen küçük uyarılar gibi dursa da arka planda çoğu zaman alan adı stratejisi, DNS kurgusu, web sunucusu yapılandırması ve uygulama mimarisi ile ilgili daha derin sorunlara işaret eder. “Mixed Content” veya “Not Secure” mesajlarını tek seferlik bir düzenlemeyle susturmak mümkün; ancak asıl hedefiniz, projenizin yaşam döngüsü boyunca bu tip hataların otomatik olarak önlenmesi olmalı.

DCHost tarafında, paylaşımlı hosting’ten yönetilen VPS ve dedicated sunuculara kadar her seviyede, SSL ve TLS yapılandırmasını operasyonel süreçlerinizin doğal bir parçası haline getirmenize yardımcı oluyoruz. İster yeni HTTPS’e geçiyor olun, ister karmaşık bir SaaS altyapısında onlarca alan adı ve wildcard sertifikayı yönetiyor olun; doğru DNS, doğru ACME akışı ve doğru web sunucusu ayarlarıyla bu süreci öngörülebilir, tekrarlanabilir ve denetlenebilir kılmak mümkün.

Eğer bugün sitenizde tarayıcı uyarıları görüyorsanız; yukarıdaki kontrol listesiyle başlayın, kritik noktaları işaretleyin ve gerekirse DCHost altyapısında size uygun hosting, VPS veya dedicated sunucu çözümlerini değerlendirerek SSL tarafını uzun vadeli bir plana oturtun. Böylece hem kullanıcılarınız hem de arama motorları için sitenizin gerçekten “güvenli” olduğunu teknik olarak kanıtlamış olursunuz.