CDN Arkasında Gerçek HTTPS ve Full (Strict) SSL Kurulumu

CDN arkasında gerçek HTTPS neden bu kadar kritik?

CDN kullanmaya başlayan çoğu proje ilk etapta performans kazanımına odaklanıyor: daha düşük gecikme, statik dosyaların edge’te cache’lenmesi, DDoS’a karşı temel koruma… Ancak mimari toplantılarında genellikle gözden kaçan kritik bir detay var: HTTPS trafiğiniz CDN’den origin sunucuya kadar gerçekten uçtan uca şifreli mi, yoksa tarayıcıda yeşil kilidi görüp içimiz rahatlasa da arka tarafta HTTP mi dolaşıyor?

DCHost tarafında onlarca projede gördüğümüz ortak hata, CDN’de “HTTPS aktif” göründüğü için her şeyin güvende sanılması. Oysa yanlış seçilmiş bir SSL modu (örneğin sadece CDN’de sonlanan, origin’e HTTP giden “esnek/flexible” türler) şu riskleri doğuruyor:

• CDN ile origin arasındaki trafik düz metin (HTTP) gidiyor; veri merkezleri arası dinleme (sniffing) mümkün.
• Araya giren saldırgan (MITM) CDN–origin hattında istekleri değiştirebiliyor.
• PCI-DSS, KVKK/GDPR gibi uyumluluk gereklilikleri karşılanmıyor.
• İleride HSTS, HTTP/2, HTTP/3, mTLS gibi gelişmiş güvenlik adımlarını uygulamak zorlaşıyor.

Bu yazıda DCHost ekibi olarak, CDN arkasında gerçek HTTPS kurulumunu uçtan uca ele alacağız: SSL termination nedir, Full ve Full (Strict) SSL arasındaki farklar nelerdir, origin şifreleme ve hatta mTLS (karşılıklı TLS) nasıl devreye alınır? Ayrıca hem paylaşımlı hosting, hem VPS/dedicated ortamları için pratik yapılandırma örnekleri paylaşacağız.

Temel kavramlar: SSL termination, passthrough ve origin şifreleme

Önce mimariyi netleştirelim. CDN arkasında HTTPS konuşurken aslında üç ayrı bacağı yönetiyoruz:

• Tarayıcı → CDN (kullanıcı ile edge arasındaki bağlantı)
• CDN → Origin (edge ile asıl web sunucunuz arasındaki bağlantı)
• Origin içinde/arkasında servisler (uygulama–veritabanı–API arası trafiğiniz)

Bu tabloda karşımıza üç önemli kavram çıkıyor:

SSL Termination (TLS sonlandırma)

SSL termination, şifreli bağlantının sonlandığı noktayı ifade eder. Örneğin:

• Tarayıcı CDN’e https ile bağlanır, CDN sertifikayı sunar ve trafiği çözer.
• CDN, origin’e HTTP ile bağlanabilir (yanlış ama yaygın), ya da tekrar HTTPS ile şifreleyebilir.

Bu durumda ilk TLS katmanı CDN’de sonlanır. Eğer origin’e kadar şifreli gitmek istiyorsak ikinci bir TLS katmanı daha devreye girer.

TLS Passthrough

TLS passthrough, CDN veya reverse proxy’nin TLS’i çözmeden, şifreli trafiği doğrudan arka uç sunucuya aktarmasıdır. Bu modelde sertifika doğrulaması tamamen origin tarafında yapılır. Bazı L4 load balancer ve gelişmiş CDN özelliklerinde karşımıza çıkar. Ancak çoğu web projesinde CDN’in header ekleyebilmesi, cache kontrolü yapabilmesi için termination modeli tercih edilir.

Origin şifreleme

Origin şifreleme, CDN → origin trafiğinin de mutlaka TLS ile korunmasını ifade eder. Yani sadece tarayıcıdan CDN’e kadar değil, edge’ten veri merkezinizdeki web sunucusuna kadar olan hat da şifrelenmiş olur. Bu noktada:

