Nginx'te SSL Yapılandırması ve A+ Ayarları

Bir siteyi HTTPS'e taşımak, sunucuya bir sertifika yükleyip 443 portunu açmaktan ibaret değildir. Sertifikanın geçerli olması, tarayıcının yeşil kilidi göstermesi güzel bir başlangıçtır; ama SSL Labs gibi bir test aracına sitenizin adresini yazdığınızda karşınıza B ya da C notu çıkıyorsa, kullandığınız protokoller ve şifreleme algoritmaları modern güvenlik standartlarının gerisinde kalmış demektir. Eski TLS sürümleri, zayıf cipher'lar ve eksik HTTP başlıkları; sertifikanız kusursuz olsa bile bağlantınızı ortadaki adam (man-in-the-middle) saldırılarına, downgrade saldırılarına ve protokol seviyesindeki bilinen zafiyetlere açık bırakır.

Bu rehberde, Nginx üzerinde bir SSL yapılandırmasını satır satır ele alacağız. ssl_certificate, ssl_protocols, ssl_ciphers ve ssl_prefer_server_ciphers direktiflerinin ne işe yaradığını; HSTS başlığını, OCSP stapling'i ve HTTP/2'yi neden ve nasıl eklemeniz gerektiğini pratik örneklerle göstereceğiz. Sonunda kopyalayıp uyarlayabileceğiniz eksiksiz bir server bloğu ve yaptığınız işi SSL Labs ile doğrulama adımlarını bulacaksınız. Amacımız sadece "çalışan" değil, denetimden A+ notuyla geçen bir konfigürasyon çıkarmak.

SSL Yapılandırmasına Başlamadan Önce#

Bu rehberdeki direktiflerin çalışması için elinizde geçerli bir sertifika ve özel anahtar dosyası bulunmalı. Eğer henüz bir sertifikanız yoksa, ücretsiz ve otomatik yenilenen bir sertifika için Let's Encrypt ücretsiz SSL rehberimizdeki adımları izleyerek Certbot ile birkaç dakikada sertifika üretebilirsiniz. Nginx'i henüz kurmadıysanız, Ubuntu üzerinde Nginx kurulumu yazımız temiz bir başlangıç noktası sunar.

Certbot ile üretilen sertifikalar tipik olarak şu dizinde tutulur:

/etc/letsencrypt/live/ornekalanadi.com/
├── fullchain.pem   # sunucu sertifikası + ara sertifikalar (chain)
├── privkey.pem     # özel anahtar (kimseyle paylaşılmaz)
├── cert.pem        # yalnız sunucu sertifikası
└── chain.pem       # yalnız ara sertifikalar

Nginx için doğru dosya çifti fullchain.pem ve privkey.pem'dir. cert.pem tek başına yeterli değildir çünkü ara sertifika zincirini içermez; zinciri eksik gönderirseniz bazı tarayıcı ve mobil cihazlar sertifikanızı "güvenilmez" olarak işaretler. Yapılandırmaya başlamadan önce özel anahtar dosyanızın izinlerinin sıkı olduğundan emin olun:

sudo chmod 600 /etc/letsencrypt/live/ornekalanadi.com/privkey.pem
sudo chown root:root /etc/letsencrypt/live/ornekalanadi.com/privkey.pem

Özel anahtar dosyasının başkaları tarafından okunabilir olması, sertifikanın tümüyle ele geçirilmesi anlamına gelir. Bu dosyayı asla yedek amacıyla web erişilebilir bir dizine kopyalamayın.

ssl_certificate ve ssl_certificate_key Direktifleri#

Her SSL yapılandırmasının kalbi bu iki satırdır. ssl_certificate, sunucu sertifikanızı ve ara zincirini içeren dosyanın yolunu; ssl_certificate_key ise özel anahtarın yolunu belirtir:

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

Buradaki en yaygın hata, fullchain.pem yerine cert.pem göstermektir. Kendi bilgisayarınızın tarayıcısı işletim sistemine yüklü ara sertifikaları zaten bildiği için siteyi sorunsuz açar; oysa bu ara sertifikaları tanımayan bir Android telefon ya da bir API istemcisi "zincir tamamlanamadı" hatası verir. fullchain.pem kullandığınızda sunucu, zinciri istemciye kendisi ilettiği için bu sorun ortadan kalkar.

Nginx aynı server bloğunda birden fazla ssl_certificate satırı tanımlamanıza izin verir. Bu, aynı anda hem RSA hem de ECDSA sertifikası sunmak istediğinizde işe yarar: modern istemciler daha hızlı ve hafif olan ECDSA'yı tercih ederken, çok eski istemciler RSA'ya düşer.

