SSL Özel Anahtarı Sızdıysa: İptal ve Yeniden Kurulum

Özel anahtar, sunucunuzun HTTPS bağlantısında kimliğini kanıtlamak için kullandığı gizli bilgidir. Bu anahtarı yanlışlıkla Git deposuna göndermiş, destek kaydına eklemiş veya herkese açık bir dizinde bırakmış olabilirsiniz. Dosyayı kaldırmanız başkalarının aldığı kopyaları geçersiz kılmaz. Tarayıcıda bağlantının güvenli görünmesi de anahtarın yalnızca sizde olduğunu göstermez.

Aşağıdaki müdahale sırasını izleyerek hangi sertifikaların etkilendiğini belirleyebilir, yeni anahtarla kurulumu tamamlayabilir ve eski sertifikaların iptalini takip edebilirsiniz. Adımlar, Ubuntu üzerinde Nginx web sunucusu ve sertifika işlemlerini otomatikleştiren Certbot aracının kullanıldığı tek bir örnek ortamı izler. Bu örnekte yalnızca özel anahtarın Git deposuna sızdığı varsayılır. Sunucu veya sertifika yönetim hesabı da ele geçirilmişse yeni anahtara geçmeden önce güvenilir, temiz bir ortam gerekir.

SSL özel anahtar sızıntısında ilk müdahale sırası

SSL özel anahtar sızıntısı doğrulandığında, anahtarın başkaları tarafından kopyalanmış olabileceğini kabul edin. Dosyayı silmek yeni erişimleri azaltır; daha önce alınmış kopyaları geçersiz kılmaz. Rutin sertifika yenilemesi de aynı anahtarı kullanabilir. Bu nedenle müdahalenin hedefi yeni anahtara geçmek ve sızan anahtara bağlı sertifikaları iptal ettirmektir.

Önce erişimi sınırlayın, olay izini koruyun

Git sağlayıcınızın depo ayarlarında görünürlük bölümünü açın ve erişimi yalnız yetkili kişilerle sınırlayın. Anahtar destek kaydındaysa ekin erişimini kapattırın; web dizinindeyse dosyayı web üzerinden sunulan kök dizinin dışına taşıyın. Oturum açılmamış bir tarayıcıyla eski adresi ziyaret edin; dosyanın artık okunamadığını veya indirilemediğini kontrol edin.

Geçmişi temizlemeden önce belirleyebildiğiniz ilk sızıntı zamanını, dosya yolunu, ilgili commit kimliğini, yani Git değişiklik kaydının kimliğini ve mevcut erişim kayıtlarını saklayın. Anahtarı yeni bir destek kaydına yapıştırmayın. Örnekte mevcut sertifikanın aşağıdaki yolda bulunduğu varsayılıyor. Sunucunun terminalinde yalnız yönetici hesabı root’un erişebileceği olay dizinini oluşturup eski sertifikayı buraya kopyalayın:

sudo install -d -m 700 /root/ssl-incident
sudo cp -L /etc/letsencrypt/live/example.com/cert.pem /root/ssl-incident/old-cert.pem

Komutlar hatasız tamamlandığında olay dizininde eski sertifikanın bir kopyası bulunur. Bu kopya iptal edilecek sertifikayı belirlemek içindir; sızmış anahtarı yeniden kullanacağınız bir geri dönüş noktası değildir.

Aynı anahtara bağlı sertifikaları belirleyin

Dosya adlarının farklı olması anahtarların farklı olduğunu göstermez. Sunucuda OpenSSL kuruluysa aşağıdaki komutları terminalde çalıştırın. Komutlar, özel anahtardan ve sertifikadan çıkarılan açık anahtarın SHA-256 özetini, yani karşılaştırılabilir parmak izini verir; özel anahtarın kendisini ekrana yazdırmaz:

sudo openssl pkey -in /etc/letsencrypt/live/example.com/privkey.pem -pubout -outform DER | openssl dgst -sha256
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256

Her iki komuttaki tüm işlemler hatasız tamamlandığında özetlerin eşitliği, sertifikanın bu özel anahtarla eşleştiğini gösterir. Dosya okuma veya izin hatası görürseniz çıktıları karşılaştırmayın; önce belirtilen dosyaya erişim sorununu çözün. Diğer mevcut sertifikalar için ikinci komuttaki sertifika yolunu değiştirip çıkan özeti ilk komutun özetiyle karşılaştırın.

