Plesk Let’s Encrypt Yenileme Hatası Nasıl Çözülür? DNS, HTTP Doğrulama ve Log Rehberi

Plesk Let’s Encrypt yenileme hatası, alan adının sertifika yenileme anında doğrulanamaması nedeniyle ortaya çıkar. Plesk, Let’s Encrypt uzantısı üzerinden sertifikayı otomatik yenilemeye çalışır; ancak DNS kaydı yanlış sunucuyu gösteriyorsa, HTTP-01 doğrulama yolu engelleniyorsa, CAA kaydı yetki vermiyorsa veya alan adı proxy arkasında hatalı yönlendiriliyorsa işlem başarısız olur. Sorun yalnızca ana alan adını değil, www, alt alan adları ve posta hizmetleri için eklenen adları da etkileyebilir. Bu rehberde Plesk Let’s Encrypt yenileme hatasını loglarla doğrulayıp, en düşük riskli kontrollerden başlayarak güvenle gidereceksiniz.

Belirti ve kapsam: Yenileme hatası neyi etkiler?

Plesk panelinde Tools & Settings > SSL/TLS Certificates veya ilgili aboneliğin Let’s Encrypt ekranında yenileme başarısız mesajı görülebilir. Bazı kurulumlarda Plesk bildirimi ya da e-posta uyarısı da gönderilir.

Sertifikanın mevcut bitiş tarihine kadar web sitesi normal çalışabilir. Ancak süre dolduğunda ziyaretçiler tarayıcı sertifika uyarısı görür. SMTP, IMAP veya FTP gibi servislerde aynı sertifika kullanılıyorsa istemci bağlantıları da etkilenebilir.

Plesk Let’s Encrypt yenileme hatası için hızlı teşhis özeti

• Önce sertifikanın bitiş tarihini ve yenilemeye dahil edilen alan adlarını belirleyin.
• Her alan adının genel DNS çözümlemesinin doğru IPv4/IPv6 adresine gittiğini kontrol edin.
• /.well-known/acme-challenge/ yolunun internete açık olduğunu, yönlendirme veya güvenlik katmanında engellenmediğini doğrulayın.
• CAA kaydı varsa Let’s Encrypt yetkisini kontrol edin.
• Plesk ve alan adı seviyesindeki loglardan ACME hata metnini okuyun.
• Yalnızca hatanın nedenini düzelttikten sonra Plesk üzerinden yeniden sertifika isteği gönderin.

Önemli: Sertifikayı art arda ve rastgele yeniden istemeyin. Let’s Encrypt, başarısız doğrulama ve sertifika düzenleme istekleri için oran sınırları uygular. Önce teşhis, sonra kontrollü tek bir yenileme denemesi daha güvenlidir.

Yaygın nedenler ve hata mesajlarının anlamı

Belirti veya hata	Muhtemel neden	İlk kontrol
DNS problem: NXDOMAIN	Alan adı ya da eklenen alt alan adı için DNS kaydı yoktur.	A/AAAA ve CNAME kayıtlarını genel DNS sunucularından sorgulayın.
Timeout during connect	80 numaralı port kapalı, yanlış IP hedefi, güvenlik duvarı veya proxy sorunu vardır.	Dış ağdan HTTP erişimini test edin.
Invalid response / 404	ACME doğrulama dosyasına web sunucusu erişemiyor veya uygulama yönlendirmesi isteği yakalıyordur.	/.well-known/acme-challenge/ yolunu inceleyin.
CAA ile ilgili hata	CAA kaydı Let’s Encrypt’i yetkili sertifika otoritesi olarak tanımlamıyordur.	CAA kayıtlarını sorgulayın.
unauthorized	Doğrulama isteği beklenen içerik yerine başka bir yanıt almıştır.	DNS hedefi, proxy, yönlendirme ve sanal host eşleşmesini kontrol edin.
rateLimited	Çok sayıda hatalı istek veya sertifika talebi yapılmıştır.	İsteği durdurun; hata nedenini düzeltip limit penceresinin dolmasını bekleyin.

Tanı koymadan önce güvenlik ve hazırlık