# ECDSA (modern, hızlı) — önce denenir
ssl_certificate     /etc/ssl/ecdsa/fullchain.pem;
ssl_certificate_key /etc/ssl/ecdsa/privkey.pem;

# RSA (geniş uyumluluk) — yedek
ssl_certificate     /etc/ssl/rsa/fullchain.pem;
ssl_certificate_key /etc/ssl/rsa/privkey.pem;

Çoğu site için tek bir ECDSA (ya da RSA 2048-bit) sertifika fazlasıyla yeterlidir; çift sertifika kurgusu yüksek trafikli, uyumluluğun kritik olduğu ortamlar için düşünülür.

ssl_protocols ile Protokol Sürümünü Kilitlemek#

ssl_protocols, sunucunuzun hangi TLS sürümleriyle bağlantı kurmayı kabul edeceğini belirler. Bu satır A+ notunun en belirleyici parçalarından biridir; çünkü SSL Labs, eski ve kırılmış protokolleri destekleyen sunuculara ciddi puan cezası verir.

ssl_protocols TLSv1.2 TLSv1.3;

Bugün için doğru cevap yalnızca TLSv1.2 ve TLSv1.3'tür. SSLv3, TLSv1.0 ve TLSv1.1 sürümlerinin hepsi ya tümüyle kırılmıştır (POODLE, BEAST gibi saldırılar) ya da modern cipher desteğinden yoksundur. PCI-DSS gibi ödeme güvenliği standartları da TLSv1.0/1.1'i açıkça yasaklar. Aşağıdaki tablo hangi sürümün neden dışarıda bırakıldığını özetliyor:

TLSv1.3, el sıkışmayı (handshake) tek gidiş-dönüşe indirir ve zayıf cipher seçeneklerini protokol seviyesinde tamamen kaldırır. Sunucunuzdaki Nginx ve OpenSSL sürümleri destekliyorsa TLSv1.3'ü mutlaka açık tutun; desteklemeyen çok eski istemciler otomatik olarak TLSv1.2'ye düşer, yani kimseyi dışarıda bırakmazsınız.

ssl_ciphers ve ssl_prefer_server_ciphers#

Protokolü seçtikten sonra sıra, o protokol içinde kullanılacak şifreleme algoritma setine (cipher suite) gelir. ssl_ciphers, TLSv1.2 için kabul edeceğiniz cipher listesini tanımlar. Aşağıdaki liste yalnızca ileri gizlilik (forward secrecy) sağlayan, AEAD modundaki güçlü algoritmaları içerir:

ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers on;

Bu listedeki her cipher ECDHE ile başlar; bu, her oturum için geçici (ephemeral) bir anahtar üretilmesini sağlayan Diffie-Hellman değişkenidir ve forward secrecy demektir. Yani sunucunuzun özel anahtarı bir gün ele geçirilse bile, geçmişte kaydedilmiş trafik geriye dönük olarak çözülemez. GCM ve POLY1305 ise AEAD modlarıdır; hem şifreleme hem bütünlük doğrulamasını tek adımda yapar ve eski CBC modundaki padding zafiyetlerini barındırmaz. CHACHA20, donanım AES hızlandırması olmayan mobil cihazlarda AES'ten daha hızlıdır.

ssl_prefer_server_ciphers on; direktifi, cipher seçiminde son sözü sunucuya verir. Kapalı olduğunda istemci kendi tercih sırasını dayatabilir ve gizlice daha zayıf bir cipher seçtirebilir; açık olduğunda ise sunucu kendi güvenli sıralamasını uygular. Bir önemli ayrıntı: TLSv1.3'te cipher pazarlığının mantığı değiştiği için bu direktif TLSv1.3 bağlantılarını etkilemez; TLSv1.3'ün cipher seti zaten protokol tarafından güvenli olacak şekilde sabitlenmiştir. Dolayısıyla ssl_ciphers satırınız pratikte yalnızca TLSv1.2 bağlantıları için geçerlidir.

Aşağıdaki tablo bu iki grubun rollerini netleştiriyor:

HSTS ile HTTPS'i Zorunlu Kılmak#

Sertifikanız kusursuz olsa bile, kullanıcı adres çubuğuna http:// yazarak ilk isteğini şifresiz gönderirse, bu ilk istek bir saldırganın sitenizi taklit etmesine (SSL stripping) fırsat verir. HTTP Strict Transport Security (HSTS) başlığı, tarayıcıya "bundan sonra bu alan adına yalnızca HTTPS ile bağlan" talimatı verir; tarayıcı bu talimatı hatırlar ve http:// isteklerini daha ağa çıkmadan HTTPS'e çevirir.

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