Bulguları sertifika sağlayıcınızın kayıtlarıyla birlikte inceleyin. Aynı anahtarı kullanan, süresi dolmamış sertifikaları ve bunların kurulu olduğu sunucuları listeleyin. Yenileme öncesindeki sertifikaları da kontrol edin; yeni sertifika alınmış olması öncekinin süresinin dolduğu veya iptal edildiği anlamına gelmez.

İptalin ne kadar acil olduğuna karar verin

Aktif kötüye kullanım belirtisi yoksa yeni anahtar ve sertifikayı hızla hazırlayıp yayına alın, ardından eskileri gecikmeden iptal ettirin. Yeni sertifikayı önce yayına almak, sızmış anahtarla çalışılan süreyi kısa tutarken iptal nedeniyle ziyaretçilerinizin sertifika hatasıyla karşılaşma riskini azaltır.

Aktif kötüye kullanım varsa yeni kurulumu beklemeden iptal talebini öne alın. Sertifikayı veren kuruluşun iptal kanalına anahtar sızıntısını, yani keyCompromise nedenini bildirin. Siteye erişimde sorun yaşanabilir. Ayrıca tarayıcıların ve diğer istemcilerin iptal kontrolü farklı olduğundan iptal, kötüye kullanımı her yerde anında durdurma garantisi değildir. İptal talebinden sonra da yeni anahtara geçişi tamamlayın.

Temiz ortamda yeni özel anahtar ve sertifika oluşturun

Bu örnekte sunucu ve sertifika işlemlerini yöneten ACME hesabı güvende kabul edildiğinden yeni anahtarı aynı Ubuntu sunucusunda üretebilirsiniz. İşlemleri sudo yetkili SSH oturumunda yapın. Yeni sertifikayı ayrı bir Certbot kaydında tutacağız; böylece Nginx’in mevcut sertifika yollarına dokunmadan yeni dosyaları hazırlayabilirsiniz.

Araçları kurun ve mevcut ayarları koruyun

Örnek ortamda Ubuntu 24.04 üzerinde Nginx zaten kurulu ve siteyi sunuyor; Certbot için Ubuntu paketleri kullanılıyor. Certbot sertifika başvurusunu, OpenSSL anahtar karşılaştırmasını, diğer araçlar DNS ve erişim kontrollerini yapacak. Sunucunun terminalinde paketleri kurun, ardından değişiklikten önce site ayarını yalnız root kullanıcısının erişebildiği olay dizinine kopyalayın:

sudo apt update
sudo apt install certbot openssl dnsutils curl
sudo install -d -m 700 /root/ssl-incident
sudo cp -a /etc/nginx/sites-available/example.com /root/ssl-incident/example.com.nginx.before
sudo certbot certificates

Son komutun çıktısında eski example.com kaydını görmelisiniz. Yeni kullanacağımız example-com-incident adı listede bulunmamalı; varsa devam etmeden bu kaydın hangi sertifikaya ait olduğunu ve nerede kullanıldığını belirleyin. Böylece mevcut bir kaydı yanlışlıkla değiştirmemiş olursunuz.

DNS ve HTTP doğrulamasını hazırlayın

DNS yönetim panelinizde iki adın A kayıtlarının bu sunucunun genel IPv4 adresini gösterdiğini kontrol edin. AAAA kaydı varsa IPv6 üzerinden de aynı siteye ulaşılmalı. Aşağıdaki ilk dört komutla yayınlanan DNS yanıtlarını inceleyin. Yanlış kayıt varsa geri dönüş için mevcut değerini kaydedip panelden düzeltin; doğru yanıt görünmeden sertifika başvurusu yapmayın. Son iki komut doğrulama dosyalarının dizinini oluşturur ve site ayarını nano düzenleyicisinde açar:

dig +short example.com A
dig +short example.com AAAA
dig +short www.example.com A
dig +short www.example.com AAAA
sudo install -d -m 755 /var/www/acme/.well-known/acme-challenge
sudo nano /etc/nginx/sites-available/example.com

Let’s Encrypt, HTTP-01 yönteminde alan adınız üzerinden geçici bir dosyayı okuyarak alan adını kontrol ettiğinizi doğrular. Bu doğrulama için 80 numaralı porta dışarıdan erişilebilmelidir. Açtığınız dosyada iki alan adını karşılayan listen 80 sunucu bloğuna aşağıdaki bölümü ekleyin. Buradaki root, doğrulama dosyalarının tutulacağı web kökünü belirtir:

location ^~ /.well-known/acme-challenge/ {
    root /var/www/acme;
    default_type text/plain;
    try_files $uri =404;
}

Sunucu bloğunda, location bölümlerinin dışında HTTPS’ye yönlendiren bir return varsa bu kural doğrulama isteğini de yönlendirir. Bu örnekte dosyanın doğrudan HTTP üzerinden okunması için yönlendirmeyi mevcut location / içine taşıyın; ikinci bir location / oluşturmayın. Dosyayı kaydettikten sonra aşağıdaki komutlarla ayarı test edin, test başarılıysa yeniden yükleyin ve dış erişimi sınamak için geçici bir dosya oluşturun:

sudo nginx -t && sudo systemctl reload nginx
printf 'acme-ok\n' | sudo tee /var/www/acme/.well-known/acme-challenge/probe

Test başarısızsa yeniden yükleme komutu çalışmaz. Hata verilen satırı düzeltin; hazırlık değişikliğini geri almak gerekirse olay dizinindeki example.com.nginx.before kopyasını özgün site dosyasının üzerine geri kopyalayıp testi tekrarlayın. Bu geri dönüş yalnız hazırlık ayarı içindir; sızmış anahtarı kullanmaya devam etmek için bir çözüm değildir.

Başka bir internet bağlantısındaki bilgisayarın terminalinde aşağıdaki iki komutu çalıştırın. İkisi de acme-ok döndürmeli. Bu yanıt, alan adlarının dışarıdan erişilebildiğini ve Nginx’in doğrulama dosyasını doğru dizinden sunduğunu gösterir:

curl --fail example.com/.well-known/acme-challenge/probe
curl --fail www.example.com/.well-known/acme-challenge/probe

Ayrı kayıt oluşturun ve anahtarın değiştiğini doğrulayın

İki adresten de beklenen yanıtı aldıktan sonra sunucunun terminaline dönün. Aşağıdaki komut, hazırladığınız web kökünü kullanarak iki alan adı için sertifika ister. Sorulursa takip ettiğiniz e-posta adresini girin ve hizmet koşullarını inceleyin. --duplicate aynı alan adları için ayrı kayıt açılmasını sağlar; certonly ise sertifikayı alır, Nginx’in sertifika yollarını değiştirmez. Komut aşağıda satırlara bölünmüş gösteriliyor; çalıştırmadan önce satırları aralarında boşluk bırakarak birleştirin:

sudo certbot certonly --webroot -w /var/www/acme 
  --cert-name example-com-incident --duplicate 
  -d example.com -d www.example.com

Yukarıdaki komutu terminalde tek satır olarak çalıştırın. Başarı çıktısında yeni dosyalar /etc/letsencrypt/live/example-com-incident/ altında görünmeli. Ardından eski sertifikanın açık anahtarıyla yeni özel anahtardan türetilen açık anahtarın SHA-256 özetlerini karşılaştırın. İlk iki komut bu özetleri gösterir; son komut artık gerekmeyen erişim denemesi dosyasını siler:

sudo openssl x509 -in /root/ssl-incident/old-cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256
sudo openssl pkey -in /etc/letsencrypt/live/example-com-incident/privkey.pem -pubout -outform DER | openssl dgst -sha256
sudo rm /var/www/acme/.well-known/acme-challenge/probe

İlk iki komuttaki tüm işlemler hatasız tamamlanmalı ve özetler farklı olmalı. Yalnız bir özet satırı görünmesi yeterli değildir; dosya okuma veya anahtar işleme hatası varsa karşılaştırmaya güvenmeyin. Hatasız elde edilen farklı özetler, eski anahtarın yeniden kullanılmadığını gösterir. Yeni sertifika artık hazırdır; Nginx hâlâ eski yolları kullandığından sıradaki işlem yeni sertifika ile anahtarın eşleşmesini kontrol edip dosyaları yayına almaktır.

Yeni sertifikayı yayına alın ve sızan sertifikayı iptal edin

Anahtar eşleşmesini kontrol edip Nginx yollarını değiştirin