• Origin’de geçerli bir SSL sertifikası (public CA veya CDN’in kendi origin sertifikası)
• Doğru hostname/SNI yapılandırması
• Mümkünse sertifika doğrulamasının zorunlu kılınması (Full Strict, mTLS gibi)

gibi detaylar devreye girer.

CDN SSL modları: Flexible, Full ve Full (Strict) farkı

Birçok CDN panelinde üç temel SSL modu görürsünüz. İsimler değişebilir ama mantık genelde aynıdır:

1. Flexible (esnek) SSL – Kaçınılması gereken mod

Bu modda yapı şöyle çalışır:

• Tarayıcı → CDN: HTTPS
• CDN → Origin: HTTP (şifresiz)

Dışarıdan bakınca site tamamen HTTPS görünür; tarayıcıda kilit işareti vardır. Ancak CDN’in sizin sunucunuza bağlandığı hat düz metindir. Bu modelin sakıncaları:

• CDN–origin trafiği dinlenebilir, değiştirilebilir.
• Şirket içi güvenlik taramalarında “HTTPS var” sanılırken aslında yarım bir şifreleme uygulanıyor olur.
• KVKK, PCI-DSS gibi regülasyonlarda bu yapı genellikle uyumsuz kabul edilir.

Özetle: Flexible/Esnek SSL, sadece çok acil debug ortamları dışında production’da kullanılmamalı.

2. Full SSL – Şifreli ama zayıf doğrulama

Full modda:

• Tarayıcı → CDN: HTTPS
• CDN → Origin: HTTPS (şifreli), ancak sertifika detayları gevşek kontrol edilir.

CDN, origin’e TLS ile bağlanır ama çoğu Full modda:

• Sertifikanın süresi dolmuş olsa bile bağlantı kabul edilebilir.
• Hostname uyuşmazlığı (CN/SAN uyuşmazlığı) göz ardı edilebilir.
• Self-signed sertifikalar sessizce kabul edilebilir.

Bu, dinlemeye karşı koruma sağlar ama gerçek bir kimlik doğrulaması sunmaz. Yine de Flexible’a göre önemli bir adımdır.

3. Full (Strict) SSL – Önerilen üretim modu

Full (Strict) modda ise tablo şöyledir:

• Tarayıcı → CDN: HTTPS
• CDN → Origin: HTTPS ve sertifika sıkı doğrulama ile kontrol edilir.

Buradaki kritik noktalar:

• Origin sertifikası tanınmış bir CA’dan ya da CDN’in kendi origin CA’sinden alınmış olmalı.
• Hostname (SNI) tam olarak eşleşmeli.
• Sertifika süresi geçmemiş olmalı.
• Güvensiz algoritmalar ve çok zayıf şifreler genellikle reddedilir.

Üretim ortamlarında DCHost olarak her zaman Full (Strict) modunu, hatta uygun projelerde bunun bir adım ötesi olan mTLS (karşılıklı TLS) yaklaşımını öneriyoruz.

Origin sunucuda doğru SSL/TLS kurulumu

CDN tarafında ne seçerseniz seçin, işin temeli her zaman origin sunucudaki SSL/TLS yapılandırmasıdır. DCHost üzerinde paylaşımlı hosting, VPS veya dedicated fark etmeksizin aşağıdaki prensipleri izlemenizi öneririz.

1. Doğru sertifika türünü seçmek

Önce hangi tip sertifikaya ihtiyacınız olduğuna karar verin:

• Tek domain (ör. www.ornek.com)
• Wildcard (ör. *.ornek.com)
• SAN/Multi-Domain (birden fazla alan adı)

Bu konuya daha detaylı bakmak isterseniz, blogda yayınladığımız Wildcard SSL ve SAN sertifikalar arasındaki farkları anlattığımız rehberi inceleyebilirsiniz.

2. Let’s Encrypt veya kurumsal SSL kurulumu

DCHost altyapısında:

