cPanel AutoSSL HTTP DCV 404 Hatası: SSL Yenilemesini Güvenle Düzeltme

cPanel SSL sertifikası yenilenmiyor şikâyetinde AutoSSL günlüğünde HTTP 404, 404 Not Found veya geçici DCV dosyasına erişilemediği yönünde bir kayıt görülüyorsa sorun çoğunlukla alan adının doğrulama dosyasını sunamamasıdır. AutoSSL, sertifikayı yenilemeden önce alan adını kontrol edebildiğini doğrulamak için web kökünde geçici bir dosya oluşturur ve dış ağdan bu dosyaya ulaşmayı dener. Bu rehber, özellikle HTTP tabanlı Domain Control Validation (DCV) sırasında oluşan 404 hatasını; DNS, belge kökü, Apache/LiteSpeed davranışı, zorunlu yönlendirmeler ve ters proxy katmanları üzerinden güvenli biçimde çözmeye odaklanır.

Belirti ve kapsam: HTTP DCV 404 ne anlama gelir?

AutoSSL işlemi sırasında cPanel, doğrulanacak alan adı için geçici bir doğrulama dosyası yayımlar. Sertifika otoritesi veya cPanel’in doğrulama denetimi bu dosyayı HTTP üzerinden çağırır. İstek hedefe ulaştığı hâlde sunucu 404 döndürüyorsa, alan adı genellikle doğru bir web sunucusuna yanıt veriyor; ancak istenen geçici dosya doğru belge kökünden servis edilmiyor demektir.

Bu sorun, yalnızca ana alan adını değil; www, alt alan adları ve sertifika kapsamına eklenen diğer adları da etkileyebilir. Bir alan adındaki DCV başarısızlığı, günlükteki nedene ve AutoSSL yapılandırmasına bağlı olarak sertifika kapsamının daralmasına veya yenilemenin tamamen başarısız görünmesine yol açabilir.

Hızlı teşhis özeti

• AutoSSL günlüğünde başarısız olan tam alan adını ve HTTP durum kodunu belirleyin.
• Alan adının A/AAAA kayıtlarının bu cPanel sunucusuna yöneldiğini doğrulayın.
• HTTP/80 erişiminin dış dünyaya açık olduğundan emin olun.
• Alan adının gerçek belge kökünü cPanel alan adı yapılandırmasından kontrol edin.
• .well-known dizinini engelleyen yönlendirme, güvenlik kuralı, uygulama rotası veya proxy davranışını inceleyin.
• Düzeltmeden sonra yalnızca ilgili cPanel hesabı için AutoSSL denetimini yeniden çalıştırın.

Olası nedenler ve ayırt etme yöntemi

Olası neden	Tipik belirti	Güvenli kontrol
Yanlış A veya AAAA kaydı	İstek başka bir sunucudan 404 döner	Yetkili DNS yanıtını ve sunucu IP’sini karşılaştırın
Yanlış belge kökü	Site açılır, DCV dosyası görünmez	cPanel Domains ekranındaki belge kökünü doğrulayın
HTTP’den HTTPS’ye sorunlu yönlendirme	HTTP isteği farklı hosta veya uygulamaya gider	curl -I -L ile yönlendirme zincirini inceleyin
Proxy/CDN veya WAF müdahalesi	Beklenmeyen 404, 403 ya da özel hata sayfası	Doğrudan origin testi ve erişim günlüklerini karşılaştırın
Uygulama/.htaccess kuralı	/.well-known/ isteği uygulamaya yönlenir	İlgili yeniden yazma kurallarını dar kapsamda gözden geçirin
IPv6 uyumsuzluğu	IPv4 doğru, IPv6 üzerinden DCV başarısız	AAAA kaydını ve IPv6 üzerindeki HTTP yanıtını ayrı test edin

cPanel SSL sertifikası yenilenmiyor: Güvenli teşhis adımları

1. AutoSSL günlüğünde başarısız alan adını bulun

WHM erişiminiz varsa Manage AutoSSL bölümündeki ilgili kullanıcı günlüğünü inceleyin. Komut satırında root yetkisiyle son AutoSSL günlüklerini listelemek için aşağıdaki komut kullanılabilir:

ls -lt /usr/local/cpanel/logs/autossl/ | head

İlgili günlük dosyasında alan adı, 404, DCV veya pki-validation ifadelerini arayın. Günlük dosyasının adı kurulum ve tarihe göre değişebileceğinden önce listeleme yapmak önemlidir.

grep -Ein '404|DCV|pki-validation|example.com' /usr/local/cpanel/logs/autossl/LOG_DOSYASI

example.com ve LOG_DOSYASI alanlarını kendi değerlerinizle değiştirin. Hata metnindeki tam URL, teşhisin temel kanıtıdır; alan adını tahmin ederek ilerlemeyin.

2. DNS hedefini ve IPv4/IPv6 yanıtını karşılaştırın

Önce alan adının hangi IP adreslerine çözüldüğünü görün. Sunucu üzerinde dig paketi bulunmuyorsa komutu yerel yönetim bilgisayarınızdan da çalıştırabilirsiniz.

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