Yeni sertifikayı yayına almadan önce doğru özel anahtarla eşleştiğini kontrol edin. Sunucunun SSH terminalinde aşağıdaki komutları çalıştırın. İkisi de hatasız tamamlanmalı ve açık anahtar için aynı SHA-256 özetini vermeli. Sertifika dosyasını okurken izin hatası alırsanız kontrolü root yetkili terminalde yapın; dosya izinlerini genişletmeyin.

openssl x509 -in /etc/letsencrypt/live/example-com-incident/cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256
sudo openssl pkey -in /etc/letsencrypt/live/example-com-incident/privkey.pem -pubout -outform DER | openssl dgst -sha256

Özetler farklıysa iki dosya yolunun da yeni oluşturduğunuz sertifika kaydına ait olduğunu kontrol edin. Eşleşme sağlandıktan sonra Nginx’in kullanacağı dosya yollarını değiştirmek için site ayarını açın:

sudo nano /etc/nginx/sites-available/example.com

example.com ve www.example.com için HTTPS sunan bloklardaki mevcut iki sertifika satırını aşağıdakilerle değiştirin. ssl_certificate sunucu sertifikası ile ara sertifikaları içeren zincir dosyasını, ssl_certificate_key ise özel anahtarı gösterir. Eski satırların yanına ikinci bir çift eklemek yerine mevcut yolları değiştirin.

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

Dosyayı kaydettikten sonra sunucuda aşağıdaki komutu çalıştırın. Bu komut önce Nginx ayarlarını test eder; yalnız test başarılıysa çalışan servise yeni ayarları yükler:

sudo nginx -t && sudo systemctl reload nginx

Test çıktısında syntax is ok ve test is successful mesajlarını görmelisiniz. Test hata verirse yeniden yükleme adımı çalışmaz ve Nginx mevcut ayarlarla hizmet vermeyi sürdürür. Belirtilen dosya veya satırı düzeltip tekrar deneyin. Önceki bölümde aldığınız ayar yedeğini karşılaştırma için kullanın; geri dönüş amacıyla sızmış anahtarı yeniden yayına almayın. Yeniden yükleme başarılı olduğunda dışarıdan hangi sertifikanın sunulduğunu kontrol edin.

Dışarıdan sunulan sertifikayı doğrulayın

Nginx testinin başarılı olması, ziyaretçilerin yeni sertifikayı gördüğünü tek başına kanıtlamaz. Karşılaştırma için önce sunucudaki yeni sertifikanın parmak izini alın. Bu değer, önceki adımda karşılaştırdığınız açık anahtar özetinden farklı olarak sertifikanın tamamını tanımlar:

openssl x509 -in /etc/letsencrypt/live/example-com-incident/cert.pem -noout -fingerprint -sha256

Ardından OpenSSL bulunan, başka bir internet bağlantısındaki bilgisayarın Bash terminalinde iki alan adını kontrol edin. -servername hangi sitenin sertifikasının istendiğini belirtir; doğrulama seçenekleri sertifikanın güven zincirini ve alan adıyla eşleşmesini denetler. Kontrol bilgisayarının güvenilir kök sertifika deposu güncel olmalıdır.

set -o pipefail
for host in example.com www.example.com; do
  printf '\n%s\n' "$host"
  openssl s_client -connect "${host}:443" -servername "$host" -verify_hostname "$host" -verify_return_error </dev/null | openssl x509 -noout -fingerprint -sha256
done

Her iki bağlantıda da doğrulama hatası olmamalı ve görünen sertifika parmak izi sunucudan aldığınız değerle aynı olmalı. Yalnız parmak izinin yazdırılmış olması yeterli değildir; hata çıktısını da inceleyin. IPv4 ve IPv6 birlikte yayınlanıyorsa s_client komutuna sırasıyla -4 ve -6 ekleyerek iki bağlantı yolunu ayrı ayrı sınayın.

Eski sertifikaları anahtar sızıntısı nedeniyle iptal edin

Aktif kötüye kullanım saptanmayan örnek senaryomuzda, yeni sertifikayı dışarıdan doğruladıktan hemen sonra eski sertifika için iptal isteği gönderin. Sunucunun SSH terminalinde çalıştıracağınız komut, olay dizininde koruduğunuz eski sertifikayı kullanır. keycompromise, özel anahtarın sızdığını bildiren iptal nedenidir:

sudo certbot revoke --cert-path /root/ssl-incident/old-cert.pem --reason keycompromise --no-delete-after-revoke

