VPS’te SSL Sertifikası Kurulumu: Let’s Encrypt Rehberi

VPS’te SSL sertifikası kurmadan önce bilmeniz gerekenler

Bir sitenin adres çubuğunda kilit simgesini görmek ziyaretçi açısından güven vericidir. Sunucu yöneticisi açısından ise DNS, web sunucusu ve otomatik yenileme zincirinin çalıştığı anlamına gelir. VPS SSL sertifikası kurulumu yalnızca bir dosyayı sunucuya kopyalamaktan ibaret değil. Alan adının doğru sunucuya bakması, 80 ve 443 numaralı portların erişilebilir olması, web sunucusunun doğru yapılandırılması ve sertifikanın süresi dolmadan yenilenmesi gerekir.

Let’s Encrypt bunu ücretsiz ve otomatikleştirilebilir biçimde sağlıyor. Ben çoğu Linux VPS’te Nginx ile birlikte Certbot kullanıyorum. Apache kullanan sunucularda da yol benzer; komutları çalıştırmadan önce hangi web sunucusunun gerçekten aktif olduğunu kontrol etmek gerekiyor. Yanlış makinede çalıştırılan doğru komut da işe yaramaz.

Alan adı ve VPS hazırlığı

Kuruluma geçmeden önce alan adınızın DNS kayıtlarını kontrol edin. example.com ve gerekiyorsa www.example.com kayıtları VPS’in public IP adresine işaret etmeli. IPv6 kullanıyorsanız AAAA kaydını da kontrol edin. Sunucuda çalışan bir IPv6 servisi yokken DNS’te yanlış bir AAAA kaydı bulunması, doğrulama isteklerinin beklenmedik bir adrese gitmesine neden olabilir.

Panelden bakmak yerine terminalde ilk kontrolüm genellikle şöyledir:

dig +short example.com A
dig +short example.com AAAA
dig +short www.example.com A

İlk komut VPS’in IPv4 adresini, ikinci komut varsa IPv6 adresini göstermeli. dig +short boş dönüyorsa DNS değişikliği henüz yayılmamış olabilir veya kayıt eksiktir. DNS TTL değerine bağlı olarak beklemek gerekebilir; Certbot’u tekrar tekrar çalıştırmak bu süreci hızlandırmaz.

Web sunucusunun dinlediği portları da kontrol edin:

sudo ss -tulpn | grep -E ':80|:443'
sudo ufw status verbose

Let’s Encrypt’in HTTP doğrulaması için dışarıdan TCP 80 portuna ulaşabilmesi gerekir. HTTPS trafiği için 443 de açık olmalı. UFW kullanıyorsanız şu profil iki portu da açar:

sudo ufw allow 'Nginx Full'
sudo ufw status

Bu profil hem 80 hem 443 portunu açar. nftables, sağlayıcı güvenlik grubu veya harici firewall kullanıyorsanız aynı izinleri o katmanlarda da tanımlamanız gerekir. VPS’te bir portu açmak, sağlayıcının ağ güvenlik grubunda kapalı duran portu sihirli biçimde açmaz.

Certbot kurulumu

Ubuntu ve Debian tabanlı sistemlerde Certbot’u dağıtımın paket yöneticisiyle kurabilirsiniz. Güncel Ubuntu sürümlerinde snap yöntemi de yaygın; ben sunucuların paket yönetimiyle uyumlu kalmak için çoğu Debian kurulumunda apt paketlerini tercih ediyorum. Kurulumdan önce işletim sistemi sürümünü ve web sunucusunu öğrenin:

cat /etc/os-release
nginx -v
apache2 -v

Nginx için Debian veya Ubuntu üzerinde:

sudo apt update
sudo apt install certbot python3-certbot-nginx

Apache kullanıyorsanız Nginx eklentisi yerine Apache eklentisini kurun:

sudo apt install certbot python3-certbot-apache

