Nginx'te HTTPS: SSL sertifikası kurulumu

• Sunucu ve Altyapı
• Güncelleme: 04.10.2026
• Yaklaşık 7 dk okuma

Yedi adımda HTTPS

1. 1

   Ön koşulları kontrol edin

   Let's Encrypt, sertifika vermeden önce alan adının gerçekten sizin denetiminizde olduğunu doğrular. En yaygın yöntemde doğrulama sunucusu, alan adınıza 80 numaralı bağlantı noktasından bağlanıp geçici bir dosya ister. Bu yüzden:

   • Alan adının (ve kullanıyorsanız www adının) DNS kaydı bu sunucuyu göstermelidir.
   • Güvenlik duvarında 80 ve 443 açık olmalıdır.
   • Nginx'te bu alan adı için server_name satırı doğru yazılmış bir server bloğu bulunmalıdır.

   Site dosyalarının yeri dağıtıma göre değişir: /etc/nginx/conf.d yaygındır, /etc/nginx/sites-available ise Debian/Ubuntu düzenidir.

   : Büyüt

2. 2

   Certbot ile sertifikayı alın

   Certbot'un kurulum komutu dağıtıma ve paket yöneticisine göre değişir; aşağıdaki ilk satır yalnızca bir örnektir. Kurulumdan sonra --nginx seçeneği, sertifikayı alır ve ilgili server bloğuna gerekli satırları kendisi ekler. Her -d bir alan adıdır.

   Bash

   # Kurulum dağıtıma göre değişir. Örnek (Debian/Ubuntu paket deposu):
   sudo apt install certbot python3-certbot-nginx
   
   # Sertifikayı al ve Nginx yapılandırmasına işle
   sudo certbot --nginx -d ornek.com -d www.ornek.com

   Certbot dosyaları /etc/letsencrypt/live/ornek.com/ altına yerleştirir. Nginx için iki dosya önemlidir:

   • fullchain.pem: sitenizin sertifikası ile ara sertifika birlikte. ssl_certificate bunu gösterir.
   • privkey.pem: özel anahtar. ssl_certificate_key bunu gösterir. Kimseyle paylaşılmaz, web kökünün altına konmaz.

   : Büyüt

3. 3

   HTTPS sunucu bloğunu ve yönlendirmeyi yazın

   Certbot yapılandırmayı kendisi düzenlediyse bu adımda yalnızca sonucu gözden geçirin. Elle yazıyorsanız iki blok gerekir: biri 80'de dinleyip her isteği kalıcı (301) olarak HTTPS'e yönlendirir, diğeri 443'te sertifikayla yanıt verir.

   Nginx

   # 80: her isteği HTTPS'e yönlendir
   server {
       listen 80;
       listen [::]:80;
       server_name ornek.com www.ornek.com;
   
       return 301 https://$host$request_uri;
   }
   
   # 443: sertifikayla yanıt ver
   server {
       listen 443 ssl;
       listen [::]:443 ssl;
       server_name ornek.com www.ornek.com;
   
       ssl_certificate     /etc/letsencrypt/live/ornek.com/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/ornek.com/privkey.pem;
   
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_session_cache shared:SSL:10m;
       ssl_session_timeout 1h;
   
       root /var/www/ornek.com/public;
       index index.html;
   }

   return 301 https://$host$request_uri; satırı, ziyaretçinin istediği adresi ve sorgu dizgisini koruyarak yönlendirir. ssl_protocols TLSv1.2 TLSv1.3; eski ve güvensiz protokol sürümlerini kapatır. HTTP/2'yi açan yönergenin yazımı Nginx sürümüne göre değişir; kendi sürümünüzün belgelerine bakın.

4. 4

   Sınayın ve yeniden yükleyin

   Önce sözdizimini sınayın; hata yoksa Nginx'i yeniden yükleyin. Yeniden yükleme (reload) açık bağlantıları kesmez. Ardından yönlendirmeyi ve sertifikayı dışarıdan kontrol edin.

   Bash

   # Sözdizimini sına, sonra yeniden yükle
   sudo nginx -t
   sudo systemctl reload nginx
   
   # HTTP adresi HTTPS'e yönleniyor mu?
   curl -sI http://ornek.com/ | grep -i -E "^(HTTP|location)"
   
   # HTTPS yanıtı ve başlıkları
   curl -sI https://ornek.com/
   
   # Sunulan sertifika zincirini göster
   openssl s_client -connect ornek.com:443 -servername ornek.com < /dev/null

   İlk curl çıktısında 301 ve https:// ile başlayan bir location satırı görmelisiniz. Tarayıcıda adres çubuğundaki bağlantı bilgisinden sertifikanın alan adını ve bitiş tarihini kontrol edin. Sorun çıkarsa aşağıdaki "Sık hatalar" bölümüne bakın.

   : Büyüt

