Let's Encrypt Doğrulaması Başarısız: .well-known/acme-challenge Hatası

Ekranda genelde şu satır durur: Invalid response from http://ornek.com/.well-known/acme-challenge/7Xk...: 404. Ya da cPanel'in AutoSSL raporunda "The domain failed domain control validation" yazar. Sertifika istediniz, sunucu bir dosya oluşturdu, doğrulama sunucusu o dosyayı okumaya gitti ve bulamadı. Site açılıyor, panel çalışıyor, her şey normal görünüyor — ama sertifika bir türlü kurulmuyor.

Bu hatanın can sıkıcı tarafı, mesajın her zaman gerçek nedeni söylememesidir. 404 gördüğünüzde dosyanın oluşmadığını düşünürsünüz; oysa dosya yerindedir ve .htaccess içindeki bir yönlendirme isteği başka yere savurmuştur. Timeout gördüğünüzde sunucunun kapalı olduğunu sanırsınız; oysa alan adı bambaşka bir IP'ye bakıyordur. Doğrulama zincirinde altı ayrı halka var ve hepsi aynı hata mesajını üretebiliyor.

Bu yazıda o zinciri baştan sona, eleme sırasıyla söküyoruz. Her adımda tek satırlık bir doğrulama testi var: testi çalıştırıyorsunuz, sonuç beklediğiniz gibiyse bir sonraki halkaya geçiyorsunuz. Sorunun nerede olduğunu tahmin etmek yerine ölçerek buluyorsunuz. Sıralama rastgele değil; en ucuz ve en sık karşılaşılan nedenden başlayıp en nadirine doğru ilerliyor.

Doğrulama Aslında Ne Yapıyor?#

Let's Encrypt size sertifika vermeden önce şu soruya cevap arar: "Bu alan adı gerçekten bu kişinin kontrolünde mi?" Bunu ispatlamanın en yaygın yolu HTTP-01 doğrulamasıdır ve mekanizması şaşırtıcı derecede basittir.

1. İstemciniz (certbot, acme.sh, cPanel AutoSSL) sertifika siparişi açar.
2. Let's Encrypt rastgele bir token üretip gönderir.
3. İstemci bu token'ı sunucunuzda <web kökü>/.well-known/acme-challenge/<token> yoluna bir dosya olarak yazar.
4. Let's Encrypt doğrulama sunucuları http://ornek.com/.well-known/acme-challenge/<token> adresini 80. porttan ister.
5. Beklenen içerik döndüyse doğrulama geçer, sertifika imzalanır ve dosya silinir.

Kritik ayrıntılar burada saklı. İstek HTTP üzerinden, 80. porttan başlar — çünkü henüz geçerli bir sertifikanız olmayabilir. Yönlendirme varsa Let's Encrypt onu takip eder; HTTPS'e yönlendirmek sorun değildir, çünkü doğrulama sırasında hedefin sertifikası doğrulanmaz. Yani "sitem zaten HTTPS'e yönleniyor, sorun bu olmalı" tahmini genellikle yanlıştır.

İkinci kritik ayrıntı: istek internetten gelir. Sunucunun kendi içinden curl localhost ile dosyayı görebilmeniz hiçbir şey ispatlamaz. Doğrulama, alan adının dünyaya gösterdiği IP'ye gider. Protokolün genel işleyişi için ACME protokolünün nasıl çalıştığını inceleyebilirsiniz; burada sadece kırılma noktalarına odaklanacağız.

Hangi Hata Mesajı Neyi Gösteriyor?#

Log satırını doğru okumak, deneme yanılma süresini yarıya indirir. En sık karşılaşılan mesajlar ve gerçek anlamları:

404 ile Invalid response arasındaki fark özellikle önemlidir. İlkinde web sunucusu "böyle bir dosya yok" der; ikincisinde bir şey döner ama içerik beklenen token değildir — bu neredeyse her zaman bir yönlendirme veya araya giren bir uygulama demektir.