Certbot eklentileri web sunucusunun sanal host yapılandırmasını okuyup sertifika kurulumunu kolaylaştırır. Yine de yapılandırma dosyanızı yedeklemeden otomatik değişiklik yaptırmam. Küçük bir hata, özellikle çok sayıda alan adı barındıran VPS’lerde beklenmedik bir siteyi etkileyebilir.

sudo cp -a /etc/nginx /etc/nginx.backup.$(date +%F)
sudo nginx -t

nginx -t çıktısında syntax is ok ve test is successful görmeniz gerekir. Bu satırları görmüyorsanız sertifika kurulumuna geçmeyin.

Nginx üzerinde Let’s Encrypt sertifikası

Önce Nginx yapılandırmasında alan adının tanımlı olduğundan emin olun. Basit bir sanal host örneği:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

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

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

Dosyayı örneğin /etc/nginx/sites-available/example.com konumuna koyduktan sonra etkinleştirin:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com
sudo nginx -t
sudo systemctl reload nginx

Buradaki reload mevcut bağlantıları koparmadan yapılandırmayı yeniden okur. Sertifika kurulumu öncesinde adresi HTTP ile açıp doğru sitenin geldiğini test edin. Nginx varsayılan sayfasını görüyorsanız hostname eşleşmesi henüz doğru değildir.

Production’da Nginx değişikliği yapmadan önce hostname’i prompt’ta kontrol etmek benim için teorik bir tavsiye değil. Bir staging sanıp production’da değişiklik yaptığım gün, kırmızı prompt alışkanlığını kalıcı hale getirdim. Dosyayı düzenlemeden önce hâlâ hostname çalıştırırım.

Artık Certbot’u Nginx eklentisiyle çalıştırabiliriz:

sudo certbot --nginx -d example.com -d www.example.com

Komut sizden e-posta adresi, hizmet şartları onayı ve HTTP isteklerinin HTTPS’e yönlendirilip yönlendirilmeyeceği konusunda seçim ister. Canlı bir site için yönlendirme seçeneğini tercih ederim; proxy arkasında çalışan özel yapılarda ise önce X-Forwarded-Proto davranışını kontrol ederim.

Certbot başarılı olduğunda sertifika dosyaları genellikle şu dizinde bulunur:

sudo ls -l /etc/letsencrypt/live/example.com/
sudo certbot certificates

live altındaki dosyalar gerçek sertifikaların kopyası değil, güncellenen sürümlere işaret eden sembolik bağlantılardır. Nginx yapılandırmasına bu yolu yazmak, her yenilemeden sonra dosya yolunu değiştirme ihtiyacını ortadan kaldırır:

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

Certbot bu satırları genellikle kendisi ekler. Elle yapılandırma yapıyorsanız fullchain.pem dosyasını sertifika olarak kullanın; yalnızca cert.pem kullanmak bazı istemcilerde ara sertifika zinciri sorunlarına yol açabilir.

Apache ile kurulum

Apache kullanan bir VPS’te işlem mantığı aynı, eklenti farklıdır. Sanal host içinde alan adının tanımlı olduğundan emin olduktan sonra:

sudo certbot --apache -d example.com -d www.example.com

Certbot, Apache sanal host dosyasına SSL yapılandırmasını ekleyebilir ve HTTP trafiğini HTTPS’e yönlendirebilir. Değişiklikten sonra Apache yapılandırmasını ayrıca test edin:

sudo apachectl configtest
sudo systemctl reload apache2

Syntax OK çıktısı yapılandırmanın sözdizimi açısından geçerli olduğunu gösterir. Uygulamanız Apache’nin arkasında PHP-FPM, Node.js veya Docker üzerinde çalışıyorsa sertifika web uygulamasına değil, çoğunlukla dışarı bakan Apache ya da Nginx katmanına kurulmalıdır.