DNS, web sunucusu yapılandırması veya güvenlik duvarı değişiklikleri üretim trafiğini etkileyebilir. Değişiklik yapmadan önce geçerli DNS kayıtlarını, Plesk abonelik ayarlarını ve özel web sunucusu ek yapılandırmalarını kaydedin. Mümkünse işlemi bakım penceresinde uygulayın.

Özellikle ters proxy, CDN, WAF, özel Nginx/Apache kuralları veya harici DNS sağlayıcısı kullanılan ortamlarda önce değişikliğin sorumlusunu belirleyin. Plesk’in yönetmediği DNS bölgesinde yapılan panel değişiklikleri, yetkili DNS sunucularına yansımayabilir.

Loglar ve komutlarla güvenli teşhis

1. Sertifika bitiş tarihini dışarıdan kontrol edin

Aşağıdaki komutu Plesk sunucusundan veya OpenSSL bulunan başka bir Linux sisteminden çalıştırabilirsiniz. alanadiniz.tld bölümünü gerçek alan adıyla değiştirin.

openssl s_client -connect alanadiniz.tld:443 -servername alanadiniz.tld </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Bu kontrol, istemcilere şu an hangi sertifikanın sunulduğunu gösterir. CDN veya yük dengeleyici kullanılıyorsa sonuç, doğrudan Plesk sunucusundaki sertifikadan farklı olabilir.

2. DNS çözümlemesini A, AAAA ve CAA kayıtlarıyla inceleyin

Linux sistemlerde dig ile hem IPv4 hem IPv6 hedeflerini kontrol edin:

dig +short A alanadiniz.tld
dig +short AAAA alanadiniz.tld
dig +short CAA alanadiniz.tld
dig +short A www.alanadiniz.tld
dig +short AAAA www.alanadiniz.tld

Windows üzerinde PowerShell kullanıyorsanız:

Resolve-DnsName alanadiniz.tld -Type A
Resolve-DnsName alanadiniz.tld -Type AAAA
Resolve-DnsName alanadiniz.tld -Type CAA

A kaydı Plesk sunucusunun erişilebilir genel IPv4 adresine gitmelidir. Bir AAAA kaydı mevcutsa Let’s Encrypt doğrulaması IPv6 üzerinden de erişim kurabilir. Sunucuda IPv6 yapılandırılmamış, web sunucusu dinlemiyor veya güvenlik duvarı IPv6/80 trafiğini engelliyorsa kullanılmayan AAAA kaydı yenilemeyi bozabilir. IPv6 hizmet vermiyorsanız AAAA kaydını DNS yöneticinizden kaldırmak; hizmet veriyorsanız IPv6 erişimini düzeltmek gerekir.

CAA kaydı kullanılıyorsa kayıtlardan en az birinin Let’s Encrypt düzenlemesine izin verdiğinden emin olun. Örnek yetkilendirme değeri aşağıdaki biçimdedir:

0 issue "letsencrypt.org"

CAA değişikliği DNS sağlayıcısının panelinden yapılır. Mevcut CAA politikanız başka sertifika otoritelerini veya wildcard sertifikaları da kapsıyorsa, kaydı silmek yerine mevcut politikanın etkisini anlayarak düzenleyin.

3. HTTP-01 doğrulama yoluna erişimi test edin

Plesk Let’s Encrypt uzantısı çoğu standart kurulumda HTTP-01 doğrulamasını kullanır. Let’s Encrypt, alan adında 80 numaralı port üzerinden aşağıdaki yolun altına erişmeye çalışır:

http://alanadiniz.tld/.well-known/acme-challenge/<dogrulama-degeri>

Belirli doğrulama değeri yalnızca sertifika isteği sırasında oluşur. Yine de HTTP erişimi ve yönlendirme davranışını şu komutla denetleyebilirsiniz:

curl -I -L --max-redirs 10 http://alanadiniz.tld/.well-known/acme-challenge/test

404 Not Found tek başına bu örnek dosya bulunmadığı için normal olabilir. Kritik nokta; alan adının doğru hedefe ulaşması, bağlantının zaman aşımına uğramaması, erişimin kimlik doğrulama ekranına düşmemesi ve yönlendirme zincirinin bozuk olmamasıdır. 403, bağlantı zaman aşımı veya farklı bir sitenin yanıtı araştırılmalıdır.