Parametreleri tek tek okuyalım: max-age=63072000 tarayıcının bu kuralı iki yıl boyunca hatırlamasını söyler. includeSubDomains kuralı tüm alt alan adlarına (blog., panel. vb.) genişletir; bunu eklemeden önce tüm alt alan adlarınızın HTTPS sunduğundan emin olun, aksi halde HTTPS'i olmayan bir alt alanı erişilemez hale getirebilirsiniz. preload, alan adınızı tarayıcıların yerleşik HSTS listesine dahil etme talebidir; bu listeye girdiğinizde ilk ziyaret dahil hiçbir istek şifresiz gönderilmez.

always parametresi kritik ama sık atlanır: onsuz Nginx bu başlığı yalnızca 2xx/3xx yanıtlarına ekler, 4xx ve 5xx hata sayfalarında eklemez. always ile başlık her yanıt kodunda gönderilir. Bir uyarı: preload listesine bir kez girmek kolay, çıkmak aylar sürer. Sitenizin HTTPS altyapısının kalıcı olduğundan emin olmadan preload anahtarını eklemeyin. Kapsamlı bir başlık güvenliği için HSTS'i bir WAF katmanıyla birlikte düşünmek, uygulama seviyesindeki saldırılara karşı ek koruma sağlar.

OCSP Stapling ile Doğrulamayı Hızlandırmak#

Bir tarayıcı sertifikanızı gördüğünde, o sertifikanın iptal edilip edilmediğini (çalınmış ya da yanlış üretilmiş olabilir) sertifika sağlayıcının OCSP sunucusuna sorarak öğrenmek ister. Bu sorgu istemci tarafında yapıldığında hem bağlantıyı yavaşlatır hem de kullanıcının hangi siteyi ziyaret ettiğini sertifika sağlayıcıya sızdırır. OCSP stapling, bu doğrulamayı sunucunuza taşır: sunucunuz iptal durumu yanıtını sağlayıcıdan önceden alır, imzalı biçimde önbelleğe koyar ve el sıkışma sırasında sertifikayla birlikte istemciye "iliştirir" (staple).

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/ornekalanadi.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

ssl_stapling on; özelliği etkinleştirir. ssl_stapling_verify on;, sunucunuzun sağlayıcıdan aldığı OCSP yanıtının imzasını doğrulamasını sağlar; bu doğrulama için ara sertifika zincirini ssl_trusted_certificate ile göstermeniz gerekir (Let's Encrypt için chain.pem). resolver satırı ise önemlidir: Nginx OCSP sunucusunun adresini çözebilmek için bir DNS çözümleyiciye ihtiyaç duyar; bunu tanımlamazsanız stapling sessizce çalışmaz. Yaptığınız stapling'in gerçekten aktif olduğunu şu komutla doğrulayabilirsiniz:

echo QUIT | openssl s_client -connect ornekalanadi.com:443 \
  -servername ornekalanadi.com -status 2>/dev/null | grep -A 17 "OCSP Response Status"

Çıktıda OCSP Response Status: successful satırını görüyorsanız stapling düzgün çalışıyor demektir. Not: Let's Encrypt gibi bazı sağlayıcılar OCSP altyapısını aşamalı olarak kaldırmaya başladı; sertifika sağlayıcınız OCSP yerine CRL tabanlı iptal kullanıyorsa bu blok bir işe yaramaz ama zararı da olmaz.

HTTP/2 ile Performansı Artırmak#

HTTP/2, tek bir TLS bağlantısı üzerinden birden çok isteği paralel (multiplexing) taşıyabilen, başlıkları sıkıştıran ve tarayıcı-sunucu iletişimini belirgin biçimde hızlandıran bir protokoldür. Pratikte yalnızca HTTPS üzerinden kullanıldığı için SSL yapılandırmasının doğal bir parçasıdır. Yeni Nginx sürümlerinde (1.25.1 ve sonrası) ayrı bir http2 direktifiyle açılır:

listen 443 ssl;
listen [::]:443 ssl;
http2 on;

Daha eski Nginx sürümlerinde ise HTTP/2, listen satırının bir parametresi olarak yazılırdı:

# Nginx 1.25.1 öncesi sözdizimi
listen 443 ssl http2;
listen [::]:443 ssl http2;

Sürümünüzü nginx -v ile kontrol edip doğru sözdizimini kullanın. HTTP/2, SSL için ek bir güvenlik ayarı gerektirmez; sertifikanız ve protokol/cipher yapılandırmanız aynı kalır, yalnızca aktarım katmanı hızlanır. Statik dosyaların (resim, CSS, JS) çok olduğu sitelerde sayfa yükleme süresine gözle görülür katkı sağlar. HTTP/2'nin bir sonraki adımı olan HTTP/3'ü (QUIC) de değerlendirebilirsiniz, ancak QUIC UDP tabanlı olduğu için güvenlik duvarı ve altyapı tarafında ek yapılandırma gerektirir; çoğu site için önce HTTP/2'yi doğru kurmak yeterlidir.

Eksiksiz Örnek server Bloğu#

Şimdiye kadar ele aldığımız her parçayı tek bir çalışır yapılandırmada birleştirelim. Aşağıdaki blok, http:// isteklerini kalıcı olarak HTTPS'e yönlendiren bir sunucu ve tüm güvenlik direktiflerini içeren asıl HTTPS sunucusundan oluşur. ornekalanadi.com yerine kendi alan adınızı yazmanız yeterli:

# 1) HTTP -> HTTPS kalıcı yönlendirme
server {
    listen 80;
    listen [::]:80;
    server_name ornekalanadi.com www.ornekalanadi.com;
    return 301 https://$host$request_uri;
}

# 2) Asıl HTTPS sunucusu
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name ornekalanadi.com www.ornekalanadi.com;

    # Sertifika
    ssl_certificate     /etc/letsencrypt/live/ornekalanadi.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ornekalanadi.com/privkey.pem;

    # Protokol ve cipher
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers on;

    # Oturum önbelleği (performans)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/ornekalanadi.com/chain.pem;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # HSTS (her yanıtta)
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

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

    location / {
        try_files $uri $uri/ =404;
    }
}