• Paylaşımlı hosting ve çoğu panel (cPanel, DirectAdmin, Plesk) üzerinde Let’s Encrypt’i tek tıkla etkinleştirebilirsiniz.
• VPS ve dedicated sunucularda ise ACME istemcileri (ör. acme.sh, certbot) ile otomatik yenileme kurmanızı tavsiye ederiz.

Wildcard kullanıyorsanız, genellikle DNS-01 challenge gerekir. Bununla ilgili adım adım kurulumu, Let’s Encrypt wildcard SSL otomasyonu rehberimizde detaylandırdık.

3. Nginx için örnek TLS yapılandırması

VPS veya dedicated sunucuda Nginx kullanıyorsanız, tipik bir HTTPS sanal host şöyle görünebilir:

server {
    listen 443 ssl http2;
    server_name www.ornek.com ornek.com;

    ssl_certificate     /etc/letsencrypt/live/www.ornek.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.ornek.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    # Örnek güçlü ayarlar, ayrıntı için ilgili TLS makalelerine bakın
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:...';

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    root /var/www/ornek.com/public;
    index index.php index.html;

    # PHP-FPM, cache vb. ayarlar...
}

TLS 1.3, OCSP stapling, modern şifre kümeleri gibi konularda daha detaylı ayarları TLS 1.3 ve modern şifreler rehberimizde adım adım anlattık.

4. Apache için örnek TLS yapılandırması

<VirtualHost *:443>
    ServerName www.ornek.com
    ServerAlias ornek.com

    DocumentRoot /var/www/ornek.com/public

    SSLEngine on
    SSLCertificateFile      /etc/letsencrypt/live/www.ornek.com/fullchain.pem
    SSLCertificateKeyFile   /etc/letsencrypt/live/www.ornek.com/privkey.pem

    SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite HIGH:!aNULL:!MD5
    SSLHonorCipherOrder on

    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

    # PHP handler, log vb...
</VirtualHost>

Bu noktada siteniz CDN olmadan da tamamen HTTPS üzerinde sorunsuz çalışıyor olmalı. Sonraki adım, CDN tarafa bu yapıyı doğru anlatmak.

CDN tarafında Full (Strict) SSL’i adım adım kurmak

Origin tarafınız hazır olduktan sonra, CDN panelinizde aşağıdaki adımları izlemeniz gerekir. CDN ismi değişse de mantık genelde benzerdir.

1. CDN’de SSL modunu Full (Strict) olarak ayarlayın

İlk adım, SSL/TLS bölümünde Full (Strict) veya benzeri bir modu seçmektir. Bu, CDN’in origin’e bağlanırken sertifikayı gerçekten doğrulaması anlamına gelir.

Dikkat edilmesi gerekenler:

• Origin’deki sertifika, CDN’in bağlandığı hostname ile tam eşleşmeli.
• CDN’in origin’e hangi host header ile gittiğini kontrol edin (çoğu panelde “Origin Hostname” veya “Origin Server Name” alanı bulunur).
• Wildcard veya SAN sertifika kullanıyorsanız, doğru alt alan adlarını kapsadığından emin olun.

2. Sertifikayı CDN’e mi yükleyeceksiniz, CDN mi sizin için üretecek?

İki senaryo var:

• Tarayıcı → CDN için: Çoğu CDN, sizin adınıza ücretsiz DV sertifikası üretir. Bazılarında ise kendi SSL’inizi (EV/OV gibi) yükleyebilirsiniz.
• CDN → Origin için: Ya standart bir CA’dan aldığınız sertifikayı kullanırsınız ya da CDN’in sağladığı özel origin sertifikasını sunucuya kurarsınız.

İkinci seçenek (CDN origin sertifikası), origin’in sadece o CDN tarafından güvenilir kılınmasını sağlar. Böylece kötü niyetli biri, aynı hostname ile sahte bir sunucu kursa bile CDN ona bağlanmaz.

3. HSTS, HTTP→HTTPS yönlendirmeleri ve SEO

CDN arkasında HTTPS’e geçtiğinizde aşağıdakileri unutmayın:

• Tüm HTTP isteklerini 301 ile HTTPS’e yönlendirin (tercihen origin tarafında).
• HSTS kullanıyorsanız, CDN’in de bu header’ı ilettiğinden emin olun.
• Canonical URL’lerinizde protokolü güncelleyin.

Bu süreci daha geniş bir perspektiften ele aldığımız HTTP’den HTTPS’e geçiş rehberimiz, CDN önünde de benzer mantıkla uygulanabilir.

Origin’i gerçekten korumak: IP kısıtlama, mTLS ve Authenticated Origin Pulls

Full (Strict) SSL, trafiğin şifrelenmesini ve sertifikanın doğrulanmasını sağlar. Ancak bir adım daha ileri gidip, origin sunucunun sadece CDN’den gelen trafiği kabul etmesini sağlayabilirsiniz. Böylece:

• Doğrudan IP ile siteye erişim engellenir.
• CDN’i atlayarak yapılan saldırılar boşa çıkar.
• Gerçek kullanıcı trafiği mutlaka CDN filtrelerinden geçmiş olur.

1. IP whitelisting (CDN IP’lerine izin vermek)

Basit ama etkili bir yöntem: Güvenlik duvarınızda (iptables, ufw, firewalld, DCHost panel güvenlik kuralları vb.) sadece CDN’in yayınladığı IP aralıklarına 80/443 izni verip, diğer IP’leri engelleyebilirsiniz.

Bunun avantajları:

• Kurulumu basit; ek şifreleme gerektirmez.
• Çoğu küçük ve orta ölçekli site için yeterli seviye sağlar.

Dezavantajları:

• CDN IP aralıkları değiştiğinde whitelist’i güncellemeniz gerekir.
• Birden fazla CDN/servis kullanıyorsanız kurallar karmaşıklaşabilir.

2. Authenticated Origin Pulls (CDN → origin mTLS)

Daha gelişmiş bir yöntem, CDN’in client sertifikası ile kendini origin’e tanıtmasıdır. Örneğin bazı CDN’ler “Authenticated Origin Pulls” adını verdikleri özellikle, origin’e bağlanırken istemci sertifikası gönderir ve siz de Nginx/Apache tarafında sadece bu sertifikayı taşıyan bağlantıları kabul edersiniz.

Bu yapıyı daha önce detaylı ele aldığımız origin’i mTLS ile koruma rehberimiz, Nginx ve CDN özelinde adım adım anlatıyor. Aynı prensip, diğer CDN’ler ve reverse proxy’ler için de geçerli.

3. Kendi mTLS altyapınızı kurmak

CDN kullanmasanız bile, iç servisleriniz (API gateway, mikroservisler, panel erişimi vb.) için mTLS kurmak oldukça güçlü bir güvenlik katmanı sunar. Nginx ve Caddy üzerinde mTLS kurulumunu, istemci sertifikalarının nasıl zorunlu kılınacağını ve sadece belirli CA’lardan gelen sertifikaların nasıl kabul edileceğini anlattığımız mTLS rehberimiz bu noktada iyi bir başvuru kaynağı olabilir.

Gerçek dünya senaryoları: Hangi mimaride ne yapmak mantıklı?

Senaryo 1: Klasik WordPress + CDN

Basit bir kurumsal site veya orta ölçekli bir blog düşünelim. WordPress, DCHost paylaşımlı hosting veya NVMe VPS üzerinde çalışıyor, önünde popüler bir CDN var.

• Origin’de Let’s Encrypt veya kurumsal DV/OV sertifikası.
• Nginx/Apache’de TLS 1.2+1.3, HSTS, OCSP stapling ayarlı.
• CDN → origin trafiği için Full (Strict) mod.
• Güvenlik duvarında IP whitelisting veya en azından rate limit.

Bu yapı, çoğu kurumsal site için güvenlik, performans ve işletme maliyeti dengesini iyi kurar.

Senaryo 2: WooCommerce veya ödeme alan e‑ticaret sitesi

Burada iş biraz daha ciddi; ödeme sayfalarında PCI-DSS uyumu, hata anında minimum risk, loglama gibi konular devreye giriyor. DCHost müşterilerinde sıkça uyguladığımız yaklaşım:

• Origin’de kurumsal SSL (OV/EV) veya en azından iyi yönetilen DV.
• CDN’de Full (Strict) SSL, minimum TLS 1.2.
• Kritik admin ve ödeme endpoint’leri için CDN tarafında da ek WAF kuralları.
• Origin IP’si doğrudan erişime kapalı; sadece CDN IP’leri ve bakım için VPN’den erişim.

Ödeme süreçlerinin güvenliğini, TLS tarafındaki gerekliliklerle birlikte ele aldığımız PCI-DSS uyumlu e‑ticaret hosting rehberimiz bu mimariyi tamamlar nitelikte.

Senaryo 3: SaaS uygulaması, çoklu domain ve otomatik SSL

SaaS dünyasında kullanıcılar kendi alan adlarını sisteme eklemek istiyor (ör. panel.musteri.com). Bu durumda:

• Hem CDN’de hem origin’de çok sayıda dinamik SSL sertifikası yönetmeniz gerekir.
• Çoğu zaman DNS-01 challenge tabanlı ACME otomasyonu devreye girer.
• CDN, edge tarafında sertifikayı sonlandırırken; origin’de de wildcard veya otomatik üretilen sertifikalar çalışır.

DCHost olarak bu tür yapılarda ACME tabanlı otomasyon, origin şifrelemesi ve CDN ilişkisini daha önce SaaS’te özel alan adları ve otomatik SSL rehberimizde adım adım anlattık. Aynı prensipleri CDN arkasında Full (Strict) SSL ile birleştirmek mümkün.

DCHost altyapısında örnek kurulum akışları

1. DCHost paylaşımlı hosting + CDN

1. DCHost kontrol panelinizden alan adınıza Let’s Encrypt veya satın aldığınız SSL sertifikasını kurun.
2. https:// ile siteye doğrudan (CDN’siz) erişip her şeyin sorunsuz çalıştığını doğrulayın.
3. CDN panelinde domaini ekleyin, origin adresi olarak DCHost sunucu adınızı veya IP’nizi girin.
4. SSL modunu Full (Strict) olarak ayarlayın.
5. DNS kayıtlarınızı DCHost nameserver’larından CDN nameserver’larına yönlendirin veya sadece A/CNAME kayıtlarını CDN’e işaret edecek şekilde güncelleyin.
6. Gerekirse DCHost tarafında güvenlik duvarı kuralları ile CDN IP’lerini whitelist’leyin.

2. DCHost NVMe VPS + Nginx + CDN

1. VPS’inizde Nginx veya Apache’yi kurun; Let’s Encrypt ile otomatik yenilenen bir sertifika yapılandırın.
2. server_name / ServerName direktiflerinin CDN’in origin olarak bağlanacağı hostname ile uyumlu olduğundan emin olun.
3. Nginx’te HTTP→HTTPS yönlendirmelerini ve HSTS’i etkinleştirin.
4. CDN panelinde SSL modunu Full (Strict) yapın; origin hostname olarak aynı alan adını veya ayrı bir origin.ornek.com alt alanını kullanın.
5. iptables/ufw ile sadece CDN IP aralıklarından 443’e erişime izin verin; yönetim için DCHost VPN veya sabit yönetim IP’lerinizi de whitelist’e ekleyin.

3. DCHost dedicated/colocation + mTLS + CDN

Daha kurumsal yapılarda şu mimariyi öneriyoruz:

• Edge’te CDN, Full (Strict) + Authenticated Origin Pulls veya benzeri özellik aktif.
• DCHost veri merkezindeki dedicated/colocation sunucunuzda Nginx, CDN’in client sertifikasını doğrulayacak şekilde mTLS ile yapılandırılmış.
• Origin IP’leri dış dünyaya kapalı; sadece CDN IP blokları ve yönetim VPN’i erişebiliyor.

Böyle bir yapıda, sadece doğru sertifikaya sahip CDN düğümleri origin’e ulaşabildiği için, kimlik doğrulaması çok daha sağlam bir hale gelir.

