NGINX’e SSL Sertifikası Nasıl Yüklenir

Bu kılavuz size NGINX üzerine bir SSL/TLS sertifikasının nasıl kurulacağını gösterir. Çoğu kişinin zorlandığı kısmı ele alır: NGINX’in gerektirdiği doğru sertifika zincirini (“fullchain”) oluşturmak, doğru direktifleri doğru dosyalara yönlendirmek, yeniden yüklemeden önce yapılandırmayı test etmek ve her ziyaretçinin sitenizin güvenli sürümüne ulaşması için düzgün bir HTTP’den HTTPS’e yönlendirme eklemek.

NGINX için CSR kodu oluşturma

CSR’nizi zaten oluşturduysanız ve verilen sertifika dosyaları elinizdeyse, NGINX üzerine SSL sertifikası kurma bölümüne geçebilirsiniz.

Bir Sertifika Yetkilisi sertifikanızı verebilmeden önce bir CSR (Sertifika İmzalama Talebi) göndermeniz gerekir: alan adı bilgilerinizi ve bir açık anahtarı içeren, sunucuda tutulan bir özel anahtarla eşleştirilmiş küçük bir metin bloğu. İki seçeneğiniz var:

• CSR Oluşturucu aracımızla CSR’yi otomatik olarak oluşturun. Araç, hem CSR’yi hem de eşleşen özel anahtarı döndürür; bunları daha sonra sunucuya yüklersiniz.
• NGINX üzerinde CSR oluşturma hakkındaki eğitimimizi takip ederek OpenSSL ile CSR’yi doğrudan sunucuda oluşturun. Özel anahtar sunucuda kalır.

Oluşan .csr dosyasını herhangi bir metin düzenleyicide açın; içindeki metin bloğu (—–BEGIN CERTIFICATE REQUEST—– ve —–END CERTIFICATE REQUEST—– satırları dahil) satın alma işlemi sırasında SSL başvuru formuna yapıştıracağınız kısımdır. Göndermeden önce CSR içeriğini doğrulamak isterseniz, CSR kod çözücü aracımıza yapıştırın.

NGINX üzerine SSL sertifikası kurma

CA sertifikayı verdiğinde, genellikle şunları alırsınız:

• Birincil (sunucu) sertifikanız, genellikle alan adınızın adını taşıyan bir .crt dosyası.
• Ara (intermediate) (ve bazen kök) sertifikalar, ayrı .crt dosyaları olarak veya tek bir .ca-bundle dosyasında paketlenmiş olarak.
• CSR’nizle birlikte oluşturulan özel anahtar (bir .key dosyası).

NGINX, sunucu sertifikası ile ara sertifika zincirinin tek bir dosyada (“fullchain”) birleştirilmesini ve ssl_certificate ile bu dosyaya işaret edilmesini gerektirir; özel anahtara ise ssl_certificate_key ile ayrıca işaret edilir. Zinciri atlamak, en yaygın kurulum hatasıdır: sertifika masaüstü tarayıcısında iyi görünür, ancak Android’de, API istemcilerinde ve SSL Checker aracımız gibi araçlarda başarısız olur.

Adım 1: Sertifikaları tek bir dosyada birleştirin

Birleştirilmiş dosyadaki sertifikaların sırası önemlidir. Önce sunucu sertifikanız gelir, ardından yaprak sertifikayı veren CA’dan yukarıya doğru her ara sertifika gelir, kök sertifika ise en sona konur (veya atlanır, çünkü tarayıcılar zaten yerleşik depolarındaki kök sertifikalara güvenir):

• Alan adınız için birincil sertifikanız.
• Ara sertifika(lar).
• Kök sertifika (isteğe bağlı).

Fullchain dosyasını bir metin düzenleyicide elle oluşturabilirsiniz (her PEM bloğunu sırayla yapıştırarak) veya tek bir cat komutuyla. Ayrı ara ve kök dosyaları aldıysanız şunu çalıştırın:

cat your_domain.crt intermediate.crt root.crt > ssl-bundle.crt

Ara ve kök sertifikalar zaten tek bir .ca-bundle dosyasındaysa şunu çalıştırın:

cat example_com.crt example_com.ca-bundle > ssl-bundle.crt

Dosya adlarını kendi dosyalarınızla değiştirin. Birleştirilmiş dosyayı (ve henüz orada değilse özel anahtarı) sunucunuzdaki SSL dizinine taşıyın, örneğin /etc/ssl/ veya /etc/nginx/ssl/. Anahtar dosyasının yalnızca root tarafından okunabilir olmasını sağlayın:

sudo chmod 600 /etc/ssl/your_domain.key
sudo chown root:root /etc/ssl/your_domain.key

Adım 2: NGINX yapılandırma dosyasını düzenleyin