A kaydı cPanel sunucusunu gösterirken aktif bir AAAA kaydı başka bir sunucuya gidiyorsa, doğrulama IPv6 üzerinden yanlış hedefe ulaşabilir. IPv6 hizmeti gerçekten yapılandırılmadıysa AAAA kaydını DNS bölgesinden kaldırmak; IPv6 hizmeti kullanılıyorsa web sunucusunun aynı vhost ve belge köküyle IPv6 üzerinden yanıt vermesini sağlamak gerekir. DNS değişikliğinden sonra TTL ve önbellek etkisini hesaba katın.

3. HTTP/80 ve yönlendirme zincirini dışarıdan test edin

DCV için kritik olan ilk bağlantı HTTP/80’dir. Başka bir ağdan veya sunucunun dış IP’sini zorlayarak yanıt başlıklarını inceleyin:

curl -I http://example.com/
curl -I -L --max-redirs 10 http://example.com/

İlk komutta bağlantı hatası, zaman aşımı veya güvenlik duvarı reddi varsa 404 çözümüne geçmeden ağ erişimini düzeltin. İkinci komutta yönlendirme döngüsü, farklı bir alan adına yönlendirme ya da beklenmeyen bir uygulama yanıtı görürseniz AutoSSL doğrulama yolunun da aynı davranıştan etkilenip etkilenmediğini kontrol edin.

DNS’i değiştirmeden belirli bir origin IP üzerinde test yapmak için:

curl -I --resolve example.com:80:203.0.113.10 http://example.com/

Buradaki IP örnektir; kendi sunucunuzun gerçek IPv4 adresini yazın. Bu test, CDN veya yanlış DNS yanıtı ile origin sunucudaki davranışı ayırmaya yardım eder.

4. Belge kökü ve .well-known erişimini doğrulayın

cPanel hesabında Domains ekranını açın ve sorunlu alan adı için gösterilen Document Root değerini not edin. Ana alan adı her zaman public_html altında olmak zorunda değildir; eklenti alan adları ve alt alan adları farklı belge kökleri kullanabilir. Bu nedenle dosyayı varsayılan bir dizine koyarak test etmeyin.

Belge kökünde geçici ve zararsız bir test dosyası oluşturun. Üretimde dosya değişikliği yapmadan önce özellikle özel yönlendirme kuralları bulunan sitelerde kısa bir bakım penceresi planlayın. Aşağıdaki örnekte belge kökü yerine cPanel’de gördüğünüz gerçek yolu yazın:

mkdir -p /GERCEK/BELGE/KOKU/.well-known/pki-validation
printf 'dcv-test\n' > /GERCEK/BELGE/KOKU/.well-known/pki-validation/dcv-test.txt
curl -i http://example.com/.well-known/pki-validation/dcv-test.txt

Yanıtın HTTP/1.1 200 olması ve gövdede dcv-test metninin görülmesi beklenir. 404 devam ediyorsa dosya yanlış belge köküne yazılmış olabilir veya istek bir yeniden yazma kuralıyla başka bir hedefe aktarılıyor olabilir. Test tamamlanınca geçici dosyayı silin:

rm -f /GERCEK/BELGE/KOKU/.well-known/pki-validation/dcv-test.txt

Adım adım çözüm: 404 üreten katmanı düzeltin

Belge kökünü ve alan adı eşlemesini düzeltin

Alan adı bir alt alan adı, eklenti alan adı veya uygulama dizinine bağlıysa cPanel’deki belge kökü ile yayımlanan dosyaların bulunduğu dizin eşleşmelidir. Yanlış eşleme varsa alan adının yapılandırmasını cPanel/WHM üzerinden düzeltin. Doğrudan Apache sanal host dosyalarını elle değiştirmek, cPanel yapılandırma yeniden oluşturma süreçlerinde değişikliklerin kaybolmasına neden olabilir.

.well-known yolunu engelleyen kuralları daraltın

WordPress, Laravel veya başka bir uygulama için tüm istekleri tek giriş dosyasına yönlendiren kurallar, /.well-known/ yolunu da yakalayabilir. Aynı durum bazı güvenlik eklentileri, ModSecurity kuralları ve CDN/WAF politikaları için de geçerlidir. Hedef, tüm yönlendirmeleri kaldırmak değil; doğrulama yolunun gerçek dosyadan sunulmasına izin vermektir.

Önce alan adına ait erişim günlüğünde test isteğini arayın. cPanel/Apache kurulumlarında alan adı günlükleri çoğunlukla aşağıdaki dizindedir:

grep -F '.well-known/pki-validation/dcv-test.txt' /usr/local/apache/domlogs/example.com

Günlükte isteğin görünmemesi, DNS, proxy veya ağ katmanına işaret eder. İstek görünmesine rağmen 404 dönüyorsa belge kökü, uygulama yönlendirmesi veya web sunucusu kuralı incelenmelidir. LiteSpeed kullanılıyorsa Apache uyumlu .htaccess kuralları çoğu kurulumda işlenir; ancak özel LiteSpeed/uygulama önbellek davranışı için aynı URL’yi önbellek dışı bırakarak tekrar test etmek gerekebilir.