Adım 1: Alan Adı Gerçekten Bu Sunucuya mı Bakıyor?#

Vakaların yarıya yakını burada biter. Sunucuda her şey doğrudur; alan adı başka bir yeri gösteriyordur — eski hosting, test sunucusu ya da parked sayfası.

Önce alan adının hangi IP'ye çözümlendiğine bakın, sonra sunucunun kendi genel IP'siyle karşılaştırın:

# Alan adı hangi IP'ye bakıyor? (www ile ve www'suz ayrı ayrı)
dig +short ornek.com A
dig +short www.ornek.com A

# IPv6 kaydı var mı? (çok gözden kaçan neden)
dig +short ornek.com AAAA

# Sunucunun dışarıya gösterdiği IP
curl -s https://ifconfig.me; echo

İki değer aynı değilse başka hiçbir adımı denemeye gerek yok. DNS kaydını düzeltin ve TTL süresi kadar bekleyin.

AAAA kaydı burada özel bir tuzaktır. Let's Encrypt bir alan adında hem A hem AAAA kaydı görürse önce IPv6 üzerinden bağlanmayı dener. Sunucunuz IPv6'da hiç dinlemiyorsa bağlantı hatası alınır ve IPv4'e düşülür; ama IPv6 adresi başka bir makineye bakıyor ve o makine cevap veriyorsa geri dönüş olmaz — doğrulama "dosya yok" diyerek başarısız olur. IPv6'yı gerçekten kullanmıyorsanız AAAA kaydını silmek en temiz çözümdür.

Alan adı hiç çözümlenmiyorsa sorun daha yukarıdadır: nameserver kayıtlarını kontrol edin.

dig +short NS ornek.com

Dönen nameserver'lar hosting sağlayıcınıza ait değilse DNS kayıtlarınızı yanlış panelden yönetiyorsunuz demektir. Sorgulama komutlarının ayrıntısı için dig ve nslookup kullanımı yazısına bakabilirsiniz.

Adım 2: Dosya Tarayıcıdan Görünüyor mu?#

DNS doğruysa artık gerçek testi yapabilirsiniz: doğrulama sunucusunun yapacağı isteği elle taklit edin. Sunucuda web kökünün altına kendi test dosyanızı yazın.

# cPanel'de web kökü genelde /home/kullanici/public_html
cd /home/kullanici/public_html
mkdir -p .well-known/acme-challenge
echo "test-ok" > .well-known/acme-challenge/deneme.txt

Sonra dışarıdan, açıkça HTTP ile isteyin:

curl -s http://ornek.com/.well-known/acme-challenge/deneme.txt

Çıktı test-ok ise bu halka sağlam. Başka bir şey döndüyse ne döndüğünü görmek için yönlendirmeleri takip edin ve başlıkları yazdırın:

curl -sIL http://ornek.com/.well-known/acme-challenge/deneme.txt

Bu çıktıda Location: satırlarını okuyun. /.well-known/acme-challenge/deneme.txt yolunun sonunda hâlâ aynı yolda mı, yoksa ana sayfaya mı düştünüz? Zincir https://ornek.com/ gibi bir yerde bitiyorsa suçlu bir sonraki adımda.

Testi bitirdikten sonra dosyayı silmeyi unutmayın:

rm -f /home/kullanici/public_html/.well-known/acme-challenge/deneme.txt

Adım 3: .htaccess Yönlendirmesi .well-known Dizinini Yutuyor mu?#

Test dosyası diskte duruyor ama curl ana sayfayı döndürüyorsa neredeyse kesin sebep budur. WordPress, Laravel ve çoğu PHP çatısı, var olmayan yolları tek bir giriş dosyasına yönlendirir; ayrıca "tüm trafiği HTTPS'e ve www'ya taşı" kuralları da bu dizini yakalar.

Çözüm, .well-known yolunu tüm kurallardan en başta muaf tutmaktır. Apache için .htaccess dosyasının en üstüne şu iki satırı ekleyin:

RewriteEngine On
# Doğrulama isteklerini hiçbir kurala sokma
RewriteRule ^\.well-known/acme-challenge/ - [L]

[L] bayrağı "bu istekte kural işlemeyi burada bitir" demektir; bu yüzden satırın diğer tüm RewriteRule satırlarından önce gelmesi zorunludur. Sonda durursa hiçbir işe yaramaz. Yönlendirme kurallarının genel mantığı için .htaccess ile yönlendirme yazısı iyi bir başlangıçtır.

Bir diğer klasik neden gizli dosya engellemesidir. Güvenlik amacıyla noktayla başlayan dosyaları kapatan şu blok, .well-known dizinini de kapatır:

# BU BLOK DOĞRULAMAYI KIRAR
<FilesMatch "^\.">
    Require all denied
</FilesMatch>

Bunun yerine sadece gerçekten riskli dosyaları hedefleyin (^\.(env|git|htpasswd)) ya da .well-known için açık bir istisna tanımlayın.

Nginx kullanıyorsanız karşılığı şu blok olur ve location / bloğundan önce yazılmalıdır:

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

^~ ön eki burada bilinçli bir tercihtir: eşleşme bulunduğunda Nginx artık regex konumlarını değerlendirmez, böylece .php veya try_files ... /index.php kuralları araya giremez.

Uygulama katmanını da unutmayın. WordPress'te "coming soon", bakım modu veya zorunlu HTTPS eklentileri her isteği kendi sayfasına çevirir. Sorunu bulmak için eklentileri geçici olarak kapatıp curl testini tekrarlayın.

Adım 4: CAA Kaydı Sertifika Sağlayıcısını Engelliyor mu?#

Dosya dışarıdan okunabiliyor ama doğrulama yine de reddediliyorsa, engel HTTP katmanında değil DNS'te olabilir. CAA kaydı, bir alan adına hangi sertifika otoritelerinin sertifika verebileceğini ilan eder. Kayıt varsa ve listede Let's Encrypt yoksa, dosya doğru yerde dursa bile sipariş reddedilir.

dig +short CAA ornek.com

Çıktı boşsa CAA kaydınız yoktur ve bu bir sorun değildir — kayıt yokluğu "herkes verebilir" anlamına gelir. Çıktı doluysa içinde letsencrypt.org geçtiğinden emin olun:

ornek.com.  3600  IN  CAA  0 issue "letsencrypt.org"

Wildcard sertifika alıyorsanız issuewild satırı da gerekir; issue tek başına joker adları kapsamaz:

ornek.com.  3600  IN  CAA  0 issuewild "letsencrypt.org"

CAA kontrolü üst alan adlarına doğru da yürür: blog.ornek.com için kayıt yoksa ornek.com kaydına bakılır. Yani alt alan adının sertifikası, kök alan adına konmuş katı bir CAA kaydı yüzünden reddedilebilir. Kaydın söz dizimi ve bayrak alanı için CAA kaydı nedir yazısına göz atın.

Adım 5: Cloudflare Proxy Araya Giriyor mu?#

