Cloudflare SSL Modları: Flexible, Full ve Full (Strict) Hangisi Doğru?

Sitenizi Cloudflare'e taşıdınız, SSL/TLS sekmesinde dört seçenek duruyor ve hiçbiri ne yaptığını açıkça anlatmıyor. Sunucunuzda sertifika yok ya da süresi dolmuş; Flexible seçtiğiniz anda tarayıcıda yeşil kilit beliriyor, adres çubuğunda https:// yazıyor, iş bitmiş görünüyor. Bir hafta sonra ya da ilk wp-admin girişinde "ERR_TOO_MANY_REDIRECTS" ekranıyla karşılaşıyorsunuz ve site tamamen erişilemez hale geliyor.

Bu iki olay birbirinden bağımsız değil. Aynı ayarın iki ayrı sonucu. Çünkü Cloudflare kullandığınızda bağlantı tek parça değil, iki ayrı bacak haline gelir: ziyaretçi ile Cloudflare arasındaki bacak ve Cloudflare ile sizin sunucunuz arasındaki bacak. SSL modu, ikinci bacakta ne olacağını belirler — ilkinde değil. Yeşil kilit ise yalnızca birinci bacağı gösterir. Flexible'ın bu kadar cazip ve bu kadar tehlikeli olmasının sebebi tam olarak budur: tarayıcıya ziyaretçinin göreceği tek şeyi verir, arkadaki yarıyı açıkta bırakır.

Bu yazıda her modun iki bacakta tam olarak ne yaptığını ayıracağız, Flexible'ın nasıl hem sahte bir güvenlik hissi hem de somut bir yönlendirme döngüsü ürettiğini adım adım göstereceğiz ve hedefi baştan koyacağız: doğru cevap her zaman Full (Strict). Sonrasında sunucunuzda sertifika olmasa bile oraya nasıl geçeceğinizi iki farklı yolla anlatacağım.

Cloudflare Devredeyken Bağlantı Neden İkiye Bölünür?#

Cloudflare'i proxy modunda (DNS kaydında turuncu bulut) kullandığınızda ziyaretçi artık doğrudan sunucunuza bağlanmaz. Trafiği en yakın Cloudflare veri merkezi karşılar, orada sonlandırır, sonra kendi adına sizin sunucunuza yeni bir bağlantı açar. Ortaya çıkan yapı şudur:

Ziyaretçi  ──[1. bacak]──►  Cloudflare  ──[2. bacak]──►  Sizin sunucunuz (origin)
           HTTPS (Universal SSL)          SSL moduna göre değişir

Birinci bacak neredeyse her zaman güvendedir: Cloudflare, alan adınız için ücretsiz Universal SSL sertifikası üretir ve ziyaretçiyle arasındaki trafiği şifreler. Tarayıcıdaki kilit simgesi bu bacağı anlatır ve ikinci bacak hakkında hiçbir şey söylemez.

İkinci bacak ise tamamen sizin seçtiğiniz SSL moduna bağlıdır. Ziyaretçi hiçbir zaman bu bacağı göremez; ne tarayıcısı, ne bir eklenti, ne de kilit simgesi. Bu görünmezlik, yanlış modun aylarca fark edilmeden kalmasının sebebidir. Cloudflare'in genel çalışma mantığını hatırlamak isterseniz Cloudflare DNS ve CDN kullanımı yazısı iyi bir arka plan sunar.

Dört Mod, İki Bacak: Karşılaştırma Tablosu#

Cloudflare panelinde SSL/TLS → Overview altında bulacağınız modlar ve ne yaptıkları:

Tablodaki iki satır özellikle dikkat ister.

Flexible satırındaki kalın hücre, bu modun tek cümlelik özetidir: ziyaretçinin gönderdiği şifre, kredi kartı bilgisi ya da oturum çerezi Cloudflare'de açılır ve sizin sunucunuza düz metin olarak gider. Kilit simgesi vardır ama koruma yarım yoldadır.

Full satırında ise şifreleme vardır, doğrulama yoktur. Sunucunuz kendi imzalı, süresi dolmuş ya da başka bir alan adına ait bir sertifika sunsa bile Cloudflare itiraz etmez. Bu, curl komutuna -k eklemenin Cloudflare'deki karşılığıdır: bağlantı şifrelidir ama karşı tarafın kim olduğu doğrulanmaz.