Docker kullandığınız bir VPS’te reverse proxy mimarisini önceden planlamak işleri kolaylaştırır. Her konteynere ayrı ayrı sertifika dağıtmak yerine, dış trafiği karşılayan Nginx Proxy Manager, Traefik veya host üzerindeki Nginx sertifikayı sonlandırabilir. Docker kullanan VPS’lerde ilk konteyneri çalıştırmadan önce port çakışmalarını görmek için VPS’te Docker Kurulumu ve İlk Konteyneri Çalıştırma yazısındaki kontrol yaklaşımı işinize yarayabilir.

HTTPS yönlendirmesini kontrol etmek

Kurulumdan sonra hem sertifikayı hem de yönlendirmeyi terminalden kontrol edin:

curl -I http://example.com
curl -I https://example.com

İlk komutta beklediğim çıktı genellikle 301 veya 308 durum kodu ve Location: https://example.com/ başlığıdır. İkinci istekte 200 görmek güzel bir işaret olsa da uygulamanız giriş sayfasında farklı bir kod döndürebilir. Asıl bakmanız gereken TLS el sıkışmasının başarılı olması ve doğru sertifikanın sunulmasıdır.

Sertifikanın ayrıntılarını OpenSSL ile inceleyebilirsiniz:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

-servername seçeneği önemli. Aynı IP üzerinde birden fazla alan adı varsa SNI olmadan test ettiğinizde varsayılan sanal hostun sertifikasını görebilirsiniz. Çıktıda notBefore, notAfter, subject ve issuer alanlarını kontrol edin.

Yenileme otomasyonu: asıl iş burada

Let’s Encrypt sertifikaları kısa süreli verilir. VPS SSL sertifikası kurulumu tamamlandıktan sonra yenileme mekanizmasını mutlaka test edin. Certbot’un yenileme servisini veya zamanlayıcısını kontrol edin:

systemctl list-timers | grep certbot
systemctl status certbot.timer
sudo certbot renew --dry-run

--dry-run gerçek sertifikayı değiştirmeden yenileme akışını sınar. Başarılı bir test, DNS doğrulamasının, port erişiminin ve web sunucusu reload adımının çalıştığına dair iyi bir işarettir. Hata alırsanız bunu görmezden gelmeyin; sertifika süresi dolduğu gün çözmeye çalışmak için kötü bir zamandır.

Yenileme sonrası Nginx veya Apache’nin yeni sertifikayı yüklediğinden de emin olun. Dosyalar güncellense bile çalışan süreç eski sertifikayı belleğinde tutabilir. Certbot çoğu kurulumda deploy hook ile reload işlemini yönetir; özel yapılandırmalarda şu tür bir hook gerekebilir:

sudo install -d -m 0755 /etc/letsencrypt/renewal-hooks/deploy
sudo vim /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

#!/bin/sh
systemctl reload nginx

Dosyayı çalıştırılabilir yapın:

sudo chmod 0755 /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Hook’un yalnızca sertifika gerçekten yenilendiğinde çalışması gerekir. Her gün gereksiz reload yaptıran cron satırları yazmak yerine Certbot’un kendi yenileme akışına bağlanmak daha temizdir.

Yenileme işinin çalıştığını varsaymak yerine, ben certbot renew --dry-run çıktısını izlemeye alıyorum. Bir alarmın yalnızca HTTP durum koduna bakması yeterli olmayabilir; site açılırken sertifika süresi dolmuş olabilir.

Doğrulama yöntemleri: HTTP-01 ve DNS-01

Certbot, alan adının size ait olduğunu kanıtlamak için challenge yöntemleri kullanır. Standart Nginx kurulumlarında en kolay yöntem HTTP-01’dir. Let’s Encrypt, http://example.com/.well-known/acme-challenge/... altında geçici bir dosyaya ulaşmaya çalışır. Bu yüzden port 80’i tamamen kapatmak veya bütün HTTP isteklerini uygulama katmanında engellemek doğrulamayı bozabilir.