Alan adı Cloudflare üzerinden geçiyorsa (dig +short ornek.com size Cloudflare IP'si döndürüyorsa) doğrulama isteği önce Cloudflare'e, oradan sunucunuza ulaşır. Bu genelde çalışır ama üç ayar bozar:

SSL/TLS modu "Full (strict)". Cloudflare, sunucunuzdan içeriği çekerken sizin sertifikanızı doğrular. Henüz geçerli sertifikanız yoksa bu çekme başarısız olur ve ziyaretçiye — dolayısıyla doğrulama sunucusuna — bir Cloudflare hata sayfası döner. Sertifika kurulana kadar modu geçici olarak "Full" seviyesine indirin, kurulum bitince tekrar "Full (strict)" yapın.

WAF veya "Under Attack" modu. Tarayıcı doğrulama ekranı (JS challenge) devredeyse, Let's Encrypt sunucusu o ekranı geçemez ve token yerine HTML alır. Doğrulama süresince bu modu kapatın veya /.well-known/acme-challenge/* yolu için kuralı atlayan bir yapılandırma kuralı ekleyin.

Önbellek. Nadiren de olsa, daha önce alınmış bir 404 cevabı önbellekte kalabilir. Sipariş öncesi önbelleği temizlemek ucuz bir sigortadır.

En pratik yaklaşım şudur: sertifikayı alırken ilgili DNS kaydının turuncu bulutunu kapatıp gri (DNS only) yapın, sertifika kurulduktan sonra tekrar açın. Proxy mimarisinin ayrıntıları için Cloudflare DNS ve CDN yazısına bakabilirsiniz.

Not: Cloudflare üzerinde uçtan uca zaten HTTPS görünüyor olması, sunucunuzda gerçek bir sertifika olduğu anlamına gelmez. Ziyaretçi ile Cloudflare arasındaki bağlantı şifrelidir; Cloudflare ile sunucunuz arasındaki bağlantı ayrı bir konudur ve orayı kapatmak için yine kendi sertifikanız gerekir.

Adım 6: Dizin İzinleri ve Sahiplik#

403 Forbidden alıyorsanız ya da dosya diskte olduğu halde web sunucusu göremiyorsa, sıra izinlere gelmiştir. Dizin zincirinin tamamının okunabilir ve girilebilir olması gerekir:

# Sahiplik ve izinleri hızlıca gör
namei -l /home/kullanici/public_html/.well-known/acme-challenge

# Doğru değerlere çek (cPanel örneği)
chown -R kullanici:kullanici /home/kullanici/public_html/.well-known
chmod 755 /home/kullanici/public_html/.well-known
chmod 755 /home/kullanici/public_html/.well-known/acme-challenge

Dizinler 755, dosyalar 644 olmalıdır. 700 verilmiş bir .well-known dizini, dosya orada olsa bile web sunucusunun okumasını engeller.

İkinci bir olasılık ModSecurity'dir. Kural setleri bazen uzun ve rastgele görünen dosya adlarını şüpheli sayar. Böyle bir durumda hatanın izi hem web sunucusu hem de ModSecurity kayıtlarına düşer; cPanel hata kayıtlarını okuma yazısı bu logları nerede bulacağınızı anlatır. Doğrulama sırasında hangi isteğin geldiğini görmek için erişim kaydını canlı izleyebilirsiniz:

tail -f /home/kullanici/logs/ornek.com.log | grep acme-challenge

Bu satır hiç dolmuyorsa istek sunucunuza hiç ulaşmıyor demektir — o zaman sorun Adım 1 veya Adım 5'tedir, izinlerde değil.

cPanel AutoSSL Özelinde Kontrol Listesi#

cPanel'in AutoSSL'i aynı HTTP doğrulamasını kullanır ama kendi ek katmanları vardır. Sağlayıcı olarak Let's Encrypt seçiliyse dosya .well-known/acme-challenge/ altına, cPanel'in kendi (Sectigo) sağlayıcısı seçiliyse .well-known/pki-validation/ altına yazılır. Muafiyet kurallarınızı yazarken hangi sağlayıcının aktif olduğunu bilmek gerekir.

Kontrol edilecekler:

1. WHM » SSL/TLS Status ekranından ilgili alan adı için "Run AutoSSL" çalıştırın ve çıkan raporu okuyun; hangi ad için hangi hata alındığını satır satır yazar.
2. Ayrıntılı kayıtlar /var/cpanel/logs/autossl/ altındadır; en son çalıştırmanın dosyası, curl ile göremediğiniz ayrıntıyı verir.
3. Alan adı AutoSSL dışı bırakılmış olabilir. Aynı ekranda "Exclude" işaretli adlar hiç denenmez.
4. Alan adı cPanel hesabına gerçekten tanımlı mı? Addon veya parked domain olarak eklenmemiş bir ad için AutoSSL sertifika istemez.
5. www alt adının A kaydı yoksa AutoSSL o adı doğrulayamaz ve tüm sipariş için uyarı üretir. Ya kaydı ekleyin ya da o adı listeden çıkarın.

AutoSSL'in çalışma takvimi ve kapsamı için AutoSSL nedir yazısı ayrıntılı bir referanstır.

Doğrulama Limitine Takıldıysanız Ne Yapmalı?#

Let's Encrypt başarısız doğrulamaları sayar. Aynı alan adı için saatlik başarısız doğrulama sınırına ulaşırsanız, sorunu düzeltseniz bile bir süre yeni sipariş açamazsınız — ve bu kez hata mesajı yanıltıcı biçimde "too many failed authorizations" olur.

Bu yüzden düzeltmeyi denemeden önce testinizi canlı sipariş üzerinden yapmayın. İki güvenli yol var:

# 1) Gerçek sipariş açmadan prova
certbot certonly --webroot -w /home/kullanici/public_html -d ornek.com --dry-run

# 2) Test (staging) sunucusuna karşı deneme
certbot certonly --webroot -w /home/kullanici/public_html -d ornek.com \
  --server https://acme-staging-v02.api.letsencrypt.org/directory

Staging sertifikaları tarayıcıda güvenilir değildir; amaç zaten sertifika almak değil, doğrulama zincirinin çalıştığını ispatlamaktır. Zincir prova ortamında geçtiğinde canlıya alın.

Mevcut sertifikaların durumunu ve son hatanın ayrıntısını görmek için:

certbot certificates
tail -n 50 /var/log/letsencrypt/letsencrypt.log

Sertifikayı bir kez aldıktan sonra asıl mesele onu ayakta tutmaktır; yenileme aynı doğrulamayı tekrar çalıştırır ve bugün düzelttiğiniz .htaccess kuralı yarın geri gelirse sertifika sessizce süresi dolmuş duruma düşer. SSL otomatik yenileme yazısındaki kontrolleri kurmanız uzun vadede işinizi kolaylaştırır.

DNS-01 Doğrulamasına Ne Zaman Geçmeli?#

HTTP-01 doğrulaması, web sunucusunun dışarıdan 80. porttan erişilebilir olmasını gerektirir. Bazı senaryolarda bu mümkün değildir ve ne kadar uğraşırsanız uğraşın çözüm HTTP tarafında değildir:

• Sunucu tamamen kapalı bir ağda, kurumsal bir güvenlik duvarının arkasında.
• 80. port servis sağlayıcı tarafından kapatılmış.
• Wildcard sertifika alınacak — Let's Encrypt joker adlar için HTTP-01'i hiç kabul etmez.
• Aynı alan adı için birden çok sunucuda ayrı ayrı sertifika üretilecek.

Bu durumlarda DNS-01 doğrulaması kullanılır: dosya yerine, alan adının DNS bölgesine _acme-challenge.ornek.com adında geçici bir TXT kaydı yazılır ve doğrulama sunucusu o kaydı sorgular.

# Kaydın gerçekten yayıldığını görmek için
dig +short TXT _acme-challenge.ornek.com

Bu yöntemin bedeli, DNS sağlayıcınızın API'sine erişim gerektirmesidir; her yenilemede kaydın otomatik yazılıp silinmesi gerekir. Manuel yapılırsa 60 günde bir elle müdahale demektir ve unutulmaya çok açıktır. Joker sertifikaların kapsamı ve sınırları için wildcard SSL nedir yazısına bakabilirsiniz.

Sorunu Bulduktan Sonraki İlk İş#

Doğrulama geçtiğinde iş bitmiş sayılmaz. Aynı hatanın üç ay sonra tekrar etmemesi için üç şeyi kalıcı hale getirin: .well-known muafiyet kuralını uygulamanın kendi .htaccess şablonuna ekleyin (çünkü WordPress kalıcı bağlantı ayarları değiştiğinde dosyayı yeniden yazar), sertifika bitiş tarihine 20 gün kala uyaran bir izleme kurun ve Cloudflare üzerinde geçici olarak düşürdüğünüz SSL modunu geri yükselttiğinizden emin olun. Son madde en sık atlananıdır; sertifika alındıktan sonra "Full" modda unutulan bir site, uçtan uca şifrelemenin yarısını kaybetmiş olur.

Sıkça Sorulan Sorular#

.well-known klasörünü elle oluşturmam gerekir mi?#

Normalde hayır. Certbot, acme.sh ve cPanel AutoSSL doğrulama sırasında dizini kendisi oluşturur ve işi bitince siler. Elle oluşturmanız yalnızca test amaçlıdır: kendi yazdığınız bir dosyayı dışarıdan okuyabiliyorsanız, sorunun dosya oluşturmada değil erişimde olmadığını kanıtlamış olursunuz. Test bittikten sonra oluşturduğunuz dosyayı silin; dizinin kalması zararsızdır.

Sitem HTTPS'e yönleniyor, doğrulama bu yüzden mi başarısız?#

Büyük ihtimalle hayır. Let's Encrypt doğrulama isteğinde yönlendirmeleri takip eder ve HTTPS hedefinin sertifikasını denetlemez; bu yüzden HTTP'den HTTPS'e yönlendirme tek başına sorun çıkarmaz. Asıl sorun, yönlendirme kuralının isteği ana sayfaya veya uygulamanın giriş dosyasına savurmasıdır. Kuralın yolu koruyup korumadığını curl -sIL çıktısındaki Location satırlarından anlarsınız.

AutoSSL raporunda hata var ama site HTTPS ile açılıyor, ne oluyor?#

Muhtemelen sitede eski ve hâlâ geçerli bir sertifika duruyor, AutoSSL ise onu yenilemeye çalışırken takılıyor. Site bugün çalışır, sertifika bitince aniden uyarı verir. Rapordaki alan adını not edin: çoğu zaman www veya bir alt alan adı, ana ad değil. O adın DNS kaydını düzeltmek ya da adı AutoSSL kapsamından çıkarmak sorunu bitirir.

Aynı hata mesajını alıp duruyorum, sipariş neden hiç değişmiyor?#

Başarısız doğrulama sınırına takılmış olabilirsiniz. Let's Encrypt aynı alan adı için saatlik başarısız deneme sayısını sınırlar; limite ulaştıktan sonra sunucu tarafındaki düzeltmeniz doğru olsa bile aynı hatayı almaya devam edersiniz. Bir saat bekleyin ve bu arada denemelerinizi --dry-run veya staging sunucusuyla yapın; prova denemeleri canlı limiti tüketmez.

Alan adım Cloudflare'de, turuncu bulutu kapatmak zorunda mıyım?#

Zorunlu değil ama sorun giderirken en hızlı yol budur. Proxy açıkken doğrulama isteği önce Cloudflare'e ulaşır ve orada bir güvenlik kuralı, önbellek girdisi veya katı SSL modu araya girebilir. Bulutu gri yapıp sertifikayı aldıktan sonra tekrar turuncuya çevirirseniz hem sorunun Cloudflare kaynaklı olup olmadığını kesin öğrenir hem de birkaç dakikada sonuca ulaşırsınız.

Wildcard sertifika için de .well-known dizini gerekir mi?#

Hayır. Joker (*.ornek.com) sertifikalar yalnızca DNS-01 yöntemiyle doğrulanabilir; Let's Encrypt bu adlar için HTTP dosya doğrulamasını kabul etmez. Dolayısıyla .well-known dizininde yapacağınız hiçbir düzeltme sonucu değiştirmez. Bunun yerine DNS bölgenize _acme-challenge TXT kaydı yazacak bir eklenti veya API entegrasyonu kurmanız gerekir.