Ek olarak Cloudflare, yeni eklenen alan adları için Automatic SSL/TLS adında bir otomatik seçim mekanizması sunar; sunucuda TLS tespit ederse Full, edemezse Flexible ile başlar ve trafiği kademeli olarak daha güvenli moda taşımayı dener. Otomatik davranış faydalıdır ama bir hedef değildir: nereye varmak istediğinizi bilerek moda kendiniz karar vermeniz gerekir.

Flexible Neden Sahte HTTPS Üretir?#

Flexible modunda ziyaretçi https://siteniz.com adresini görür, sertifika geçerlidir, tarayıcı memnundur. Ama Cloudflare veri merkezinden çıkıp sunucunuza giden paketler 80 numaralı portta, şifresiz gider. Yani:

• Kullanıcının giriş formuna yazdığı parola, Cloudflare ile sunucunuz arasındaki bütün ağ üzerinde okunabilir haldedir.
• Bu yol kısa değildir: veri merkezinden çıkar, birden fazla transit sağlayıcıdan geçer, veri merkezinize girer.
• Trafiğe müdahale eden biri yalnızca okumakla kalmaz, yanıtı değiştirebilir; sayfanıza reklam ya da zararlı betik enjekte edilebilir ve ziyaretçi bunu sizin sitenizden gelmiş sayar.

Buradaki asıl sorun teknik olmaktan çok bilişseldir: Flexible, gerçekte var olmayan bir güvenceyi görsel olarak ilan eder. KVKK ya da PCI-DSS kapsamında "trafiğimiz uçtan uca şifreli" beyanı veriyorsanız, Flexible ile bu beyan yanlıştır — şifreleme uçtan uca değil, yolun yarısındadır.

Bir de pratik bir yan etkisi var: sunucunuz isteği HTTP olarak aldığı için uygulamanız da bağlantıyı şifresiz sanır. WordPress'te is_ssl() false döner, üretilen bağlantılar http:// ile başlar, sayfa karışık içerik (mixed content) uyarısı verir. Bu davranışın tetiklediği en can sıkıcı sonuç ise bir sonraki bölümde.

Sonsuz Yönlendirme Döngüsü Tam Olarak Nasıl Oluşuyor?#

Senaryo son derece yaygındır. Sunucunuzda, herkesin yaptığı gibi, HTTP isteklerini HTTPS'e çeviren bir kural var:

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

Cloudflare Flexible modundayken ne olduğunu adım adım izleyelim:

1. Ziyaretçi https://siteniz.com adresini ister.
2. Cloudflare isteği karşılar ve sunucunuza HTTP olarak iletir.
3. Sunucunuz %{HTTPS} off koşulunu doğru bulur ve https://siteniz.com adresine 301 yönlendirmesi döndürür.
4. Cloudflare bu yönlendirmeyi ziyaretçiye iletir; tarayıcı aynı adresi tekrar ister.
5. Cloudflare isteği yine HTTP olarak sunucunuza iletir. Başa döndük.

Tarayıcı belirli bir sayıdan sonra pes eder ve ERR_TOO_MANY_REDIRECTS gösterir. Site tamamen erişilemezdir; ne ön yüz, ne panel. Sunucu logunda ardı ardına 301 satırları görürsünüz ve hiçbiri hatalı değildir — kural doğru çalışmaktadır, kurala yanlış bilgi verilmektedir. Bu hatanın Cloudflare dışındaki nedenleri için ERR_TOO_MANY_REDIRECTS hatası yazısına bakabilirsiniz.

Geçici çare ile gerçek çözümü karıştırmayın#

İnternette bu duruma iki "çözüm" önerilir. İkisi de yönlendirmeyi durdurur, sadece biri sorunu çözer.

Birincisi, kuralı Cloudflare'in gönderdiği başlığa bakacak şekilde değiştirmektir:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Bu, döngüyü kırar. Ama ikinci bacak hâlâ şifresizdir; yalnızca belirtiyi ortadan kaldırdınız. WordPress kullanıyorsanız aynı mantığın uygulama tarafındaki karşılığı wp-config.php içine eklenir:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Bu satır is_ssl() fonksiyonunun doğru cevap vermesini sağlar ve karışık içerik uyarılarını giderir; WordPress tarafındaki tabloyu WordPress'te HTTPS zorlama yazısında bulabilirsiniz. Yine de asıl düzeltme bu değil.