HTTP-01, wildcard sertifikaları desteklemez. *.example.com için DNS-01 kullanmanız gerekir. DNS sağlayıcınızın API’sini destekleyen Certbot eklentileriyle TXT kaydı otomatik oluşturulabilir. Örneğin Cloudflare DNS eklentisi kullanırken API anahtarını dosyaya koyacaksanız izinlerini sınırlandırın:

sudo chmod 0600 /root/.secrets/certbot/cloudflare.ini

Token’ı shell geçmişine veya herkese açık bir playbook dosyasına yazmayın. DNS API erişimi yalnızca ilgili zone için TXT kaydı oluşturma ve silme yetkisine sahip olmalı. Yetki sınırı küçük görünür ama sızıntı anında hasarı da küçük tutar.

Yaygın hatalar ve teşhis adımları

Timeout veya connection refused

Bu hata çoğu zaman sertifikadan değil ağ erişiminden kaynaklanır. Önce DNS’in doğru IP’yi gösterdiğini, ardından VPS firewall’unun ve sağlayıcı güvenlik grubunun 80 portuna izin verdiğini kontrol edin. Nginx’in yalnızca 127.0.0.1:80 üzerinde dinlemesi de dışarıdan doğrulamayı engeller.

sudo ss -ltnp | grep ':80'
curl -4 -I http://example.com
curl -6 -I http://example.com

IPv4 çalışıp IPv6 çalışmıyorsa ve alan adında hatalı AAAA kaydı varsa DNS tarafını düzeltin. Benzer bir problemi bir VPS taşımasında yaşamıştım; A kaydını güncelledim ama eski AAAA kaydını fark etmedim. IPv6 kullanan istemciler hâlâ eski sunucuya gidiyordu.

Too many redirects

Cloudflare gibi bir proxy kullanıyorsanız SSL modu ile origin sunucudaki HTTPS yapılandırması birbiriyle uyumlu olmalı. Proxy’nin dışarıda HTTPS alıp VPS’e HTTP ile bağlandığı, VPS’in de gelen isteği HTTPS’e yönlendirdiği durumda döngü oluşabilir. Uygulamanın proxy başlıklarını doğru yorumladığından emin olun.

Rate limit hataları

Başarısız denemeleri arka arkaya tekrarlamayın. Let’s Encrypt üretim ortamında doğrulama ve sertifika limitleri uygular. Önce --dry-run ile staging ortamında test edebilir, sorunu çözdükten sonra gerçek sertifika isteyebilirsiniz:

sudo certbot certonly --staging --nginx -d example.com

Staging sertifikaları tarayıcılar tarafından güvenilir kabul edilmez; yalnızca kurulum akışını test etmek içindir. Testten sonra staging sertifikasının canlı yapılandırmada kalmadığını kontrol edin.

Web sunucusu reload edilemiyor

Certbot sertifikayı almış olsa bile Nginx yapılandırmasındaki hata nedeniyle reload başarısız olabilir. Önce:

sudo nginx -t
sudo journalctl -u nginx -n 80 --no-pager

Log okumadan servisi yeniden başlatmak benim de gençlik günahlarımdan biriydi. Sertifika kurulumunda sorun olduğunda restart yerine önce yapılandırma testini ve ilgili logları inceliyorum; çalışan bağlantıları gereksiz yere kesmemiş oluyorum.

TLS yapılandırmasını sertleştirmek

Certbot’un varsayılan ayarları çoğu site için iyi bir başlangıçtır. Elle şifre takımı yazmaya başlamadan önce uygulamanın ve istemcilerin gereksinimlerini bilin. Eski cihaz desteği gerekmiyorsa TLS 1.2 ve TLS 1.3 kullanabilirsiniz:

ssl_protocols TLSv1.2 TLSv1.3;