4. Plesk ve alan adı loglarını okuyun

Plesk for Linux’ta panel işlemleri için ana log dosyası genellikle aşağıdaki konumdadır:

sudo tail -n 200 /usr/local/psa/admin/logs/panel.log

Alan adı web erişim günlükleri Plesk sürümüne ve abonelik adına göre aşağıdaki dizin yapısında bulunur:

sudo tail -n 100 /var/www/vhosts/system/alanadiniz.tld/logs/proxy_access_log
sudo tail -n 100 /var/www/vhosts/system/alanadiniz.tld/logs/proxy_error_log

Bu dosyalar her yapılandırmada aynı olmayabilir. Dosya bulunamazsa, alan adının Plesk’teki sistem kullanıcısını ve günlük dizinlerini panelden kontrol edin; rastgele dosya oluşturmayın veya izin değiştirmeyin.

Plesk for Windows kullanıyorsanız Linux dosya yollarını kullanmayın. Panel günlükleri çoğunlukla %plesk_dir%admin\logs\panel.log altında yer alır. Yönetici Komut İstemi’nde değişkeni doğrulamak için:

echo %plesk_dir%

Plesk Let’s Encrypt yenileme hatasını adım adım çözme

1. Yenilemeye dahil edilen tüm adları kontrol edin

Plesk’te ilgili aboneliği açın, Let’s Encrypt ekranına gidin ve sertifikaya eklenen alan adlarını inceleyin. Ana alan adı, www, posta alan adı ve seçilmiş alt alan adlarından yalnızca biri hatalı olsa bile tek sertifika talebi başarısız olabilir.

Artık kullanılmayan bir alt alan adı sertifikada gerekmiyorsa, önce hizmet bağımlılığını doğrulayın; ardından sertifika kapsamından çıkarın. Kullanılması gereken her ad için DNS ve web erişimini ayrı ayrı test edin.

2. DNS hedefini düzeltin ve yayılımı bekleyin

Yanlış A/AAAA veya CNAME kaydını yetkili DNS sağlayıcısında düzeltin. Alan adı Cloudflare gibi proxy hizmeti kullanıyorsa, sertifika isteği sırasında proxy/WAF kurallarının ACME isteğini engellemediğinden emin olun. DNS değişikliğinin ardından yalnızca yerel bilgisayar önbelleğine değil, genel çözümlemeye de bakın.

dig @1.1.1.1 +short A alanadiniz.tld
dig @8.8.8.8 +short A alanadiniz.tld

TTL ve sağlayıcı yayılım süresi tamamlanmadan Plesk üzerinden tekrar tekrar yenileme denemesi yapmayın.

3. Port 80, yönlendirme ve erişim engellerini giderin

HTTP-01 için 80/TCP erişimi gereklidir. Kalıcı HTTP-HTTPS yönlendirmesi çoğunlukla sorun değildir; ancak yönlendirme sonunda erişilemeyen bir hedef, oturum açma sayfası, IP tabanlı engel veya hatalı farklı alan adı oluşmamalıdır.

Sunucu güvenlik duvarı, bulut güvenlik grubu, CDN/WAF ve ağ güvenlik cihazlarında TCP/80 erişimini kontrol edin. UFW kullanılan Debian/Ubuntu tabanlı sistemlerde yalnızca mevcut kuralları görüntülemek için:

sudo ufw status verbose

firewalld kullanılan RHEL, AlmaLinux veya Rocky Linux sistemlerinde:

sudo firewall-cmd --list-services
sudo firewall-cmd --list-ports

Plesk sunucusunda özel Apache/Nginx ek direktifleri, uygulama yönlendirmeleri veya erişim sınırlamaları varsa /.well-known/acme-challenge/ yolunu engelleyip engellemediğini inceleyin. Kural değişikliğinden önce yapılandırmanın yedeğini alın ve değişikliği geri döndürülebilir tutun.

4. CAA yetkisini düzeltin