Bu işlem, güvende olduğunu varsaydığımız mevcut ACME hesabıyla, yani otomatik sertifika işlemlerini yöneten hesapla yetkilendirilir. --no-delete-after-revoke seçeneği iptalden sonra yerel sertifika kaydını korur; dosyayı silmek sertifikayı iptal etmez. Aynı sızmış anahtara bağlı diğer geçerli sertifikalar için de ilgili sertifika dosyasını kullanarak işlemi tekrarlayın.

Certbot çıktısında iptal isteğinin başarıyla tamamlandığını kontrol edin. Hata veya belirsiz yanıt varsa /var/log/letsencrypt/letsencrypt.log kaydını inceleyin; gerekirse sertifikayı veren kuruluşun iptal kanalından teyit alın. Başarı yanıtını olay kaydına ekleyin. Tarayıcıdaki kilit simgesi eski sertifikanın iptal edildiğini kanıtlamaz; istemcilerin iptal bilgisini kontrol etme ve uygulama biçimi farklı olabilir.

Kurulum sorunlarını ayırın ve yeniden sızıntıyı önleyin

Eski sertifika ve doğrulama hatasını ayırın

Dış kontrolde eski sertifika görünüyorsa önce IPv4 ve IPv6 sonuçlarını karşılaştırın. Yalnız birinde eski sertifika sunuluyorsa ilgili DNS kaydı başka bir sunucuya gidiyor olabilir. İkisinde de eski sertifika görünüyorsa Ubuntu sunucusunun SSH terminalinde Nginx’in okuduğu ayarları ve yeniden yükleme kayıtlarını inceleyin:

sudo nginx -T 2>&1 | grep -E 'server_name|ssl_certificate'
sudo journalctl -u nginx -n 30 --no-pager

İlgili alan adının HTTPS bloğu example-com-incident yollarını kullanmalı. Yanlış yol veya aynı alan adını karşılayan çakışan bir blok bulursanız site dosyasının mevcut kopyasını koruyup yalnız ilgili ayarı düzeltin. Ardından sudo nginx -t && sudo systemctl reload nginx komutunu çalıştırın ve dış parmak izi kontrolünü tekrarlayın. Böylece düzeltmenin yalnız dosyada kalmadığını, ziyaretçiye sunulan sertifikaya da yansıdığını görebilirsiniz.

Alan adı doğrulaması başarısızsa önceki bölümdeki probe dosyasını yeniden oluşturup iki adrese de sunucu dışından erişmeyi deneyin. 404 yanıtı, isteğin bir web sunucusuna ulaştığını ancak dosyanın bulunamadığını gösterir; web kökünü, isteği karşılayan sunucu bloğunu ve yönlendirmeleri inceleyin. Zaman aşımında DNS yanıtlarını, güvenlik duvarını ve 80 numaralı port erişimini kontrol edin. Bulguyla ilgili ayarı düzelttikten sonra dosyanın içeriğini iki adresten de okuyabildiğinizi görün; sertifika başvurusunu bundan sonra tekrarlayın.

Anahtar izinlerini dar kapsamda düzeltin

Permission denied, yani erişim izni hatası alırsanız önce sunucuda anahtar bağlantısının hangi gerçek dosyaya gittiğini ve üst dizinlerin izinlerini inceleyin:

sudo namei -l /etc/letsencrypt/live/example-com-incident/privkey.pem
sudo systemctl show nginx -p User

Standart Ubuntu Nginx servisinde ana süreç root olarak başlar; servis çıktısındaki boş User= alanı da bu düzende beklenir. Ana süreç sertifikayı ve anahtarı okuyabildiği için anahtarı www-data kullanıcısına açmanız gerekmez. Çıktıda yeni anahtarın sahipliği veya dosya izinleri yanlışsa mevcut değerleri olay kaydına not edin ve yalnız bu anahtarın hedef dosyasını düzeltin:

sudo chown root:root /etc/letsencrypt/live/example-com-incident/privkey.pem
sudo chmod 600 /etc/letsencrypt/live/example-com-incident/privkey.pem
sudo nginx -t

Bu ayarlar anahtarı yalnız root kullanıcısının okuyup yazabileceği hale getirir. Nginx testi başarılıysa erişim sorunu giderilmiştir; bekleyen ayar değişikliğini önceki test ve yeniden yükleme adımıyla yayına alabilirsiniz. Test hâlâ başarısızsa hata mesajındaki yolu ve üst dizinlere erişimi inceleyin; tüm /etc/letsencrypt ağacına toplu izin vermek yerine sorunun bulunduğu dosya veya dizine odaklanın.

