SSL Doğrulamasında Takılı Kalan Özel Alan Adı

Kaydı eklediniz. dig kaydı gösteriyor. Platform hâlâ beklemede diyor ve bir saattir böyle. Doğrulamada takılı kalan bir özel alan adı, kendi başınıza çalıştırabileceğiniz her kontrol başarılı göründüğü için özellikle can sıkıcıdır.

Dört neden vardır; hepsi mekaniktir ve aşağıdaki sıra, sorunu en hızlı şekilde bulmanızı sağlar.

Öncelikle: doğrulama aslında ne yapıyor?

Bir sertifika otoritesi sertifika yayımlamadan önce alan adını kontrol ettiğinizi doğrulamak zorundadır. Bunun iki yaygın yöntemi vardır ve platformunuzun hangisini kullandığı, hangi sorunların ortaya çıkabileceğini değiştirir:

• HTTP-01 — CA, http://your-domain/.well-known/acme-challenge/<token> adresine istek gönderir ve belirli bir metin bekler. Bunun çalışması için alan adınıza gelen düz HTTP isteklerinin platforma ulaşması gerekir.
• DNS-01 — CA, bir TXT kaydı arar. Bunun çalışması için kaydın mevcut olması ve CA'nin resolver'ı tarafından görülebilmesi gerekir; bu resolver, sorguladığınız resolver olmak zorunda değildir.

Takılı kalan doğrulamaların neredeyse tamamında CA ile bu iki şeyden biri arasında duran bir engel vardır.

Neden 1: challenge'ın önünde bir proxy olması

Alan adı bir CDN'in arkasındaysa en yaygın neden budur. Üstelik proxy genellikle zaten kullanmak istediğiniz şey olduğu için durum gerçekten kafa karıştırıcı olabilir.

DNS kaydınız doğrudan platformu göstermek yerine proxy üzerinden geçiyorsa CA'nin HTTP-01 isteği proxy'de sonlanır. Proxy kendi sertifikasını sunar, kendi kurallarını uygular ve bir redirect, challenge sayfası veya 404 döndürebilir — bunların hiçbiri CA'nin beklediği token'ı içermez.

Çözüm, challenge'ın geçmesine izin vermektir:

• Sertifika oluşturulana kadar proxy'yi kapatın (kaydı gri buluta alın), ardından yeniden etkinleştirin.
• Ya da /.well-known/acme-challenge/* yolunu tüm redirect veya erişim kurallarının dışında bırakın.

Buradaki tuzak, "Always Use HTTPS" ve "Under Attack" tarzı korumaların, sitenin tarayıcınızda tamamen sorunsuz çalıştığı izlenimini verirken HTTP-01'i bozabilmesidir.

Neden 2: yanlış kayıt türü

Geri kalan sorunların çoğu iki hatadan kaynaklanır:

Değişen bir adresi gösteren A kaydı. Platform size bir hostname verdiyse CNAME kullanın. Mevcut IP adresini bir A kaydına kopyalamak, adres değişene kadar çalışır.

Zone apex'te bir CNAME. example.com, SOA ve NS kayıtlarıyla birlikte yasal olarak bir CNAME barındıramaz. Bazı sağlayıcılar bunu çözmek için ALIAS, ANAME veya "CNAME flattening" sunar; bazıları sunmaz. Sizin sağlayıcınız sunmuyorsa bir subdomain — app.example.com — kullanın ve apex'e redirect uygulayın.

# What the world actually sees, not what your dashboard shows
dig +short app.example.com CNAME
dig +short app.example.com A

İkisi de boş dönüyorsa bu listedeki diğer hiçbir şey henüz önemli değildir.

Neden 3: ölçmediğiniz propagation

Argümansız dig, sizin resolver'ınıza sorar. Bu resolver, az önce oluşturduğunuz yanıtı cache'lemiş olabilir — hatta daha kötüsü, kaydı oluşturmadan önceki NXDOMAIN yanıtını cache'lemiş olabilir. TTL değeri uzun olan negatif bir cache kaydı, doğrulamanın bir saat boyunca başarısız olup ardından hiçbir müdahale olmadan başarılı olmasının gerçekten yaygın bir nedenidir.

CA'nin büyük olasılıkla göreceğini anlamak için authoritative sunuculara doğrudan ve bir public resolver'a sorgu gönderin:

# Ask the zone's own nameservers
dig +short app.example.com @$(dig +short NS example.com | head -1)

# Ask a resolver outside your network
dig +short app.example.com @1.1.1.1
dig +short app.example.com @8.8.8.8

Authoritative yanıt doğru, public resolver'lar yanlışsa TTL'yi bekliyorsunuz demektir; düzeltebileceğiniz bir şey yoktur.

Neden 4: CAA issuer'ı reddediyor

Bu neden nadirdir, normal DNS kontrollerinde görünmez ve ortaya çıktığında tamamen sessizdir.

Alan adınızdaki bir CAA kaydı, hangi sertifika otoritelerinin alan adınız için sertifika oluşturabileceğini listeler. Bir CAA kaydınız varsa — genellikle eski bir kurulumdan miras kalır veya bir güvenlik taraması önerisiyle eklenir — ve platformunuzun kullandığı CA'yi içermiyorsa sertifika oluşturma başarısız olur. Bunun belirtildiği tek yer, erişemediğiniz CA loglarıdır.

dig +short example.com CAA
dig +short app.example.com CAA

Boş çıktı herhangi bir kısıtlama olmadığı anlamına gelir ve bu sorun değildir. Kayıt dönerse platformunuzun kullandığı CA'yi ekleyin veya kısıtlamayı kaldırın.

Sorunu en hızlı bulan sıra

1. Kaydı bir public resolver üzerinden dig ile sorgulayın. Yanıt yoksa kayıt yanlıştır veya henüz propagation tamamlanmamıştır — burada durun.
2. Kaydın proxy üzerinden geçip geçmediğini kontrol edin. Geçiyorsa proxy'yi kaldırın veya ACME yolunu hariç tutun.
3. Hem apex hem de subdomain üzerindeki CAA kayıtlarını kontrol edin.
4. Ancak bundan sonra sorunun platformdan kaynaklandığını düşünün.

Takılı kalan doğrulamaların yüzde doksanı 1. veya 2. adımda çözülür.

Dockup'ta bu süreç nasıl işler?

İki tasarım tercihi, tahmin yürütme ihtiyacını büyük ölçüde ortadan kaldırır.

DNS kaydı sizin için oluşturulur. Zone'unuz Cloudflare üzerindeyse ve hesabınızı bağladıysanız, alan adı eklemek değeri elle kopyalamanızı gerektirmek yerine kaydı doğrudan oluşturur:

dockup domain add app.example.com my-project/my-api --port 3000 --cloudflare

Bu, yazım hataları ve yanlış kayıt türüyle ilgili sorunların tamamını ortadan kaldırır — platformun CNAME'e mi yoksa A kaydına mı ihtiyaç duyduğunu bilir ve doğru kaydı oluşturur.

Yetki iki permission'dan oluşur. Zone:Read ve DNS:Edit; başka hiçbir şey verilmez. Dockup diğer zone'larınızı okuyamaz, hesap ayarlarını değiştiremez veya kendisine verilmeyen hiçbir şeye dokunamaz. DNS otomasyonunu bağlamak, bir hesabın tüm yetkilerini devretmeyi gerektirmemelidir.

Doğrulama ve sertifika durumu tek bir toplu status yerine alan adı bazında görünür. Böylece "DNS doğrulandı ancak TLS beklemede" ifadesi, gerçekte olduğu gibi iki ayrı adımdan birinin tamamlandığını gösterir.

Sık sorulan sorular

Sertifika oluşturma ne kadar sürmeli? DNS doğru şekilde çözümlendiğinde genellikle bir dakikadan kısa sürer. Yaklaşık on beş dakikadan uzun süredir beklemedeyse yavaş ilerlemiyor, bir şey tarafından engelleniyor demektir.

Alan adım tarayıcıda çalışırken doğrulama neden başarısız oluyor? Çünkü tarayıcınız redirect'leri takip eder ve HTTPS kullanır; challenge ise ikisini de yapmaz. Sitenizi kusursuz şekilde sunan bir proxy, düz HTTP üzerinden gelen ACME isteğini yine de engelleyebilir.

Kök alan adımda CNAME kullanabilir miyim? Standart DNS'te kullanamazsınız. ALIAS veya CNAME flattening gibi bir sağlayıcı özelliği kullanın ya da apex'i redirect ile bir subdomain'e yönlendirin.

CAA kaydı nedir ve buna ihtiyacım var mı? Hangi sertifika otoritelerinin alan adınız için sertifika oluşturabileceğini kısıtlar. Bir CAA kaydına ihtiyacınız yoktur; ancak platformunuzun CA'sini içermeyen bir kaydınız varsa sertifika oluşturma sessizce başarısız olur.