CAA sorgusunda Let’s Encrypt’i dışlayan bir politika görünüyorsa DNS kaydını güncelleyin. Birden fazla CAA kaydının birlikte değerlendirildiğini unutmayın. Kurumsal politika gereği yalnızca belirli otoriteler izinliyse, değişikliği DNS yöneticisi ve güvenlik sorumlusu ile onaylayın.

5. Plesk üzerinden tek ve kontrollü yenileme başlatın

DNS, erişim ve CAA kontrolleri temizlendikten sonra ilgili alan adının Let’s Encrypt ekranından sertifika isteğini yeniden çalıştırın. Başarısız olursa Plesk’in gösterdiği tam hata metnini ve panel.log içindeki aynı zaman damgasına ait kaydı inceleyin. Genel hata yerine bu metin, sorunun hangi alan adında ve hangi doğrulama aşamasında oluştuğunu belirtir.

Yenilemenin başarılı olduğunu doğrulama

Plesk ekranında yeni sertifikanın bitiş tarihi güncellenmelidir. Ardından dışarıdan yeniden kontrol yapın:

openssl s_client -connect alanadiniz.tld:443 -servername alanadiniz.tld </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Çıktıdaki notAfter tarihi yeni dönemi göstermelidir. Sertifika Plesk’te yenilenmiş ancak dışarıda eski görünüyorsa CDN, yük dengeleyici, ters proxy veya farklı IP’ye yönlenen DNS kaydı üzerinde eski sertifika sunuluyor olabilir.

Tekrarını önleme

• Sertifikaya yalnızca gerçekten kullanılan alan adlarını ekleyin.
• DNS değişikliği süreçlerinde A, AAAA, CNAME ve CAA kayıtlarını birlikte gözden geçirin.
• 80/TCP erişimini kalıcı olarak kapatmadan önce ACME doğrulama yöntemine etkisini değerlendirin.
• WAF ve proxy istisnalarını, özellikle /.well-known/acme-challenge/ yolu için değişiklik yönetimine dahil edin.
• Plesk bildirim e-postalarının geçerli bir yönetici adresine ulaştığını düzenli olarak kontrol edin.

Sonuç

Plesk Let’s Encrypt yenileme hatası çoğu durumda sertifika yazılımından değil; yanlış DNS hedefi, erişilemeyen HTTP-01 yolu, sorunlu IPv6 kaydı, CAA kısıtı veya aradaki proxy ve güvenlik katmanlarından kaynaklanır. Alan adlarını tek tek doğrulamak, logdaki gerçek ACME hata metnini okumak ve ardından yalnızca gerekli düzeltmeyi uygulamak; hem kesinti hem de oran sınırı riskini azaltır.

Sık sorulan sorular

Let’s Encrypt yenilemesi için 443 portu yeterli mi?

Hayır. Plesk Let’s Encrypt uzantısının yaygın HTTP-01 doğrulamasında doğrulama isteği 80/TCP üzerinden yapılır. HTTPS yönlendirmesi kullanılabilir, ancak HTTP isteği erişilebilir olmalıdır.

AAAA kaydını silmek güvenli midir?

Sunucunuz alan adı için çalışan IPv6 web hizmeti sunmuyorsa, hatalı AAAA kaydını kaldırmak uygun olabilir. Ancak IPv6 kullanan başka hizmetler veya bağımlılıklar varsa önce bunları değerlendirin.

Cloudflare proxy kullanırken sertifika yenilenebilir mi?

Evet, ancak alan adı doğrulama isteği proxy ve WAF kurallarından geçebilmelidir. Ayrıca Plesk kaynak sunucusundaki ve Cloudflare kenarındaki sertifikaların farklı olabileceğini doğrulayın.

Yenilemeyi kaç kez tekrar deneyebilirim?

Sabit bir deneme sayısına güvenmeyin. Let’s Encrypt oran sınırları uygular. Hata nedenini loglardan çözmeden tekrarlanan denemeler yapmak geçici engellemelere yol açabilir.

Plesk’te sertifika yenilendi ama tarayıcı eski sertifikayı gösteriyor. Neden?

DNS farklı bir IP’ye gidiyor olabilir veya CDN, yük dengeleyici ya da ters proxy eski sertifikayı sunuyor olabilir. openssl s_client ile alan adını dışarıdan kontrol edip sertifika sunan katmanı belirleyin.