{"id":309,"date":"2026-08-29T17:19:13","date_gmt":"2026-08-29T17:19:13","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/?p=309"},"modified":"2026-08-29T09:08:12","modified_gmt":"2026-08-29T09:08:12","slug":"vps-ssl-sertifikasi-kurulumu-lets-encrypt","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/tr\/vps-ssl-sertifikasi-kurulumu-lets-encrypt\/","title":{"rendered":"VPS&#8217;te SSL Sertifikas\u0131 Kurulumu: Let&#8217;s Encrypt Rehberi"},"content":{"rendered":"<h2>VPS&#8217;te SSL sertifikas\u0131 kurmadan \u00f6nce bilmeniz gerekenler<\/h2>\n<p>Bir sitenin adres \u00e7ubu\u011funda kilit simgesini g\u00f6rmek ziyaret\u00e7i a\u00e7\u0131s\u0131ndan g\u00fcven vericidir. Sunucu y\u00f6neticisi a\u00e7\u0131s\u0131ndan ise DNS, web sunucusu ve otomatik yenileme zincirinin \u00e7al\u0131\u015ft\u0131\u011f\u0131 anlam\u0131na gelir. VPS SSL sertifikas\u0131 kurulumu yaln\u0131zca bir dosyay\u0131 sunucuya kopyalamaktan ibaret de\u011fil. Alan ad\u0131n\u0131n do\u011fru sunucuya bakmas\u0131, 80 ve 443 numaral\u0131 portlar\u0131n eri\u015filebilir olmas\u0131, web sunucusunun do\u011fru yap\u0131land\u0131r\u0131lmas\u0131 ve sertifikan\u0131n s\u00fcresi dolmadan yenilenmesi gerekir.<\/p>\n<p>Let&#8217;s Encrypt bunu \u00fccretsiz ve otomatikle\u015ftirilebilir bi\u00e7imde sa\u011fl\u0131yor. Ben \u00e7o\u011fu Linux VPS&#8217;te Nginx ile birlikte Certbot kullan\u0131yorum. Apache kullanan sunucularda da yol benzer; komutlar\u0131 \u00e7al\u0131\u015ft\u0131rmadan \u00f6nce hangi web sunucusunun ger\u00e7ekten aktif oldu\u011funu kontrol etmek gerekiyor. Yanl\u0131\u015f makinede \u00e7al\u0131\u015ft\u0131r\u0131lan do\u011fru komut da i\u015fe yaramaz.<\/p>\n<h2>Alan ad\u0131 ve VPS haz\u0131rl\u0131\u011f\u0131<\/h2>\n<p>Kuruluma ge\u00e7meden \u00f6nce alan ad\u0131n\u0131z\u0131n DNS kay\u0131tlar\u0131n\u0131 kontrol edin. <code>example.com<\/code> ve gerekiyorsa <code>www.example.com<\/code> kay\u0131tlar\u0131 VPS&#8217;in public IP adresine i\u015faret etmeli. IPv6 kullan\u0131yorsan\u0131z <code>AAAA<\/code> kayd\u0131n\u0131 da kontrol edin. Sunucuda \u00e7al\u0131\u015fan bir IPv6 servisi yokken DNS&#8217;te yanl\u0131\u015f bir <code>AAAA<\/code> kayd\u0131 bulunmas\u0131, do\u011frulama isteklerinin beklenmedik bir adrese gitmesine neden olabilir.<\/p>\n<p>Panelden bakmak yerine terminalde ilk kontrol\u00fcm genellikle \u015f\u00f6yledir:<\/p>\n<pre><code>dig +short example.com A\ndig +short example.com AAAA\ndig +short www.example.com A<\/code><\/pre>\n<p>\u0130lk komut VPS&#8217;in IPv4 adresini, ikinci komut varsa IPv6 adresini g\u00f6stermeli. <code>dig +short<\/code> bo\u015f d\u00f6n\u00fcyorsa DNS de\u011fi\u015fikli\u011fi hen\u00fcz yay\u0131lmam\u0131\u015f olabilir veya kay\u0131t eksiktir. DNS TTL de\u011ferine ba\u011fl\u0131 olarak beklemek gerekebilir; Certbot&#8217;u tekrar tekrar \u00e7al\u0131\u015ft\u0131rmak bu s\u00fcreci h\u0131zland\u0131rmaz.<\/p>\n<p>Web sunucusunun dinledi\u011fi portlar\u0131 da kontrol edin:<\/p>\n<pre><code>sudo ss -tulpn | grep -E ':80|:443'\nsudo ufw status verbose<\/code><\/pre>\n<p>Let&#8217;s Encrypt&#8217;in HTTP do\u011frulamas\u0131 i\u00e7in d\u0131\u015far\u0131dan TCP 80 portuna ula\u015fabilmesi gerekir. HTTPS trafi\u011fi i\u00e7in 443 de a\u00e7\u0131k olmal\u0131. UFW kullan\u0131yorsan\u0131z \u015fu profil iki portu da a\u00e7ar:<\/p>\n<pre><code>sudo ufw allow 'Nginx Full'\nsudo ufw status<\/code><\/pre>\n<p>Bu profil hem 80 hem 443 portunu a\u00e7ar. nftables, sa\u011flay\u0131c\u0131 g\u00fcvenlik grubu veya harici firewall kullan\u0131yorsan\u0131z ayn\u0131 izinleri o katmanlarda da tan\u0131mlaman\u0131z gerekir. VPS&#8217;te bir portu a\u00e7mak, sa\u011flay\u0131c\u0131n\u0131n a\u011f g\u00fcvenlik grubunda kapal\u0131 duran portu sihirli bi\u00e7imde a\u00e7maz.<\/p>\n<h2>Certbot kurulumu<\/h2>\n<p>Ubuntu ve Debian tabanl\u0131 sistemlerde Certbot&#8217;u da\u011f\u0131t\u0131m\u0131n paket y\u00f6neticisiyle kurabilirsiniz. G\u00fcncel Ubuntu s\u00fcr\u00fcmlerinde snap y\u00f6ntemi de yayg\u0131n; ben sunucular\u0131n paket y\u00f6netimiyle uyumlu kalmak i\u00e7in \u00e7o\u011fu Debian kurulumunda <code>apt<\/code> paketlerini tercih ediyorum. Kurulumdan \u00f6nce i\u015fletim sistemi s\u00fcr\u00fcm\u00fcn\u00fc ve web sunucusunu \u00f6\u011frenin:<\/p>\n<pre><code>cat \/etc\/os-release\nnginx -v\napache2 -v<\/code><\/pre>\n<p>Nginx i\u00e7in Debian veya Ubuntu \u00fczerinde:<\/p>\n<pre><code>sudo apt update\nsudo apt install certbot python3-certbot-nginx<\/code><\/pre>\n<p>Apache kullan\u0131yorsan\u0131z Nginx eklentisi yerine Apache eklentisini kurun:<\/p>\n<pre><code>sudo apt install certbot python3-certbot-apache<\/code><\/pre>\n<p>Certbot eklentileri web sunucusunun sanal host yap\u0131land\u0131rmas\u0131n\u0131 okuyup sertifika kurulumunu kolayla\u015ft\u0131r\u0131r. Yine de yap\u0131land\u0131rma dosyan\u0131z\u0131 yedeklemeden otomatik de\u011fi\u015fiklik yapt\u0131rmam. K\u00fc\u00e7\u00fck bir hata, \u00f6zellikle \u00e7ok say\u0131da alan ad\u0131 bar\u0131nd\u0131ran VPS&#8217;lerde beklenmedik bir siteyi etkileyebilir.<\/p>\n<pre><code>sudo cp -a \/etc\/nginx \/etc\/nginx.backup.$(date +%F)\nsudo nginx -t<\/code><\/pre>\n<p><code>nginx -t<\/code> \u00e7\u0131kt\u0131s\u0131nda <code>syntax is ok<\/code> ve <code>test is successful<\/code> g\u00f6rmeniz gerekir. Bu sat\u0131rlar\u0131 g\u00f6rm\u00fcyorsan\u0131z sertifika kurulumuna ge\u00e7meyin.<\/p>\n<h2>Nginx \u00fczerinde Let&#8217;s Encrypt sertifikas\u0131<\/h2>\n<p>\u00d6nce Nginx yap\u0131land\u0131rmas\u0131nda alan ad\u0131n\u0131n tan\u0131ml\u0131 oldu\u011fundan emin olun. Basit bir sanal host \u00f6rne\u011fi:<\/p>\n<pre><code>server {\n    listen 80;\n    listen [::]:80;\n    server_name example.com www.example.com;\n\n    root \/var\/www\/example.com\/public;\n    index index.html index.php;\n\n    location \/ {\n        try_files $uri $uri\/ =404;\n    }\n}<\/code><\/pre>\n<p>Dosyay\u0131 \u00f6rne\u011fin <code>\/etc\/nginx\/sites-available\/example.com<\/code> konumuna koyduktan sonra etkinle\u015ftirin:<\/p>\n<pre><code>sudo ln -s \/etc\/nginx\/sites-available\/example.com \/etc\/nginx\/sites-enabled\/example.com\nsudo nginx -t\nsudo systemctl reload nginx<\/code><\/pre>\n<p>Buradaki <code>reload<\/code> mevcut ba\u011flant\u0131lar\u0131 koparmadan yap\u0131land\u0131rmay\u0131 yeniden okur. Sertifika kurulumu \u00f6ncesinde adresi HTTP ile a\u00e7\u0131p do\u011fru sitenin geldi\u011fini test edin. Nginx varsay\u0131lan sayfas\u0131n\u0131 g\u00f6r\u00fcyorsan\u0131z hostname e\u015fle\u015fmesi hen\u00fcz do\u011fru de\u011fildir.<\/p>\n<p>Production&#8217;da Nginx de\u011fi\u015fikli\u011fi yapmadan \u00f6nce hostname&#8217;i prompt&#8217;ta kontrol etmek benim i\u00e7in teorik bir tavsiye de\u011fil. Bir staging san\u0131p production&#8217;da de\u011fi\u015fiklik yapt\u0131\u011f\u0131m g\u00fcn, k\u0131rm\u0131z\u0131 prompt al\u0131\u015fkanl\u0131\u011f\u0131n\u0131 kal\u0131c\u0131 hale getirdim. Dosyay\u0131 d\u00fczenlemeden \u00f6nce h\u00e2l\u00e2 <code>hostname<\/code> \u00e7al\u0131\u015ft\u0131r\u0131r\u0131m.<\/p>\n<p>Art\u0131k Certbot&#8217;u Nginx eklentisiyle \u00e7al\u0131\u015ft\u0131rabiliriz:<\/p>\n<pre><code>sudo certbot --nginx -d example.com -d www.example.com<\/code><\/pre>\n<p>Komut sizden e-posta adresi, hizmet \u015fartlar\u0131 onay\u0131 ve HTTP isteklerinin HTTPS&#8217;e y\u00f6nlendirilip y\u00f6nlendirilmeyece\u011fi konusunda se\u00e7im ister. Canl\u0131 bir site i\u00e7in y\u00f6nlendirme se\u00e7ene\u011fini tercih ederim; proxy arkas\u0131nda \u00e7al\u0131\u015fan \u00f6zel yap\u0131larda ise \u00f6nce <code>X-Forwarded-Proto<\/code> davran\u0131\u015f\u0131n\u0131 kontrol ederim.<\/p>\n<p>Certbot ba\u015far\u0131l\u0131 oldu\u011funda sertifika dosyalar\u0131 genellikle \u015fu dizinde bulunur:<\/p>\n<pre><code>sudo ls -l \/etc\/letsencrypt\/live\/example.com\/\nsudo certbot certificates<\/code><\/pre>\n<p><code>live<\/code> alt\u0131ndaki dosyalar ger\u00e7ek sertifikalar\u0131n kopyas\u0131 de\u011fil, g\u00fcncellenen s\u00fcr\u00fcmlere i\u015faret eden sembolik ba\u011flant\u0131lard\u0131r. Nginx yap\u0131land\u0131rmas\u0131na bu yolu yazmak, her yenilemeden sonra dosya yolunu de\u011fi\u015ftirme ihtiyac\u0131n\u0131 ortadan kald\u0131r\u0131r:<\/p>\n<pre><code>ssl_certificate \/etc\/letsencrypt\/live\/example.com\/fullchain.pem;\nssl_certificate_key \/etc\/letsencrypt\/live\/example.com\/privkey.pem;<\/code><\/pre>\n<p>Certbot bu sat\u0131rlar\u0131 genellikle kendisi ekler. Elle yap\u0131land\u0131rma yap\u0131yorsan\u0131z <code>fullchain.pem<\/code> dosyas\u0131n\u0131 sertifika olarak kullan\u0131n; yaln\u0131zca <code>cert.pem<\/code> kullanmak baz\u0131 istemcilerde ara sertifika zinciri sorunlar\u0131na yol a\u00e7abilir.<\/p>\n<h2>Apache ile kurulum<\/h2>\n<p>Apache kullanan bir VPS&#8217;te i\u015flem mant\u0131\u011f\u0131 ayn\u0131, eklenti farkl\u0131d\u0131r. Sanal host i\u00e7inde alan ad\u0131n\u0131n tan\u0131ml\u0131 oldu\u011fundan emin olduktan sonra:<\/p>\n<pre><code>sudo certbot --apache -d example.com -d www.example.com<\/code><\/pre>\n<p>Certbot, Apache sanal host dosyas\u0131na SSL yap\u0131land\u0131rmas\u0131n\u0131 ekleyebilir ve HTTP trafi\u011fini HTTPS&#8217;e y\u00f6nlendirebilir. De\u011fi\u015fiklikten sonra Apache yap\u0131land\u0131rmas\u0131n\u0131 ayr\u0131ca test edin:<\/p>\n<pre><code>sudo apachectl configtest\nsudo systemctl reload apache2<\/code><\/pre>\n<p><code>Syntax OK<\/code> \u00e7\u0131kt\u0131s\u0131 yap\u0131land\u0131rman\u0131n s\u00f6zdizimi a\u00e7\u0131s\u0131ndan ge\u00e7erli oldu\u011funu g\u00f6sterir. Uygulaman\u0131z Apache&#8217;nin arkas\u0131nda PHP-FPM, Node.js veya Docker \u00fczerinde \u00e7al\u0131\u015f\u0131yorsa sertifika web uygulamas\u0131na de\u011fil, \u00e7o\u011funlukla d\u0131\u015far\u0131 bakan Apache ya da Nginx katman\u0131na kurulmal\u0131d\u0131r.<\/p>\n<p>Docker kulland\u0131\u011f\u0131n\u0131z bir VPS&#8217;te reverse proxy mimarisini \u00f6nceden planlamak i\u015fleri kolayla\u015ft\u0131r\u0131r. Her konteynere ayr\u0131 ayr\u0131 sertifika da\u011f\u0131tmak yerine, d\u0131\u015f trafi\u011fi kar\u015f\u0131layan Nginx Proxy Manager, Traefik veya host \u00fczerindeki Nginx sertifikay\u0131 sonland\u0131rabilir. Docker kullanan VPS&#8217;lerde ilk konteyneri \u00e7al\u0131\u015ft\u0131rmadan \u00f6nce port \u00e7ak\u0131\u015fmalar\u0131n\u0131 g\u00f6rmek i\u00e7in <a>VPS&#8217;te Docker Kurulumu ve \u0130lk Konteyneri \u00c7al\u0131\u015ft\u0131rma<\/a> yaz\u0131s\u0131ndaki kontrol yakla\u015f\u0131m\u0131 i\u015finize yarayabilir.<\/p>\n<h2>HTTPS y\u00f6nlendirmesini kontrol etmek<\/h2>\n<p>Kurulumdan sonra hem sertifikay\u0131 hem de y\u00f6nlendirmeyi terminalden kontrol edin:<\/p>\n<pre><code>curl -I http:\/\/example.com\ncurl -I https:\/\/example.com<\/code><\/pre>\n<p>\u0130lk komutta bekledi\u011fim \u00e7\u0131kt\u0131 genellikle <code>301<\/code> veya <code>308<\/code> durum kodu ve <code>Location: https:\/\/example.com\/<\/code> ba\u015fl\u0131\u011f\u0131d\u0131r. \u0130kinci istekte <code>200<\/code> g\u00f6rmek g\u00fczel bir i\u015faret olsa da uygulaman\u0131z giri\u015f sayfas\u0131nda farkl\u0131 bir kod d\u00f6nd\u00fcrebilir. As\u0131l bakman\u0131z gereken TLS el s\u0131k\u0131\u015fmas\u0131n\u0131n ba\u015far\u0131l\u0131 olmas\u0131 ve do\u011fru sertifikan\u0131n sunulmas\u0131d\u0131r.<\/p>\n<p>Sertifikan\u0131n ayr\u0131nt\u0131lar\u0131n\u0131 OpenSSL ile inceleyebilirsiniz:<\/p>\n<pre><code>echo | openssl s_client -connect example.com:443 -servername example.com 2&gt;\/dev\/null | openssl x509 -noout -subject -issuer -dates<\/code><\/pre>\n<p><code>-servername<\/code> se\u00e7ene\u011fi \u00f6nemli. Ayn\u0131 IP \u00fczerinde birden fazla alan ad\u0131 varsa SNI olmadan test etti\u011finizde varsay\u0131lan sanal hostun sertifikas\u0131n\u0131 g\u00f6rebilirsiniz. \u00c7\u0131kt\u0131da <code>notBefore<\/code>, <code>notAfter<\/code>, <code>subject<\/code> ve <code>issuer<\/code> alanlar\u0131n\u0131 kontrol edin.<\/p>\n<h2>Yenileme otomasyonu: as\u0131l i\u015f burada<\/h2>\n<p>Let&#8217;s Encrypt sertifikalar\u0131 k\u0131sa s\u00fcreli verilir. VPS SSL sertifikas\u0131 kurulumu tamamland\u0131ktan sonra yenileme mekanizmas\u0131n\u0131 mutlaka test edin. Certbot&#8217;un yenileme servisini veya zamanlay\u0131c\u0131s\u0131n\u0131 kontrol edin:<\/p>\n<pre><code>systemctl list-timers | grep certbot\nsystemctl status certbot.timer\nsudo certbot renew --dry-run<\/code><\/pre>\n<p><code>--dry-run<\/code> ger\u00e7ek sertifikay\u0131 de\u011fi\u015ftirmeden yenileme ak\u0131\u015f\u0131n\u0131 s\u0131nar. Ba\u015far\u0131l\u0131 bir test, DNS do\u011frulamas\u0131n\u0131n, port eri\u015fiminin ve web sunucusu reload ad\u0131m\u0131n\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131na dair iyi bir i\u015farettir. Hata al\u0131rsan\u0131z bunu g\u00f6rmezden gelmeyin; sertifika s\u00fcresi doldu\u011fu g\u00fcn \u00e7\u00f6zmeye \u00e7al\u0131\u015fmak i\u00e7in k\u00f6t\u00fc bir zamand\u0131r.<\/p>\n<p>Yenileme sonras\u0131 Nginx veya Apache&#8217;nin yeni sertifikay\u0131 y\u00fckledi\u011finden de emin olun. Dosyalar g\u00fcncellense bile \u00e7al\u0131\u015fan s\u00fcre\u00e7 eski sertifikay\u0131 belle\u011finde tutabilir. Certbot \u00e7o\u011fu kurulumda deploy hook ile reload i\u015flemini y\u00f6netir; \u00f6zel yap\u0131land\u0131rmalarda \u015fu t\u00fcr bir hook gerekebilir:<\/p>\n<pre><code>sudo install -d -m 0755 \/etc\/letsencrypt\/renewal-hooks\/deploy\nsudo vim \/etc\/letsencrypt\/renewal-hooks\/deploy\/reload-nginx.sh<\/code><\/pre>\n<pre><code>#!\/bin\/sh\nsystemctl reload nginx<\/code><\/pre>\n<p>Dosyay\u0131 \u00e7al\u0131\u015ft\u0131r\u0131labilir yap\u0131n:<\/p>\n<pre><code>sudo chmod 0755 \/etc\/letsencrypt\/renewal-hooks\/deploy\/reload-nginx.sh<\/code><\/pre>\n<p>Hook&#8217;un yaln\u0131zca sertifika ger\u00e7ekten yenilendi\u011finde \u00e7al\u0131\u015fmas\u0131 gerekir. Her g\u00fcn gereksiz reload yapt\u0131ran cron sat\u0131rlar\u0131 yazmak yerine Certbot&#8217;un kendi yenileme ak\u0131\u015f\u0131na ba\u011flanmak daha temizdir.<\/p>\n<p>Yenileme i\u015finin \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 varsaymak yerine, ben <code>certbot renew --dry-run<\/code> \u00e7\u0131kt\u0131s\u0131n\u0131 izlemeye al\u0131yorum. Bir alarm\u0131n yaln\u0131zca HTTP durum koduna bakmas\u0131 yeterli olmayabilir; site a\u00e7\u0131l\u0131rken sertifika s\u00fcresi dolmu\u015f olabilir.<\/p>\n<h2>Do\u011frulama y\u00f6ntemleri: HTTP-01 ve DNS-01<\/h2>\n<p>Certbot, alan ad\u0131n\u0131n size ait oldu\u011funu kan\u0131tlamak i\u00e7in challenge y\u00f6ntemleri kullan\u0131r. Standart Nginx kurulumlar\u0131nda en kolay y\u00f6ntem HTTP-01&#8217;dir. Let&#8217;s Encrypt, <code>http:\/\/example.com\/.well-known\/acme-challenge\/...<\/code> alt\u0131nda ge\u00e7ici bir dosyaya ula\u015fmaya \u00e7al\u0131\u015f\u0131r. Bu y\u00fczden port 80&#8217;i tamamen kapatmak veya b\u00fct\u00fcn HTTP isteklerini uygulama katman\u0131nda engellemek do\u011frulamay\u0131 bozabilir.<\/p>\n<p>HTTP-01, wildcard sertifikalar\u0131 desteklemez. <code>*.example.com<\/code> i\u00e7in DNS-01 kullanman\u0131z gerekir. DNS sa\u011flay\u0131c\u0131n\u0131z\u0131n API&#8217;sini destekleyen Certbot eklentileriyle TXT kayd\u0131 otomatik olu\u015fturulabilir. \u00d6rne\u011fin Cloudflare DNS eklentisi kullan\u0131rken API anahtar\u0131n\u0131 dosyaya koyacaksan\u0131z izinlerini s\u0131n\u0131rland\u0131r\u0131n:<\/p>\n<pre><code>sudo chmod 0600 \/root\/.secrets\/certbot\/cloudflare.ini<\/code><\/pre>\n<p>Token&#8217;\u0131 shell ge\u00e7mi\u015fine veya herkese a\u00e7\u0131k bir playbook dosyas\u0131na yazmay\u0131n. DNS API eri\u015fimi yaln\u0131zca ilgili zone i\u00e7in TXT kayd\u0131 olu\u015fturma ve silme yetkisine sahip olmal\u0131. Yetki s\u0131n\u0131r\u0131 k\u00fc\u00e7\u00fck g\u00f6r\u00fcn\u00fcr ama s\u0131z\u0131nt\u0131 an\u0131nda hasar\u0131 da k\u00fc\u00e7\u00fck tutar.<\/p>\n<h2>Yayg\u0131n hatalar ve te\u015fhis ad\u0131mlar\u0131<\/h2>\n<h3>Timeout veya connection refused<\/h3>\n<p>Bu hata \u00e7o\u011fu zaman sertifikadan de\u011fil a\u011f eri\u015fiminden kaynaklan\u0131r. \u00d6nce DNS&#8217;in do\u011fru IP&#8217;yi g\u00f6sterdi\u011fini, ard\u0131ndan VPS firewall&#8217;unun ve sa\u011flay\u0131c\u0131 g\u00fcvenlik grubunun 80 portuna izin verdi\u011fini kontrol edin. Nginx&#8217;in yaln\u0131zca <code>127.0.0.1:80<\/code> \u00fczerinde dinlemesi de d\u0131\u015far\u0131dan do\u011frulamay\u0131 engeller.<\/p>\n<pre><code>sudo ss -ltnp | grep ':80'\ncurl -4 -I http:\/\/example.com\ncurl -6 -I http:\/\/example.com<\/code><\/pre>\n<p>IPv4 \u00e7al\u0131\u015f\u0131p IPv6 \u00e7al\u0131\u015fm\u0131yorsa ve alan ad\u0131nda hatal\u0131 <code>AAAA<\/code> kayd\u0131 varsa DNS taraf\u0131n\u0131 d\u00fczeltin. Benzer bir problemi bir VPS ta\u015f\u0131mas\u0131nda ya\u015fam\u0131\u015ft\u0131m; A kayd\u0131n\u0131 g\u00fcncelledim ama eski AAAA kayd\u0131n\u0131 fark etmedim. IPv6 kullanan istemciler h\u00e2l\u00e2 eski sunucuya gidiyordu.<\/p>\n<h3>Too many redirects<\/h3>\n<p>Cloudflare gibi bir proxy kullan\u0131yorsan\u0131z SSL modu ile origin sunucudaki HTTPS yap\u0131land\u0131rmas\u0131 birbiriyle uyumlu olmal\u0131. Proxy&#8217;nin d\u0131\u015far\u0131da HTTPS al\u0131p VPS&#8217;e HTTP ile ba\u011fland\u0131\u011f\u0131, VPS&#8217;in de gelen iste\u011fi HTTPS&#8217;e y\u00f6nlendirdi\u011fi durumda d\u00f6ng\u00fc olu\u015fabilir. Uygulaman\u0131n proxy ba\u015fl\u0131klar\u0131n\u0131 do\u011fru yorumlad\u0131\u011f\u0131ndan emin olun.<\/p>\n<h3>Rate limit hatalar\u0131<\/h3>\n<p>Ba\u015far\u0131s\u0131z denemeleri arka arkaya tekrarlamay\u0131n. Let&#8217;s Encrypt \u00fcretim ortam\u0131nda do\u011frulama ve sertifika limitleri uygular. \u00d6nce <code>--dry-run<\/code> ile staging ortam\u0131nda test edebilir, sorunu \u00e7\u00f6zd\u00fckten sonra ger\u00e7ek sertifika isteyebilirsiniz:<\/p>\n<pre><code>sudo certbot certonly --staging --nginx -d example.com<\/code><\/pre>\n<p>Staging sertifikalar\u0131 taray\u0131c\u0131lar taraf\u0131ndan g\u00fcvenilir kabul edilmez; yaln\u0131zca kurulum ak\u0131\u015f\u0131n\u0131 test etmek i\u00e7indir. Testten sonra staging sertifikas\u0131n\u0131n canl\u0131 yap\u0131land\u0131rmada kalmad\u0131\u011f\u0131n\u0131 kontrol edin.<\/p>\n<h3>Web sunucusu reload edilemiyor<\/h3>\n<p>Certbot sertifikay\u0131 alm\u0131\u015f olsa bile Nginx yap\u0131land\u0131rmas\u0131ndaki hata nedeniyle reload ba\u015far\u0131s\u0131z olabilir. \u00d6nce:<\/p>\n<pre><code>sudo nginx -t\nsudo journalctl -u nginx -n 80 --no-pager<\/code><\/pre>\n<p>Log okumadan servisi yeniden ba\u015flatmak benim de gen\u00e7lik g\u00fcnahlar\u0131mdan biriydi. Sertifika kurulumunda sorun oldu\u011funda restart yerine \u00f6nce yap\u0131land\u0131rma testini ve ilgili loglar\u0131 inceliyorum; \u00e7al\u0131\u015fan ba\u011flant\u0131lar\u0131 gereksiz yere kesmemi\u015f oluyorum.<\/p>\n<h2>TLS yap\u0131land\u0131rmas\u0131n\u0131 sertle\u015ftirmek<\/h2>\n<p>Certbot&#8217;un varsay\u0131lan ayarlar\u0131 \u00e7o\u011fu site i\u00e7in iyi bir ba\u015flang\u0131\u00e7t\u0131r. Elle \u015fifre tak\u0131m\u0131 yazmaya ba\u015flamadan \u00f6nce uygulaman\u0131n ve istemcilerin gereksinimlerini bilin. Eski cihaz deste\u011fi gerekmiyorsa TLS 1.2 ve TLS 1.3 kullanabilirsiniz:<\/p>\n<pre><code>ssl_protocols TLSv1.2 TLSv1.3;<\/code><\/pre>\n<p>HSTS konusunda acele etmeyin. <code>Strict-Transport-Security<\/code> ba\u015fl\u0131\u011f\u0131 taray\u0131c\u0131ya alan ad\u0131na yaln\u0131zca HTTPS ile ba\u011flanmas\u0131n\u0131 s\u00f6yler. <code>includeSubDomains<\/code> ve \u00f6zellikle <code>preload<\/code> se\u00e7eneklerini, b\u00fct\u00fcn alt alan adlar\u0131n\u0131n HTTPS&#8217;e haz\u0131r oldu\u011fundan emin olmadan etkinle\u015ftirmeyin. Yanl\u0131\u015f bir HSTS karar\u0131, unutulmu\u015f bir alt alan ad\u0131na eri\u015fimi zorla\u015ft\u0131rabilir.<\/p>\n<p>HSTS \u00f6ncesinde sitenin kaynaklar\u0131n\u0131, API u\u00e7 noktalar\u0131n\u0131 ve \u00fc\u00e7\u00fcnc\u00fc taraf i\u00e7eriklerini kontrol edin. HTTP \u00fczerinden y\u00fcklenen resim, JavaScript veya fontlar taray\u0131c\u0131da mixed content uyar\u0131lar\u0131na neden olabilir. Taray\u0131c\u0131 geli\u015ftirici ara\u00e7lar\u0131n\u0131n Console sekmesi bu noktada h\u0131zl\u0131 bir kontrol sa\u011flar.<\/p>\n<h2>Sertifika ile sunucu g\u00fcvenli\u011fini kar\u0131\u015ft\u0131rmay\u0131n<\/h2>\n<p>SSL sertifikas\u0131, istemci ile sunucu aras\u0131ndaki ba\u011flant\u0131y\u0131 \u015fifreler ve alan ad\u0131n\u0131n do\u011frulanmas\u0131na yard\u0131mc\u0131 olur. Sunucunun g\u00fcncel oldu\u011fu, SSH&#8217;nin g\u00fcvenli yap\u0131land\u0131r\u0131ld\u0131\u011f\u0131 veya uygulaman\u0131n a\u00e7\u0131klar\u0131n\u0131n kapat\u0131ld\u0131\u011f\u0131 anlam\u0131na gelmez.<\/p>\n<p>VPS kurulumundan sonra firewall, g\u00fcncelleme, ayr\u0131 kullan\u0131c\u0131, SSH anahtar\u0131 ve sald\u0131r\u0131 tespit kontrollerini ayr\u0131ca ele al\u0131n. Bunun i\u00e7in <a>Linux Sunucu G\u00fcvenli\u011fi i\u00e7in Zorunlu 10 Temel Ad\u0131m<\/a> yaz\u0131s\u0131ndaki temel kontrolleri kendi makinenizin risklerine g\u00f6re uygulayabilirsiniz. SSH portunu de\u011fi\u015ftirmek tek ba\u015f\u0131na g\u00fcvenlik de\u011fildir; loglar\u0131 izlemeden port numaras\u0131yla u\u011fra\u015fmak genellikle yaln\u0131zca g\u00fcr\u00fclt\u00fcn\u00fcn yerini de\u011fi\u015ftirir.<\/p>\n<p>HTTPS sonras\u0131nda performans \u00f6l\u00e7\u00fcm\u00fc yap\u0131yorsan\u0131z TLS el s\u0131k\u0131\u015fmas\u0131n\u0131, HTTP s\u00fcr\u00fcm\u00fcn\u00fc ve uygulama yan\u0131t s\u00fcresini birbirinden ay\u0131r\u0131n. Sadece TTFB de\u011ferini milisaniye milisaniye tart\u0131\u015f\u0131p cache kurmamak, benim g\u00f6z\u00fcmde termometreyi parlat\u0131p pencereyi a\u00e7\u0131k b\u0131rakmaya benziyor. HTTP\/2 veya HTTP\/3 tercihleri i\u00e7in a\u011f katman\u0131n\u0131 ayr\u0131ca incelemek gerekir; protokollerin farklar\u0131n\u0131 g\u00f6rmek isterseniz <a>\u0130nternet Protokolleri: TCP\/IP&#8217;den HTTP\/3&#8217;e Derinlemesine Bak\u0131\u015f<\/a> yaz\u0131s\u0131na bakabilirsiniz.<\/p>\n<h2>Kurulumdan sonra kullanaca\u011f\u0131m k\u0131sa kontrol listesi<\/h2>\n<ul>\n<li>Alan ad\u0131n\u0131n A ve gerekiyorsa AAAA kayd\u0131 do\u011fru VPS&#8217;i g\u00f6steriyor mu?<\/li>\n<li>TCP 80 ve 443 portlar\u0131 hem i\u015fletim sistemi firewall&#8217;unda hem sa\u011flay\u0131c\u0131 g\u00fcvenlik grubunda a\u00e7\u0131k m\u0131?<\/li>\n<li>Nginx veya Apache do\u011fru sanal hostu y\u00fckl\u00fcyor mu?<\/li>\n<li><code>certbot certificates<\/code> do\u011fru alan ad\u0131n\u0131 ve biti\u015f tarihini g\u00f6steriyor mu?<\/li>\n<li><code>certbot renew --dry-run<\/code> ba\u015far\u0131yla tamamlan\u0131yor mu?<\/li>\n<li>Yenileme sonras\u0131nda web sunucusu yeni sertifikay\u0131 y\u00fcklemek i\u00e7in reload oluyor mu?<\/li>\n<li>HTTP istekleri beklenen \u015fekilde HTTPS&#8217;e y\u00f6nleniyor mu?<\/li>\n<li>HSTS veya proxy ayarlar\u0131 yanl\u0131\u015f y\u00f6nlendirme ve mixed content \u00fcretmiyor mu?<\/li>\n<\/ul>\n<p>Kurulum tamamland\u0131ktan sonra sertifika biti\u015f tarihini monitoring sistemine ekleyin. Uptime Kuma ile sitenin eri\u015filebilirli\u011fini, Prometheus veya ayr\u0131 bir exporter ile sertifika s\u00fcresini izleyebilirsiniz. Benim evdeki Proxmox lab&#8217;\u0131nda yapt\u0131\u011f\u0131m ilk testlerden biri de buydu; \u00f6nce sertifikay\u0131 k\u0131sa s\u00fcre i\u00e7inde yenilenebilecek bir staging alan\u0131nda s\u0131nad\u0131m, sonra m\u00fc\u015fteriye ait alan ad\u0131na ge\u00e7tim.<\/p>\n<p>Let&#8217;s Encrypt kurulumu birka\u00e7 komutla bitebilir; g\u00fcvenilir bir VPS SSL sertifikas\u0131 kurulumu ise DNS&#8217;ten yenileme alarm\u0131na kadar b\u00fct\u00fcn yolu test etmeyi gerektirir. Sertifikan\u0131n bug\u00fcn \u00e7al\u0131\u015fmas\u0131 yeterli de\u011fil. As\u0131l soru \u015fu: iki ay sonra, gece vardiyas\u0131nda kimse elle m\u00fcdahale etmeden h\u00e2l\u00e2 \u00e7al\u0131\u015facak m\u0131?<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Let&#8217;s Encrypt ve Certbot kullanarak VPS \u00fczerinde SSL sertifikas\u0131 kurun; DNS, Nginx, Apache, otomatik yenileme ve yayg\u0131n hatalar\u0131 ad\u0131m ad\u0131m inceleyin.<\/p>\n","protected":false},"author":2,"featured_media":307,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[723],"tags":[1276,1272,1278,1270,389,41,1268,114],"class_list":["post-309","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-nasil-yapilir","tag-apache","tag-certbot","tag-https","tag-lets-encrypt","tag-linux","tag-nginx","tag-ssl","tag-vps"],"lang":"tr","translations":{"tr":309,"en":310},"pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/309","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/comments?post=309"}],"version-history":[{"count":1,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/309\/revisions"}],"predecessor-version":[{"id":311,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/309\/revisions\/311"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media\/307"}],"wp:attachment":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media?parent=309"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/categories?post=309"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/tags?post=309"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}