İzleme, hata teşhisi ve bakım

CDN arkasında gerçek HTTPS kurmak kadar, bu yapıyı sürdürülebilir şekilde yönetmek de önemli. DCHost’ta sahada en sık karşılaştığımız problemler ve önerilerimiz şöyle:

1. Sertifika bitiş tarihlerini otomatik izleyin

Özellikle birden fazla alan adı ve ortam (test, staging, prod) söz konusu olduğunda, sertifika süre sonu unutmak çok kolay. Bu yüzden:

• Let’s Encrypt/ACME istemcilerinin otomatik yenileme loglarını ve cron job’larını düzenli kontrol edin.
• Harici monitoring ile sertifika bitiş tarihine göre uyarı kurun.

Onlarca alan adı yönetenler için, çoklu domain’de SSL sertifika süre sonu izleme ve otomasyon rehberimiz özellikle faydalı olacaktır.

2. Mixed content ve “Not Secure” uyarılarını çözmek

CDN sonrası en sık görülen sorulardan biri, bazı sayfalarda tarayıcının hala “güvenli değil” uyarısı göstermesi. Genelde sebep, sayfa içinde HTTP ile çağrılan görsel, JS veya CSS dosyalarıdır. Bu problemi çözmek için:

• Kaynak URL’lerini https:// veya // (protokol bağımsız) yapın.
• CDN önbelleğini temizleyerek yeni içeriklerin yayılmasını hızlandırın.

Bu konuya özel hazırladığımız SSL sonrası mixed content hatalarını düzeltme rehberi, CDN arkasında da birebir geçerli.

3. HTTP/2 ve HTTP/3 (QUIC) avantajlarından yararlanın

CDN’lerin büyük kısmı HTTP/2 ve HTTP/3 desteği sunuyor. Doğru ayarlarla:

• Daha iyi bağlantı çoklama (multiplexing)
• Daha az TCP/TLS el sıkışması
• Yüksek gecikmeli mobil bağlantılarda daha iyi kullanıcı deneyimi

elde etmek mümkün. Hem CDN hem origin tarafında HTTP/2/3 desteğinin performansa etkilerini, HTTP/2 ve HTTP/3 rehberimizde detaylıca anlattık.

Sonuç: Gerçek HTTPS, sadece kilit simgesinden ibaret değil

Tarayıcıda görünen kilit simgesi çoğu zaman içimizi rahatlatıyor, ama işin mutfağında neler olup bittiğini sorgulamazsak, CDN arkasında “yarım HTTPS” ile yolumuza devam edebiliyoruz. DCHost olarak sahada gördüğümüz en kritik fark şu: Flexible ya da zayıf Full SSL, sorun çıkana kadar fark edilmiyor; Full (Strict) + origin şifreleme ise uzun vadede projeyi hem güvenlik hem uyumluluk açısından koruyor.

Özetle şunları hayatınıza katmanızı öneriyoruz:

• Origin sunucuda modern TLS ayarları ve otomatik yenilenen bir SSL altyapısı kurun.
• CDN tarafında mutlaka Full (Strict) veya eşdeğer modu seçin.
• Mümkünse origin’i sadece CDN’den ve yönetim VPN’inizden erişilebilir hale getirin.
• Orta ve büyük projelerde mTLS, Authenticated Origin Pulls gibi gelişmiş yöntemleri değerlendirin.

Eğer mevcut kurulumunuzun gerçekten uçtan uca güvenli olup olmadığından emin değilseniz, DCHost ekibi olarak paylaşımlı hosting, NVMe VPS, dedicated sunucu veya colocation altyapılarımız üzerinde CDN ve HTTPS mimarinizi birlikte gözden geçirebiliriz. Projenizin ölçeği ne olursa olsun, performans kaybı yaşamadan gerçek HTTPS’e geçmeniz mümkün. Destek talebi açarak ya da satış ekibimizle iletişime geçerek, CDN arkasında güvenli ve sürdürülebilir bir HTTPS mimarisini birlikte tasarlayabiliriz.