Yenileme ve yeniden yüklemeyi birlikte sınayın

Yeni sertifikanın bugün çalışması, sonraki yenilemenin de sorunsuz olacağını göstermez. Sunucunun SSH terminalinde önce yeni kaydın deneme yenilemesini çalıştırın ve bu örnekte paketle kurulan Certbot zamanlayıcısının durumuna bakın:

sudo certbot renew --cert-name example-com-incident --dry-run
sudo systemctl status certbot.timer --no-pager

--dry-run canlı sertifikayı değiştirmeden yenileme akışını sınar; çıktıda denemenin başarılı olduğunu görmelisiniz. Zamanlayıcı etkin değilse sudo systemctl enable --now certbot.timer çalıştırın ve durum komutuyla etkinleştiğini kontrol edin.

Sertifika yenilendiğinde Nginx’in yeni dosyaları okuması için bir deploy hook, yani başarılı yenileme sonrası çalışacak betik ekleyin. Aşağıdaki reload-nginx.sh dosyası zaten varsa komutları çalıştırmadan önce dosyayı korumalı olay dizinine kopyalayın ve içeriğini inceleyin; mevcut başka işlemleri yanlışlıkla kaldırmayın. Betik değişikliği sorun çıkarırsa bu kopyayı geri yükleyebilirsiniz; bunun için sızmış anahtara dönmeniz gerekmez.

sudo install -d -m 755 /etc/letsencrypt/renewal-hooks/deploy
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
/usr/sbin/nginx -t && /usr/bin/systemctl reload nginx
EOF
sudo chmod 750 /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
sudo certbot renew --cert-name example-com-incident --dry-run --run-deploy-hooks

Bu ikinci deneme, başarılı yenilemenin ardından betiği de çalıştırır ve Nginx’i mevcut canlı sertifikayla yeniden yükler. Çıktıda hem yenileme denemesinin hem betiğin hatasız tamamlandığını kontrol edin.

Eski kaydı kaldırmadan önce sertifika iptalinin başarıyla tamamlandığından ve Nginx dışında hiçbir servisin eski sertifika yollarını kullanmadığından emin olun. Gerekli olay kayıtlarını erişimi kısıtlı dizinde koruduktan sonra sudo certbot delete --cert-name example.com ile eski Certbot kaydını ve ona bağlı yerel sertifika dosyalarını kaldırın. Bu işlem sertifika iptalinin yerine geçmez; kullanılmayan kaydın yeniden yenilenmesini önler.

Git geçmişini temizleyin ve diğer uçları kontrol edin

Dosyayı son commit’ten, yani son kayıtlı değişiklikten silmek geçmiş kopyalarını kaldırmaz. Geçmişi temizlerken yeni değişikliklerle çakışmamak için depoya yazmayı geçici durdurun; önce erişimi kısıtlı olay arşivinde geçmişin kopyasını koruyun. Bu arşiv sızmış anahtarı da içerebileceğinden normal proje yedeği gibi paylaşılmamalıdır.

Git geçmişini yeniden yazan git-filter-repo aracıyla dosyayı geçmişte bulunduğu tüm yollardan çıkarın; yalnız bugünkü dosya adını temizlemek eski adları kaçırabilir. Ardından deponuzun barındırma hizmetindeki hassas veri temizleme sürecini uygulayın, dal ve etiketleri güncelleyin ve ekipten temiz depoyu yeniden klonlamasını isteyin. Fork olarak oluşturulan depo kopyalarını, önbellekleri ve indirilmiş dosyaları tamamen geri alamazsınız. Bu yüzden geçmiş temizliği, anahtar değişiminin ve sertifika iptalinin yerine geçmez.

Yeni anahtarı Git’e, destek kaydına veya uygulama paketine koymayın. .gitignore yalnız ek korumadır; Git’in zaten izlediği dosyaları korumaz. VPS üzerinde gizli anahtar yönetimi yaklaşımıyla anahtarı web kökünün dışında, yalnız gerekli servis erişimiyle tutun. Depoya gönderim öncesinde özel anahtar ve parola gibi sırları arayan bir tarama eklemek, aynı hatanın tekrarlanmasını önlemeye yardımcı olur.