Buradaki ssl_session_cache ve ssl_session_timeout satırları, tekrar eden bağlantılarda TLS el sıkışmasını hızlandırmak için oturumları paylaşımlı bir önbellekte tutar; ssl_session_tickets off; ise oturum biletlerini kapatarak forward secrecy'yi güçlendirir. Yapılandırmayı kaydettikten sonra sözdizimini test edip Nginx'i yeniden yükleyin:

sudo nginx -t
sudo systemctl reload nginx

nginx -t çıktısı syntax is ok ve test is successful diyorsa güvenle reload edebilirsiniz. reload, restart'tan farklı olarak mevcut bağlantıları koparmadan yeni yapılandırmayı devreye alır. WordPress çalıştırıyorsanız yönlendirme döngülerini önlemek için WordPress bakım tarafında site adresini de https:// olarak güncellemeyi unutmayın.

SSL Labs ile Doğrulama#

Yapılandırmayı devreye aldıktan sonra işi tahmine bırakmayın; Qualys SSL Labs'ın ücretsiz test aracına (ssllabs.com/ssltest) alan adınızı yazın. Araç, dışarıdan gerçek bir istemci gibi bağlanır ve sunucunuzun desteklediği protokolleri, cipher'ları, sertifika zincirini ve başlıkları tek tek denetleyerek bir not verir. Bu rehberdeki yapılandırmayla A+ almanız gerekir. Testin tamamlanması bir iki dakika sürer ve sonuç önbelleğe alınır; değişiklik sonrası tekrar test ederken "Clear cache" seçeneğini işaretleyin.

Notunuz beklediğinizden düşük çıktıysa, aşağıdaki hızlı kontrol listesi çoğu sorunu çözer:

SSL Labs dışında, komut satırından hızlı bir kontrol için nmap --script ssl-enum-ciphers -p 443 ornekalanadi.com komutu da desteklenen tüm cipher'ları güç dereceleriyle listeler. Yerel geliştirme ya da toplu tarama için testssl.sh betiği de son derece detaylı raporlar üretir. Yeni bir sunucuyu canlıya almadan önce mutlaka bu doğrulama adımını çalıştırın; A+ notu, hem kullanıcı güveni hem de arama motorları için somut bir kalite göstergesidir.

Sıkça Sorulan Sorular#

ssl_ciphers satırı neden TLSv1.3'ü etkilemiyor?#