5. 5

   Arka uca aktarıyorsanız: SSL sonlandırma

   Nginx çoğu kurulumda ters vekil (reverse proxy) olarak çalışır: isteği karşılar ve arkadaki uygulamaya iletir. Bu düzende şifreli bağlantı Nginx'te açılır; buna SSL sonlandırma (SSL termination) denir. Sertifika tek yerde durur, arka uç sunucusu (backend) şifreleme işiyle uğraşmaz.

   Nginx

   upstream uygulama {
       server 127.0.0.1:8080;
   }
   
   server {
       listen 443 ssl;
       server_name ornek.com www.ornek.com;
   
       ssl_certificate     /etc/letsencrypt/live/ornek.com/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/ornek.com/privkey.pem;
   
       location / {
           # Şifre burada çözüldü; arka uca düz HTTP gider
           proxy_pass http://uygulama;
   
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           # Ziyaretçinin kullandığı protokol: https
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

   Nginx ile arka uç arasındaki bağlantı için iki seçenek vardır:

   • Düz HTTP: arka uç aynı sunucudaysa (127.0.0.1) ya da güvenilir, kapalı bir iç ağdaysa yaygın tercihtir.
   • Yeniden şifreleme: trafik güvenmediğiniz bir ağdan geçiyorsa proxy_pass https://… kullanılır. Nginx arka ucun sertifikasını varsayılan olarak doğrulamaz; doğrulama için proxy_ssl_verify on; ve proxy_ssl_trusted_certificate gerekir.

   Arka uç isteği HTTP olarak gördüğü için ziyaretçinin HTTPS ile geldiğini bilemez. X-Forwarded-Proto başlığı bu bilgiyi taşır; uygulama güvenli çerez ve doğru adres üretmek için bu başlığa bakar. Uygulama bu başlığa yalnızca kendi vekil sunucunuzdan geldiğinde güvenmelidir. Ayrıntılar: Nginx ile ters vekil kurulumu.

   : Büyüt

6. 6

   HSTS'yi önce kısa süreyle açın

   HSTS (Strict-Transport-Security) başlığı tarayıcıya "bu siteye belirtilen süre boyunca yalnızca HTTPS ile bağlan" der. Güçlü bir korumadır ama geri alınması zordur: tarayıcı süre dolana kadar HTTP'ye dönmez. Bu yüzden önce birkaç dakikalık max-age ile deneyin.

   Nginx

   # Deneme: 5 dakika
   add_header Strict-Transport-Security "max-age=300" always;
   
   # Sorun yoksa yukarıdaki satırın yerine: 1 yıl
   # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

   Başlığı yalnızca 443'teki blokta tanımlayın. always sözcüğü başlığın hata yanıtlarında da gönderilmesini sağlar. includeSubDomains eklemeden önce tüm alt alan adlarınızın HTTPS ile çalıştığından emin olun. Diğer başlıklar için Güvenlik başlıkları ve HTTPS rehberine bakın.

7. 7

   Otomatik yenilemeyi doğrulayın

   Let's Encrypt sertifikaları kısa ömürlüdür; elle takip edilmez, otomatik yenilenir. Certbot paketleri genellikle bir zamanlayıcı (systemd timer ya da cron) kurar; bu görev düzenli çalışır ve yalnızca süresi yaklaşan sertifikaları yeniler. Kurulumun gerçekten çalıştığını deneme yenilemesiyle doğrulayın.

   Bash

   # Deneme yenilemesi: gerçek sertifikaya dokunmaz
   sudo certbot renew --dry-run
   
   # Sertifikalar ve bitiş tarihleri
   sudo certbot certificates
   
   # Zamanlayıcı kurulu mu? (systemd kullanan dağıtımlarda)
   systemctl list-timers | grep -i certbot
   
   # Yenilenen sertifikadan sonra Nginx'i yeniden yükle
   sudo certbot renew --deploy-hook "systemctl reload nginx"

   Nginx sertifika dosyasını yalnızca başlarken ve yeniden yüklenirken okur. Yenilemeden sonra yeniden yükleme yapılmazsa dosya yenilenmiş olsa bile ziyaretçilere eski sertifika sunulur. --deploy-hook ile verilen komut yalnızca bir sertifika gerçekten yenilendiğinde çalışır. Kalıcı olması için aynı komutu /etc/letsencrypt/renewal-hooks/deploy/ klasörüne çalıştırılabilir bir betik olarak da koyabilirsiniz; Certbot başarılı her yenilemeden sonra bu klasördeki betikleri çalıştırır.

   : Büyüt

Certbot yapılandırmaya dokunmasın istiyorsanız: webroot yöntemi

Nginx yapılandırmasını tümüyle kendiniz yönetmek istiyorsanız Certbot'a yalnızca sertifikayı aldırabilirsiniz. Bu yöntemde doğrulama dosyası sizin belirlediğiniz bir klasöre yazılır; 80'deki blokta bu yol yönlendirmenin dışında tutulur.

listen 80;
listen [::]:80;
server_name ornek.com www.ornek.com;

# Doğrulama dosyaları yönlendirilmez
location /.well-known/acme-challenge/ {
    root /var/www/letsencrypt;
}

location / {
    return 301 https://$host$request_uri;
}

# Yalnız sertifikayı al; Nginx yapılandırmasına dokunma
sudo certbot certonly --webroot -w /var/www/letsencrypt -d ornek.com -d www.ornek.com

Joker (wildcard) sertifikalar bu yöntemle alınamaz; DNS kaydı üzerinden doğrulama gerekir ve adımları DNS sağlayıcınıza göre değişir.

TLS ayarları: ne yazmalı, ne yazmamalı?

• Protokol: ssl_protocols TLSv1.2 TLSv1.3; güncel tarayıcılar için yeterlidir. TLS 1.3 için Nginx'in birlikte derlendiği OpenSSL kitaplığının bu sürümü desteklemesi gerekir.
• Tek yerde tanımlayın: aynı sunucuda birden çok site varsa protokol ayarını http bloğunda bir kez yazmak, siteler arasında tutarsızlığı önler.
• Oturum önbelleği: ssl_session_cache shared:SSL:10m; tekrar gelen ziyaretçilerde el sıkışmanın yeniden yapılmasını azaltır.
• Şifre takımları (cipher): internette dolaşan eski listeleri kopyalamayın. Öneriler zamanla değişir; güncel öneriler için sunucu yazılımınızın belgelerine bakın. Emin değilseniz varsayılanı bırakmak, eski bir listeyi yapıştırmaktan iyidir.

Sık hatalar ve çözümleri

Yönlendirme döngüsünde, Nginx'in önünde TLS'i sonlandıran bir hizmet varsa (ör. Cloudflare gibi bir CDN) ve sunucuya HTTP ile bağlanıyorsa, 80'deki blokta yönlendirmeyi öndeki hizmetin bildirdiği protokole bağlayabilirsiniz:

listen 80;
server_name ornek.com www.ornek.com;

# Yalnız ziyaretçi öndeki hizmete HTTP ile geldiyse yönlendir
if ($http_x_forwarded_proto = "http") {
    return 301 https://$host$request_uri;
}

root /var/www/ornek.com/public;

Bu başlığa yalnızca isteklerin gerçekten kendi vekilinizden geldiğinden eminseniz güvenin. Kalıcı çözüm, öndeki hizmet ile sunucunuz arasını da şifrelemektir. Aynı sorun, Nginx'in arkasındaki uygulama kendi içinde HTTPS'e yönlendirme yapıyor ama X-Forwarded-Proto başlığını dikkate almıyorsa da görülür.

Kontrol listesi

• ssl_certificate tam zinciri (fullchain.pem), ssl_certificate_key özel anahtarı gösteriyor.
• Özel anahtar yalnızca yetkili kullanıcı tarafından okunabiliyor; yedeklerde ve depolarda açıkta durmuyor.
• http:// adresi tek adımda, 301 ile https:// adresine gidiyor; döngü yok.
• Yalnızca TLS 1.2 ve 1.3 açık.
• Karışık içerik uyarısı yok.
• HSTS kısa süreyle denendi, sonra uzatıldı.
• Deneme yenilemesi başarılı; yenilemeden sonra Nginx yeniden yükleniyor.
• Sertifika bitiş tarihi ayrıca izleniyor: yedekleme ve izleme.

Sık sorulan sorular

İlgili rehberler

• Güvenlik başlıkları ve HTTPSHSTS, CSP, X-Content-Type-Options, Referrer-Policy ve Permissions-Policy; .htaccess örneğiyle.
• SSL nedir? Web sitesinde ve e-postada SSL ne işe yarar?Web sitesindeki https ve kilit simgesi ile e-posta programındaki SSL ayarı neyi korur, farkları nedir.
• Nginx ile reverse proxy (ters vekil) kurulumuserver bloğu, proxy_pass, iletilecek başlıklar, WebSocket, zaman aşımları ve gerçek IP ayarıyla adım adım kurulum.
• Nginx güvenlik ayarları: oran sınırlama, başlıklar, erişim kısıtlarıNginx'te oran sınırlama, güvenlik başlıkları, gizli dosya ve yönetim yolu kısıtları ile istek sınırları.