HSTS konusunda acele etmeyin. Strict-Transport-Security başlığı tarayıcıya alan adına yalnızca HTTPS ile bağlanmasını söyler. includeSubDomains ve özellikle preload seçeneklerini, bütün alt alan adlarının HTTPS’e hazır olduğundan emin olmadan etkinleştirmeyin. Yanlış bir HSTS kararı, unutulmuş bir alt alan adına erişimi zorlaştırabilir.

HSTS öncesinde sitenin kaynaklarını, API uç noktalarını ve üçüncü taraf içeriklerini kontrol edin. HTTP üzerinden yüklenen resim, JavaScript veya fontlar tarayıcıda mixed content uyarılarına neden olabilir. Tarayıcı geliştirici araçlarının Console sekmesi bu noktada hızlı bir kontrol sağlar.

Sertifika ile sunucu güvenliğini karıştırmayın

SSL sertifikası, istemci ile sunucu arasındaki bağlantıyı şifreler ve alan adının doğrulanmasına yardımcı olur. Sunucunun güncel olduğu, SSH’nin güvenli yapılandırıldığı veya uygulamanın açıklarının kapatıldığı anlamına gelmez.

VPS kurulumundan sonra firewall, güncelleme, ayrı kullanıcı, SSH anahtarı ve saldırı tespit kontrollerini ayrıca ele alın. Bunun için Linux Sunucu Güvenliği için Zorunlu 10 Temel Adım yazısındaki temel kontrolleri kendi makinenizin risklerine göre uygulayabilirsiniz. SSH portunu değiştirmek tek başına güvenlik değildir; logları izlemeden port numarasıyla uğraşmak genellikle yalnızca gürültünün yerini değiştirir.

HTTPS sonrasında performans ölçümü yapıyorsanız TLS el sıkışmasını, HTTP sürümünü ve uygulama yanıt süresini birbirinden ayırın. Sadece TTFB değerini milisaniye milisaniye tartışıp cache kurmamak, benim gözümde termometreyi parlatıp pencereyi açık bırakmaya benziyor. HTTP/2 veya HTTP/3 tercihleri için ağ katmanını ayrıca incelemek gerekir; protokollerin farklarını görmek isterseniz İnternet Protokolleri: TCP/IP’den HTTP/3’e Derinlemesine Bakış yazısına bakabilirsiniz.

Kurulumdan sonra kullanacağım kısa kontrol listesi

• Alan adının A ve gerekiyorsa AAAA kaydı doğru VPS’i gösteriyor mu?
• TCP 80 ve 443 portları hem işletim sistemi firewall’unda hem sağlayıcı güvenlik grubunda açık mı?
• Nginx veya Apache doğru sanal hostu yüklüyor mu?
• certbot certificates doğru alan adını ve bitiş tarihini gösteriyor mu?
• certbot renew --dry-run başarıyla tamamlanıyor mu?
• Yenileme sonrasında web sunucusu yeni sertifikayı yüklemek için reload oluyor mu?
• HTTP istekleri beklenen şekilde HTTPS’e yönleniyor mu?
• HSTS veya proxy ayarları yanlış yönlendirme ve mixed content üretmiyor mu?

Kurulum tamamlandıktan sonra sertifika bitiş tarihini monitoring sistemine ekleyin. Uptime Kuma ile sitenin erişilebilirliğini, Prometheus veya ayrı bir exporter ile sertifika süresini izleyebilirsiniz. Benim evdeki Proxmox lab’ında yaptığım ilk testlerden biri de buydu; önce sertifikayı kısa süre içinde yenilenebilecek bir staging alanında sınadım, sonra müşteriye ait alan adına geçtim.

Let’s Encrypt kurulumu birkaç komutla bitebilir; güvenilir bir VPS SSL sertifikası kurulumu ise DNS’ten yenileme alarmına kadar bütün yolu test etmeyi gerektirir. Sertifikanın bugün çalışması yeterli değil. Asıl soru şu: iki ay sonra, gece vardiyasında kimse elle müdahale etmeden hâlâ çalışacak mı?