Siteniz için NGINX yapılandırma dosyasını açın. Debian ve Ubuntu’da bu dosya /etc/nginx/sites-available/ içinde bulunur (ve sites-enabled/ içinde bir sembolik bağlantısı vardır); RHEL, CentOS, AlmaLinux ve Rocky Linux’ta ise /etc/nginx/conf.d/ içinde bulunur. 443 numaralı portu dinleyen server bloğunu ekleyin veya düzenleyin, böylece fullchain dosyasına ve özel anahtara işaret etsin:

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/ssl-bundle.crt;
    ssl_certificate_key /etc/ssl/your_domain.key;

    # Modern TLS only
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    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_session_timeout 1d;
    ssl_session_cache shared:NginxSSL:10m;
    ssl_session_tickets off;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    root /var/www/example.com;
    index index.html;

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

Yukarıdaki direktifler hakkında birkaç not:

• listen 443 ssl; 443 portunda TLS’yi etkinleştirir. Eski ssl on; direktifi NGINX 1.25’te kaldırılmıştır ve modern yapılandırmalarda görünmemelidir.
• http2 on; HTTP/2’yi kendi başına bir direktif olarak açar (NGINX 1.25.1 ve sonrası). Eski yapılandırmalarda listen 443 ssl http2; kullanılırdı; bu hâlâ çalışır ama kullanımdan kaldırılmıştır.
• ssl_protocols TLSv1.2 TLSv1.3; eski ve güvensiz TLS 1.0 ve 1.1’i devre dışı bırakır. NGINX 1.27.3’ten itibaren, direktifi atlarsanız da varsayılan budur; ancak bunu açıkça belirtmek, denetime uygun ve daha net bir seçimdir.
• Şifreleme listesi Mozilla’nın “intermediate” profiliyle eşleşir ve tüm güncel istemcilerde çalışır. Yalnızca TLS 1.3 istemcilere ihtiyacınız varsa, ssl_ciphers satırını tamamen kaldırabilirsiniz.

Adım 3: HTTP’yi HTTPS’e yönlendirin

80 portunda her isteği kalıcı olarak HTTPS’e yönlendiren ayrı bir server bloğu ekleyin; böylece düz HTTP üzerinden gelen ziyaretçiler güvenli URL’ye yönlendirilir:

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

return 301 kullanmak, regex tabanlı bir rewrite kuralından daha hızlı ve daha güvenlidir; ayrıca NGINX’in kendisinin de önerdiği yöntemdir.

Adım 4: Yapılandırmayı test edin ve NGINX’i yeniden yükleyin

Yeniden yüklemeden önce yapılandırmayı her zaman doğrulayın, böylece bir yazım hatası hizmeti çevrimdışı bırakamaz:

sudo nginx -t

syntax is ok ve test is successful mesajlarını görmelisiniz. Bir hata bildirilirse, mesaj dosya ve satır numarasını içerir; hatayı düzeltip testi yeniden çalıştırın. Test başarılı olduğunda, mevcut bağlantıları kesmeden yeni yapılandırmayı uygulaması için NGINX’i yeniden yükleyin:

sudo systemctl reload nginx

systemd olmayan sistemlerde, NGINX’in kendi yeniden yükleme sinyalini kullanın:

sudo nginx -s reload

restart yerine reload kullanmayı tercih edin: bir yeniden yükleme, aktif bağlantıları kapatmadan yapılandırmayı yeniden okur; bir yeniden başlatma ise onları düşürür.

Adım 5 (isteğe bağlı): OCSP stapling’i etkinleştirin

OCSP stapling, NGINX’in sertifikayla birlikte güncel, imzalı bir iptal durumu sunmasını sağlar; böylece istemcilerin her el sıkışmada CA ile iletişime geçmesine gerek kalmaz. HTTPS server bloğunuzun içine şunu ekleyin:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/ssl-bundle.crt;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

sudo systemctl reload nginx ile NGINX’i tekrar yeniden yükleyin. Stapling küçük ama değerli bir güçlendirme adımıdır ve çoğu modern sertifika bunu doğrudan destekler.

Kurulumu doğrulama

Sitenizi bir tarayıcıda https:// üzerinden açın ve kilit simgesinin kapalı olduğunu ve sertifikanın alan adınızla eşleştiğini kontrol edin. Ardından sertifika, zincir ve sunucunuzun sunduğu protokoller ve şifreler hakkında anında bir rapor için SSL Checker aracımızla daha derin bir tarama yapın. Orada alınan yeşil bir sonuç, mobil ve API istemcileri dahil olmak üzere tüm büyük platformlardaki istemcilerin sertifikaya güveneceği anlamına gelir.

Sıkça Sorulan Sorular