Örneğimizde CDN, yani içerik dağıtım ağı yoktur. HTTPS bağlantısını CDN üzerinde sonlandırıyorsanız ziyaretçiye sunulan sertifika ile kaynak sunucudaki sertifika ayrı yönetilir. Sızan anahtar hangi noktada kullanılıyorsa değişim ve iptal işlemlerini orada yapın; aynı anahtar iki tarafta da kullanılıyorsa ikisini de kapsama alın. CDN arkasında Full (Strict) SSL kurulumu bu iki bağlantının nasıl korunduğunu açıklar.

cPanel veya Plesk kullanıyorsanız ilgili alan adının SSL/TLS yönetim ekranında yeni özel anahtarı, sertifikayı ve ara sertifika zincirini birlikte yükleyin. Yalnız sertifikayı yeniden düzenletmek anahtarı değiştirmeyebilir; başka sağlayıcılarda da başvuruyu yeni anahtarla yapın. Let’s Encrypt’ten wildcard, yani aynı düzeydeki alt alan adlarını kapsayan joker sertifika alırken HTTP-01 yerine DNS kaydıyla alan adı kontrolünü kanıtlayan DNS-01 doğrulaması gerekir. DNS-01 ile wildcard sertifika otomasyonu bu alternatif akışı açıklar; otomasyonda kullanılan DNS erişim anahtarlarını da sır olarak koruyun.

Sık Sorulan Sorular

Sızan özel anahtarla geçmiş HTTPS trafiği çözülebilir mi?

Her bağlantı için değil; yanıt, bağlantı kurulurken kullanılan anahtar değişimi yöntemine bağlıdır. İleri gizlilik, oturuma özel geçici anahtarlar sayesinde sertifikanın özel anahtarı sonradan sızsa bile geçmiş trafiği korur. HTTPS bağlantısını koruyan TLS protokolünün 1.3 sürümünü kullanan bağlantılar ve TLS 1.2’de ECDHE gibi geçici anahtar değişimi kullanan bağlantılar, yalnız sertifika özel anahtarının ele geçirilmesiyle çözülemez.

Eski TLS bağlantılarında RSA anahtar değişimi kullanılmışsa saldırganın daha önce kaydettiği trafik sızan anahtarla çözülebilir. Sertifikanın RSA olması tek başına bu riskin bulunduğunu göstermez; bağlantıda kullanılan anahtar değişimi belirleyicidir. Geçmiş riski değerlendirirken olay dönemindeki TLS ayarlarına ve varsa bağlantı kayıtlarına bakın. Bugünkü ayarlar, geçmiş bağlantıların nasıl kurulduğunu kanıtlamaz.

WordPress ve müşteri parolalarını da değiştirmeli misiniz?

Yalnız SSL özel anahtarının sızması, WordPress parolalarının veya veritabanının ele geçirildiğini göstermez. Örnek senaryodaki gibi sızıntı tek dosyayla sınırlıysa ve başka bir kötüye kullanım bulgusu yoksa tüm kullanıcılara otomatik olarak parola sıfırlatmak gerekmez.

Ancak aynı depoda veritabanı parolası, erişim anahtarı veya oturumların doğruluğunu denetlemek için kullanılan bir imzalama sırrı da açığa çıktıysa bunları ayrı ayrı değiştirin. Sahte site üzerinden giriş bilgilerinin toplandığına, sunucuya izinsiz erişildiğine veya parola içeren trafiğin çözülebildiğine dair bulgu varsa etkilenen hesapların parolalarını sıfırlayın ve oturumlarını sonlandırın. Kararınızı yalnız anahtarın sızmasına değil, açığa çıkan veriye ve izinsiz erişimin kapsamına göre verin.

CSR dosyasını paylaşmak özel anahtar sızıntısı mıdır?

Hayır. CSR, sertifika imzalama isteğidir; açık anahtarı ve sertifika başvurusu bilgilerini taşır, özel anahtarı içermez. Normal bir CSR’den özel anahtar çıkarılamaz. Yine de içindeki alan adı veya kuruluş bilgilerini herkese açıklamak istemeyebilirsiniz.

Dosya uzantısına güvenmek yerine dosyanın içindeki başlık satırını kontrol edin. BEGIN CERTIFICATE REQUEST bir isteği, BEGIN PRIVATE KEY veya BEGIN RSA PRIVATE KEY ise özel anahtarı işaret eder. Bunlar yaygın başlık örnekleridir; farklı bir başlık görmeniz dosyanın paylaşılmasının güvenli olduğunu göstermez. Destek kaydına gönderdiğiniz pakette CSR yanında özel anahtar dosyasının bulunmadığını da kontrol edin.