İkincisi ve doğrusu: modu Full (Strict) yapmak. O zaman Cloudflare sunucunuza HTTPS ile bağlanır, %{HTTPS} gerçekten on olur, yönlendirme kuralı ilk seferde tatmin olur ve döngü kendiliğinden ortadan kalkar. Başlık kontrolüne dayalı kuralı da isterseniz koruyabilirsiniz — ters proxy senaryolarında zararı olmaz. Yönlendirmenin doğru kurgusu için HTTPS yönlendirme yazısı ayrıntılı bir referanstır.

Full ile Full (Strict) Arasındaki Fark Neden Önemli?#

İkisi de ikinci bacağı şifreler. Aradaki tek fark doğrulamadır ve o tek fark, korumanın ne işe yaradığını belirler.

Full modunda Cloudflare sunucunuza HTTPS ile bağlanır ama sertifikaya bakmaz. Sertifika kendi imzalı olabilir, beş yıl önce süresi dolmuş olabilir, başka bir alan adına ait olabilir — hiçbiri engel değildir. Şifreleme sağlanır, kimlik doğrulanmaz. Yani Cloudflare ile sunucunuz arasına giren biri kendi sertifikasını sunarsa Cloudflare bunu kabul eder ve trafiği ona teslim eder. Şifrelemenin koruduğu şey, şifrelemenin doğru tarafla kurulduğu varsayımına dayanır; Full bu varsayımı test etmez.

Full (Strict) ise sunucunuzdaki sertifikanın üç koşulu birden sağlamasını ister:

1. Süresi dolmamış olacak.
2. Herkesçe güvenilen bir sertifika otoritesi tarafından ya da Cloudflare'in kendi Origin CA'sı tarafından imzalanmış olacak.
3. Sertifikanın CN ya da SAN alanı istenen alan adıyla eşleşecek.

Üçü sağlandığında ikinci bacak da birinci bacak kadar korunaklı hale gelir. Bu yüzden hedef her zaman Full (Strict)'tir; Full yalnızca oraya giderken kısa süreli konaklanan bir ara duraktır.

Full (Strict) modunda sunucu sertifikası geçersizse Cloudflare isteği tamamlamaz ve ziyaretçiye Error 526 (Invalid SSL certificate) gösterir. Bu hata iyi bir haberdir: modun gerçekten çalıştığını, bir şeyin sessizce kabul edilmediğini kanıtlar. Cloudflare'in diğer 5xx kodlarının ne anlama geldiğini Cloudflare 520, 521 ve 522 hataları yazısında bulabilirsiniz.

Sunucumda Sertifika Yok: Full (Strict) Nasıl Açılır?#

İki yol var, ikisi de ücretsiz. Hangisini seçeceğiniz, sunucunuza doğrudan HTTPS ile erişilmesi gerekip gerekmediğine bağlıdır.

Yol 1: Let's Encrypt ile herkesçe güvenilen sertifika#

Sunucunuza normal bir Let's Encrypt sertifikası kurarsınız; Cloudflare bunu doğrular ve Full (Strict) sorunsuz çalışır. Avantajı, sertifikanın her yerde geçerli olmasıdır: Cloudflare'i devre dışı bıraksanız da, sunucuya IP üzerinden değil alan adıyla doğrudan bağlansanız da geçerlidir.

Proxy açıkken doğrulama yapmanın en dertsiz yolu DNS tabanlı doğrulamadır; HTTP doğrulaması Cloudflare katmanından geçtiği için ek kurallara takılabilir:

# HTTP-01 doğrulaması (proxy açıkken de çoğu durumda çalışır)
sudo certbot --nginx -d siteniz.com -d www.siteniz.com

# DNS-01 doğrulaması: Cloudflare API token'ı ile, proxy durumundan bağımsız
sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d siteniz.com -d "*.siteniz.com"

Kurulum ve otomatik yenileme ayrıntıları için Let's Encrypt ile ücretsiz SSL yazısına bakın.

Yol 2: Cloudflare Origin CA sertifikası#