TLSv1.3, protokol tasarımı gereği cipher pazarlığını kökten değiştirdi ve yalnızca güvenli sayılan sabit bir cipher setiyle çalışır. Nginx'in ssl_ciphers direktifi TLSv1.2 ve öncesi için kullanılan sözdizimini takip ettiğinden, bu satırdaki liste yalnızca TLSv1.2 bağlantılarına uygulanır. TLSv1.3 tarafında ayrıca bir cipher tanımlamanıza gerek yoktur; protokol zaten zayıf seçenekleri barındırmaz.

HSTS başlığını eklerken includeSubDomains riskli mi?#

Riskli olabilir, çünkü bu parametre kuralı tüm alt alan adlarınıza genişletir. Eğer HTTPS sunmayan bir alt alan adınız varsa (örneğin yalnız HTTP ile çalışan eski bir servis), tarayıcı ona da HTTPS ile bağlanmaya çalışır ve alt alan erişilemez hale gelir. Bu yüzden includeSubDomains eklemeden önce bütün alt alan adlarınızın geçerli sertifikayla HTTPS sunduğundan emin olun; emin değilseniz önce parametresiz başlayın.

OCSP stapling çalışmıyor, sorun ne olabilir?#

En sık karşılaşılan neden resolver satırının eksik olmasıdır; Nginx OCSP sunucusunun adresini çözemediğinde stapling sessizce devre dışı kalır. İkinci sık neden, ssl_trusted_certificate olarak yanlış dosyanın gösterilmesidir; Let's Encrypt için burada chain.pem kullanılmalıdır. Ayrıca bazı sertifika sağlayıcıları OCSP hizmetini kaldırdığı için stapling hiç aktifleşmeyebilir; bunu openssl s_client -status komutuyla teyit edebilirsiniz.

A+ notu için mutlaka HTTP/2 gerekiyor mu?#

Hayır, SSL Labs notu esas olarak protokol, cipher, sertifika ve HSTS'i değerlendirir; HTTP/2 doğrudan nota puan katmaz. Yine de HTTP/2'yi açmak sayfa yükleme performansını belirgin biçimde artırdığı için modern bir kurulumda pratikte her zaman etkinleştirilir. Yani A+ için zorunlu olmasa da, kullanıcı deneyimi için kesinlikle önerilir.

ssl_prefer_server_ciphers ayarını neden açık tutmalıyım?#

Bu ayar kapalıyken cipher seçiminde son sözü istemci söyler ve teorik olarak listedeki daha zayıf bir cipher'ı seçtirebilir. on yaptığınızda seçim önceliği sunucuya geçer, böylece kendi güvenli sıralamanız uygulanır ve downgrade riskleri azalır. TLSv1.2 için önemli bir korumadır; TLSv1.3 bağlantılarında ise cipher seçimi zaten protokolce güvenli olduğu için bu ayarın etkisi yoktur.

Sertifikamı yeniledikten sonra Nginx'i yeniden başlatmam gerekir mi?#

Certbot çoğu kurulumda yenileme sonrası Nginx'i otomatik olarak yeniden yükler (reload), bu yüzden genellikle elle bir işlem yapmanız gerekmez. Yine de manuel yenileme yaptıysanız sudo systemctl reload nginx komutuyla yeni sertifikayı devreye almalısınız. reload mevcut bağlantıları koparmadan yapılandırmayı tazelediği için kesintisiz çalışır; tam restart gerekmez.

Kapanış#

Nginx'te A+ değerinde bir SSL yapılandırması, tek bir sihirli satırdan değil; doğru sertifika zincirinden, modern protokol ve cipher seçiminden, HSTS başlığından, OCSP stapling'den ve HTTP/2'den oluşan bir bütünden gelir. Bu rehberdeki server bloğunu kendi alan adınıza uyarlayıp nginx -t ile test ettikten sonra SSL Labs'ta sonucu doğrulayın; birkaç dakikanızı alan bu adım, sitenizin güvenlik duruşunu somut biçimde yukarı taşır.

Bu tür sunucu tarafı yapılandırmalarla uğraşmak yerine kontrolü uzmanlara bırakmak isterseniz, Clou.TR olarak SSL'in hazır geldiği web hosting ve WordPress hosting paketlerimizle, tam kök erişimi sunan VDS sunucularımızla ve dilerseniz baştan sona bizim yönettiğimiz sunucu yönetimi hizmetimizle yanınızdayız. Ücretsiz sertifikanın ötesine geçmek isteyenler için SSL çözümlerimize ve saldırılara karşı ek koruma için WAF ve DDoS koruma hizmetlerimize göz atabilir; ihtiyacınıza en uygun paketi seçmek için ücretsiz araçlarımızı kullanabilirsiniz.