HSTS açıksa sızıntıya karşı korunmuş olur musunuz?

Hayır. HSTS, tarayıcıya siteye yalnız HTTPS üzerinden bağlanmasını söyleyen güvenlik politikasıdır. Bağlantının şifrelenmemiş HTTP’ye düşürülmesini önlemeye yardımcı olur; özel anahtarı değiştirmez veya sertifikayı iptal etmez.

Saldırgan trafiği kendisine yönlendirebiliyor ve tarayıcının hâlâ kabul ettiği sertifikayla sızan anahtarı kullanabiliyorsa HSTS tek başına yeterli değildir. HSTS’yi açık tutun; ancak bunu anahtar değişiminin ve sertifika iptalinin yerine koymayın. HSTS, bu işlemlerden ayrı olarak HTTPS bağlantı politikanızı korumaya devam eder.

Müdahaleyi kapatmadan önce kontrol listesi

Tarayıcıda sitenin açılması, müdahalenin tamamlandığını tek başına göstermez. Olay kaydını kapatmadan önce aşağıdaki maddelerin her birini kontrol edin. Doğrulama çıktılarını, özel anahtarı içermeyecek şekilde korumalı olay dizininde saklayın.

• Yeni anahtar gerçekten farklı: Yeni ve eski anahtardan türetilen açık anahtarların parmak izleri farklı; yeni sertifikanın açık anahtarı ise yeni özel anahtarla eşleşiyor. Bu iki kontrol, hem sızan anahtarın değiştiğini hem de yeni sertifikanın doğru anahtarla kullanılacağını gösterir.
• Tüm adreslerde doğru sertifika sunuluyor: Sunucu dışından hem example.com hem www.example.com için kontrol tamamlandı. IPv4 ve IPv6 birlikte kullanılıyorsa ikisi de sınandı. Sunulan sertifikanın parmak izi yeni sertifikayla aynı; alan adı eşleşmesi ve sertifika zinciri kontrolleri hatasız.
• Sızan anahtara bağlı eski sertifikalar iptal edildi: Eski sertifikaları yalnız Nginx’ten kaldırmakla yetinilmedi. Belirlenen, süresi dolmamış eski sertifikaların her biri için keyCompromise nedeniyle yapılan iptalin başarı yanıtı kaydedildi. Eski Certbot kaydının silinmesi, iptal kanıtı olarak kullanılmadı.
• Sızıntıya açık erişimler kapatıldı: Git deposundaki dosya ve geçmiş kopyaları için temizlik yapıldı; barındırma hizmetindeki erişim ve önbellek işlemleri takip edildi. Bu temizliğin daha önce indirilmiş kopyaları geri almadığı hesaba katıldı. Yeni anahtar Git deposunda, web kökünde veya destek eklerinde bulunmuyor. Olay kanıtlarına yalnız yetkili kişiler erişebiliyor.
• Yenileme ve yeniden yükleme sınandı: example-com-incident kaydının deneme yenilemesi başarılı, Certbot zamanlayıcısı etkin ve yenileme sonrası Nginx’i yeniden yükleyen betik çalışıyor. Hiçbir etkin servis veya geri dönüş planı sızmış anahtara dayanmıyor.

Bu kontrollerden biri eksikse olay kaydında açık iş olarak bırakın; sorumlusunu ve hedef tamamlanma tarihini yazın. Sertifikayı değiştirmeyi ve sızıntının kaynağını gidermeyi ayrı işler olarak takip edin. Böylece site yeniden güvenli sertifika sunmaya başladığında, sızıntıya yol açan sorunu da çözülmüş saymazsınız.

Bir sonraki adımınız, anahtarın Git’e nasıl girdiğini bulmak olsun. Dağıtım betiği sunucudaki anahtarları proje dizinine kopyalıyorsa bu adımı kaldırın. Dosya yanlışlıkla eklenmişse depoya gönderim öncesinde özel anahtar ve parola gibi gizli bilgileri arayan bir tarama ve inceleme kuralı ekleyin. Düzeltmeyi gerçek anahtarı yeniden paylaşmadan kontrol edin ve aldığınız önlemi olay kaydına yazın.