Cloudflare, yalnızca kendi kenar sunucularının güvendiği bir sertifika üretmenizi sağlar. Tarayıcılar bu sertifikayı tanımaz — zaten tanımasına gerek yoktur, çünkü ziyaretçi hiçbir zaman onu görmez; ikinci bacakta kullanılır ve Cloudflare Full (Strict) modunda kendi kökünü tanıdığı için doğrulama başarılı olur.

Öne çıkan farkı ömrüdür: Origin CA sertifikaları 15 yıla kadar geçerli olacak şekilde üretilebilir, yani 90 günlük yenileme döngüsüyle uğraşmazsınız. Panelde SSL/TLS → Origin Server → Create Certificate adımından üretilir; anahtar tipi olarak RSA veya ECC seçebilir, kapsayacağı ana bilgisayar adlarını yazabilirsiniz (kök alan adı ve birinci seviye joker karakter varsayılan olarak gelir).

Kurulum, sıradan bir sertifika kurulumundan farksızdır:

server {
    listen 443 ssl;
    server_name siteniz.com www.siteniz.com;

    ssl_certificate     /etc/ssl/cloudflare/origin.pem;
    ssl_certificate_key /etc/ssl/cloudflare/origin.key;

    ssl_protocols       TLSv1.2 TLSv1.3;
}

Dosya izinlerini unutmayın; özel anahtar yalnızca root tarafından okunabilir olmalıdır:

sudo chmod 600 /etc/ssl/cloudflare/origin.key
sudo chown root:root /etc/ssl/cloudflare/origin.key
sudo nginx -t && sudo systemctl reload nginx

İki uyarı: Cloudflare bu sertifikaların süresi dolmadan önce bildirim göndermez, dolayısıyla bitiş tarihini kendi takip listenize almanız gerekir. Ve Origin CA sertifikası proxy kapalıyken (gri bulut) hiçbir işe yaramaz; tarayıcı sertifikayı tanımadığı için ziyaretçi uyarı ekranı görür. Sunucuya doğrudan erişim ihtiyacınız varsa birinci yolu seçin.

Modu Değiştirmeden Önce ve Sonra Ne Doğrulanmalı?#

Sunucu tarafındaki sertifika hazır olmadan modu değiştirmek siteyi düşürür. Sıralama şudur:

1. Sunucuya sertifikayı kurun ve web sunucusunu yeniden yükleyin.
2. Cloudflare'i atlayarak, doğrudan sunucu IP'sine bağlanıp sertifikayı doğrulayın:

# Cloudflare'i devre dışı bırakıp doğrudan origin'i test et
curl -sv --resolve siteniz.com:443:203.0.113.10 https://siteniz.com/ 2>&1 \
  | grep -E "subject:|issuer:|expire|SSL certificate verify"

3. Çıktı temizse Cloudflare panelinde modu Full (Strict) yapın.
4. Ziyaretçi tarafını kontrol edin ve Always Use HTTPS ayarını açın; böylece HTTP ile gelen istekler daha kenar sunucuda HTTPS'e çevrilir ve sunucunuzun yönlendirme kuralına hiç ihtiyaç kalmaz.
5. Karışık içerik uyarısı kalırsa Automatic HTTPS Rewrites ayarını açın; kalıcı çözüm veritabanındaki http:// bağlantılarını düzeltmektir.

Doğrulamayı bitirdikten sonra dış bir araçla sertifika zincirini de kontrol etmek iyi bir alışkanlıktır; SSL Labs testi bunun için yaygın kullanılan yöntemdir.

Hangi Durumda Hangi Mod: Hızlı Karar Rehberi#

Flexible sütununun tabloda hiç görünmemesi tesadüf değil. Flexible, sunucunuza HTTPS kuramadığınız bir dönemde siteyi HTTPS'li göstermek için tasarlanmış bir köprüdür ve ücretsiz sertifikalar yaygınlaştığından beri o köprüye gerçekten ihtiyaç duyan senaryo neredeyse kalmadı. Bugün Flexible'da olan çoğu site, oraya bilinçli bir kararla değil, kurulum sırasında en az direnç gösteren seçenek olduğu için düşmüştür.

Sıkça Sorulan Sorular#

Flexible modunda sitem HTTPS görünüyor, bu yeterli değil mi?#