CDN, proxy ve güvenlik katmanını kontrollü ele alın

Alan adı bir CDN veya ters proxy arkasındaysa HTTP doğrulama isteği origin sunucuya ulaşmadan özel 404 sayfası üretebilir. Önce curl --resolve ile origin üzerinde dosyanın 200 döndüğünü kanıtlayın. Ardından proxy kuralında /.well-known/ yolunun engellenmediğini, başka bir origin’e yönlenmediğini ve HTTP/80 isteklerinin reddedilmediğini kontrol edin. Sorunu ayıklamak için tüm güvenlik katmanını kalıcı biçimde kapatmak yerine, yalnızca bu yol ve alan adı için dar, geçici bir istisna uygulayın; işlem bitince istisnayı kaldırın.

AutoSSL işlemini yeniden çalıştırma ve doğrulama

DNS, belge kökü veya kural düzeltmesinden sonra önce test URL’sinin dışarıdan 200 verdiğini doğrulayın. Ardından root yetkisiyle yalnızca etkilenen kullanıcı için AutoSSL denetimini çalıştırın:

/usr/local/cpanel/bin/autossl_check --user=CPANEL_KULLANICISI

Birden fazla hesap etkileniyorsa tüm hesaplarda denetim yapmak mümkündür; ancak gereksiz yük ve geniş etki alanı oluşturmamak için önce kullanıcı bazlı çalıştırma tercih edilmelidir:

/usr/local/cpanel/bin/autossl_check --all

İşlem sonunda cPanel’de SSL/TLS Status sayfasından alan adının sertifika durumunu kontrol edin. Tarayıcı testi tek başına yeterli değildir; eski sertifika tarayıcı veya ara katman önbelleğinde görünebilir. Sertifikanın bitiş tarihini ve sunulan sertifika ayrıntılarını komut satırından da kontrol edebilirsiniz:

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

Çıktıdaki notAfter alanı yeni bitiş tarihini göstermelidir. -servername parametresi, aynı IP üzerinde birden fazla alan adı bulunduğunda doğru SNI sertifikasının sorgulanması için önemlidir.

Tekrarını önleme

• DNS değişikliklerinde A ve AAAA kayıtlarını birlikte gözden geçirin; kullanılmayan IPv6 kaydı bırakmayın.
• Yeni yönlendirme, WAF veya CDN kuralından sonra /.well-known/ erişimini kısa bir HTTP testiyle doğrulayın.
• Alan adı taşınırken DNS geçişi ile cPanel belge kökü değişikliğini aynı anda ve doğrulama yapmadan uygulamayın.
• AutoSSL günlüklerini sertifika bitiş tarihinden önce düzenli kontrol edin; sorunları son günlere bırakmayın.
• Otomatik HTTPS yönlendirmesi kullanıyorsanız HTTP/80 erişimini tamamen kapatmak yerine yönlendirme zincirinin çalıştığını doğrulayın.

Sonuç

cPanel SSL sertifikası yenilenmiyor ve günlükte HTTP DCV 404 görünüyorsa doğru yaklaşım sertifikayı rastgele yeniden kurmak değildir. Başarısız alan adını günlükten belirlemek, DNS hedefini doğrulamak, gerçek belge kökünde .well-known erişimini test etmek ve yönlendirme/proxy katmanındaki engeli dar kapsamda kaldırmak sorunu güvenli biçimde çözer. Test URL’si dışarıdan 200 döndürmeden AutoSSL’i tekrar çalıştırmamak, gereksiz denemeleri ve yanlış müdahaleleri azaltır.

Sık sorulan sorular

HTTP 404 varken sertifika neden tarayıcıda hâlâ çalışıyor?

Mevcut sertifika henüz süresini doldurmamış olabilir. Sorun yenileme aşamasındadır; sertifika süresi dolduğunda ziyaretçiler hata görmeye başlayabilir.

HTTP’yi tamamen HTTPS’ye yönlendirmek AutoSSL’i bozar mı?

Her zaman bozmaz. Ancak yönlendirme döngüsü, yanlış alan adına geçiş, HTTPS tarafında geçersiz yapılandırma veya /.well-known yoluna özel engel varsa DCV başarısız olabilir.

404 hatasında sertifikayı cPanel’den silip yeniden kurmalı mıyım?

Hayır. Önce DCV 404 nedenini düzeltin. Mevcut sertifikayı silmek, geçerli sertifika kapsamını gereksiz yere riske atabilir.

Wildcard sertifika için bu HTTP testi yeterli midir?

Hayır. Wildcard adların doğrulanması sertifika otoritesi ve AutoSSL sağlayıcısına göre DNS tabanlı doğrulama gerektirebilir. HTTP DCV testi, özellikle normal alan adları için erişim sorununu ayıklamada kullanılır.

AutoSSL komutunu çalıştırmak siteyi keser mi?

Normal koşullarda site kesintisi oluşturmaz. Buna karşın belge kökü, DNS, proxy veya yönlendirme kurallarında değişiklik yapacaksanız değişikliği kontrollü uygulayın ve geri dönüş planı bulundurun.