Yeterli değildir. Yeşil kilit yalnızca ziyaretçi ile Cloudflare arasındaki bacağı gösterir; Cloudflare'den sunucunuza giden ikinci bacak Flexible modunda tamamen şifresizdir. Kullanıcı paroları ve oturum çerezleri o yolda düz metin olarak taşınır ve trafiğe müdahale eden biri yanıtı değiştirip sayfanıza zararlı içerik ekleyebilir. Görünen güvence ile gerçek koruma burada ayrışır.

Full ile Full (Strict) arasında pratikte ne fark var?#

İkisi de ikinci bacağı şifreler; fark doğrulamadadır. Full modunda Cloudflare sunucunuzun sertifikasına hiç bakmaz, dolayısıyla süresi dolmuş, kendi imzalı ya da başka alan adına ait bir sertifika kabul edilir. Full (Strict) ise sertifikanın geçerli, güvenilen bir otorite veya Cloudflare Origin CA tarafından imzalanmış ve alan adıyla eşleşiyor olmasını şart koşar. Araya girme saldırısına karşı gerçek koruma yalnızca ikincisinde vardır.

Cloudflare Origin CA sertifikası ücretsiz mi ve tarayıcılar tanır mı?#

Ücretsizdir ve 15 yıla kadar geçerli üretilebilir, ancak tarayıcılar tanımaz. Bu bir eksiklik değil, tasarım tercihidir: sertifika yalnızca Cloudflare ile sunucunuz arasındaki bacakta kullanılır ve ziyaretçi onu hiç görmez. Ancak proxy'yi kapatıp trafiği doğrudan sunucunuza yönlendirirseniz ziyaretçiler güvenlik uyarısı alır. Doğrudan erişim ihtiyacınız varsa Let's Encrypt tercih edin.

Modu Full (Strict) yaptım ve Error 526 alıyorum, ne yapmalıyım?#

526 hatası, Cloudflare'in sunucunuzun sertifikasını doğrulayamadığını söyler. En yaygın üç sebep sertifikanın süresinin dolmuş olması, kendi imzalı olması ve alan adının sertifikadaki CN veya SAN alanıyla eşleşmemesidir. Cloudflare'i atlayarak sunucu IP'sine doğrudan bağlanıp sertifikayı inceleyin. Ara sertifikanın eksik olması da aynı hataya yol açabilir, bu yüzden zincirin tamamının sunulduğundan emin olun.

Cloudflare kullanırken sunucuma ayrıca sertifika kurmama gerek var mı?#

Evet, Full (Strict) modunu kullanmak istiyorsanız gerekir. Cloudflare'in ürettiği Universal SSL sertifikası yalnızca ziyaretçi ile Cloudflare arasındaki bacak içindir; sunucunuza kurulmaz ve orada kullanılamaz. İkinci bacağın da korunması için sunucuda ayrı bir sertifika bulunmalıdır. Bu ya Let's Encrypt gibi ücretsiz bir sertifika ya da Cloudflare Origin CA sertifikası olabilir.

ERR_TOO_MANY_REDIRECTS hatası Cloudflare'den mi kaynaklanıyor?#

Doğrudan Cloudflare'den değil, Flexible modu ile sunucunuzdaki HTTPS yönlendirme kuralının birlikte oluşturduğu döngüden kaynaklanır. Cloudflare isteği sunucunuza HTTP olarak gönderir, sunucunuz bunu görüp HTTPS'e yönlendirir, gelen yeni istek yine HTTP olarak iletilir ve döngü kapanmaz. Modu Full (Strict) yapmak sorunu kökünden çözer; yönlendirme kuralını X-Forwarded-Proto başlığına bakacak şekilde değiştirmek ise yalnızca belirtiyi giderir.

Full (Strict) moduna geçerken sitem kapanır mı?#

Sunucunuzda geçerli bir sertifika hazırsa kapanmaz, geçiş anlıktır. Riski ortadan kaldırmanın yolu sıralamaya uymaktır: önce sertifikayı kurun, web sunucusunu yeniden yükleyin, ardından Cloudflare'i atlayarak doğrudan sunucu IP'sine bağlanıp sertifikayı doğrulayın. Bu test temiz sonuç veriyorsa modu değiştirmek güvenlidir. Sertifika hazır değilken modu değiştirirseniz ziyaretçiler 526 hatası görür.