Coolify'da Alan Adı ve SSL: Sertifika Sorunlarını Çözmek

Kısa cevap: Coolify’da alan adı bağlamanın sırası şudur: önce DNS kaydı, sonra panelde alan adı tanımı, sonra sertifika. Sertifika alınamıyorsa sebep neredeyse her zaman şu beşten biridir: DNS henüz yayılmamış, 80 portu kapalı, alan adı bir CDN üzerinden proxy ediliyor, hız sınırına takılınmış veya başka bir servis 80 portunu tutuyor.

Alan adı ve sertifika hangi sırayla kurulur?

Sertifika sağlayıcıları, sertifikayı vermeden önce alan adının gerçekten sizin kontrolünüzde olduğunu doğrular. En yaygın yöntem (HTTP-01 doğrulaması) şöyle çalışır: sağlayıcı, alan adının işaret ettiği sunucuya 80 portundan belirli bir adrese istek atar ve orada beklediği içeriği bulmayı bekler.

Bu mekanizma, sıralamayı zorunlu kılar:

1. DNS kaydını oluşturun. Alan adının A kaydı sunucunuzun genel IP adresine işaret etmeli.
2. Yayılmasını bekleyin ve doğrulayın. Dakikalar sürebilir.
3. Coolify’da alan adını tanımlayın. Uygulamanın ayarlarında tam adresi (https:// ile birlikte) yazın.
4. Sertifika otomatik alınır.

İkinci adımı atlamak, en sık yapılan hatadır. DNS kaydı yayılmadan sertifika istemek başarısız olur ve arka arkaya denemeler hız sınırına yaklaştırır.

Doğrulama komutları:

# Alan adı hangi IP'ye çözülüyor
dig +short uygulama.ornek.com

# Sunucunun genel IP'si (sunucuda çalıştırın)
curl -s https://api.ipify.org; echo

# İki çıktı aynı olmalı

Farklıysa DNS kaydı yanlış, henüz yayılmamış veya araya bir CDN girmiş demektir.

www ve kök alan adı birlikte nasıl çalışır?

Her iki adresin de çalışmasını istiyorsanız üç şey gerekir:

1. İki DNS kaydı: kök alan adı için A kaydı, www için A veya CNAME kaydı.
2. İki adres de Coolify’da tanımlı olmalı. Panelde tanımlanmayan adres için sertifika alınmaz; kullanıcı o adrese girdiğinde sertifika uyarısı görür.
3. Birini tercih edilen adres seçip diğerini yönlendirin.

Üçüncü madde arama motorları açısından önemlidir: aynı içeriğin iki farklı adresten yayınlanması kopya içerik olarak değerlendirilir ve sıralama sinyalleri bölünür. Hangisini seçtiğiniz önemli değildir, tutarlı olması önemlidir.

Yönlendirmeyi Coolify’ın kendi yönlendirme ayarından veya DNS sağlayıcınızın yönlendirme kuralından yapabilirsiniz. Uygulama içinde yapıyorsanız, yönlendirmenin sertifika doğrulama isteğini engellemediğinden emin olun: doğrulama isteği belirli bir yola gider ve o yol yönlendirmeye takılırsa sertifika alınamaz. Bu, “her şeyi HTTPS’e yönlendir” kuralının sertifikayı almayı imkânsızlaştırdığı klasik kısır döngüdür.

Sertifika alınamıyorsa nereye bakılır?

Sorunu şu sırayla daraltın; her adım bir sonrakini anlamsız kılabilir.

1. DNS gerçekten sunucuya mı işaret ediyor?

dig +short uygulama.ornek.com

Beklediğiniz IP değilse buradan devam etmeyin.

2. 80 portu dışarıdan erişilebilir mi? HTTP-01 doğrulaması bu portu kullanır. Firewall’da veya bulut sağlayıcısının güvenlik grubunda kapalıysa doğrulama başarısız olur.

# Sunucuda: 80 portu dinleniyor mu
sudo ss -tulpn | grep :80

# Dışarıdan: erişilebiliyor mu (başka bir makineden)
curl -I http://uygulama.ornek.com

Sık yapılan hata, “her şey HTTPS’ten geçsin” diyerek 80 portunu tamamen kapatmaktır. Bu port yönlendirme ve sertifika doğrulaması için açık kalmalıdır.

3. Araya bir CDN veya proxy giriyor mu? Alan adı bir CDN üzerinden proxy ediliyorsa, doğrulama isteği sizin sunucunuza değil CDN’e gider. Çözümü bir sonraki bölümde.

4. Hız sınırına takıldınız mı? Sertifika sağlayıcıları, aynı alan adı için belirli bir sürede verilebilecek sertifika sayısını sınırlar. Arka arkaya başarısız denemeler bu sınıra yaklaştırır ve saatlerce beklemek gerekebilir. Yapılandırma denemesi yapıyorsanız sağlayıcının hazırlık (staging) ortamını kullanın; oradaki sertifikalar tarayıcıda geçerli değildir ama hız sınırı çok daha geniştir.

5. 80 portunu başka bir servis mi tutuyor? Sunucuda ayrıca bir web sunucusu çalışıyorsa çakışma olur:

sudo ss -tulpn | grep -E ':80|:443'

Beklediğiniz vekil sunucu dışında bir süreç görüyorsanız, önce onu durdurun veya taşıyın.

Cloudflare arkasında sertifika nasıl alınır?

CDN proxy’si açıkken (turuncu bulut) trafik önce CDN’e, oradan sunucunuza gider. Bu, sertifika doğrulamasını ve bazı yönlendirme davranışlarını etkiler.

İki çalışan yaklaşım:

1. Önce sertifikayı alın, sonra proxy’yi açın. DNS kaydını proxy dışı (gri bulut) bırakın, Coolify sertifikayı alsın, sonra proxy’yi etkinleştirin. Yenileme zamanı geldiğinde aynı sorun tekrar edebilir; bu yüzden ikinci yaklaşım daha kalıcıdır.

2. SSL modunu tam (Full strict) yapın ve kaynak sunucuda geçerli sertifika bulundurun. Bu, uçtan uca şifreli ve doğrulanmış bir zincir kurar.

Esnek (Flexible) modu kullanmayın. Bu modda tarayıcı ile CDN arasında şifreli, CDN ile sunucunuz arasında şifresiz bir bağlantı olur. İki sorun çıkarır: trafiğin bir kısmı ağda açık gider ve sunucunuz HTTP’yi HTTPS’e yönlendirdiği için sonsuz yönlendirme döngüsü oluşur. Tarayıcıda “çok fazla yönlendirme” hatası görüyorsanız ilk bakılacak yer burasıdır.

Bir başka ayrıntı: CDN arkasındayken sunucunuz tüm istekleri CDN’in IP adreslerinden geliyor görür. Gerçek ziyaretçi adresini uygulamaya taşımak için vekil sunucunun ilgili başlıkları iletmesi ve uygulamanın bu başlıklara güvenecek biçimde yapılandırılması gerekir. İki taraf birlikte ayarlanmazsa hız sınırı, oturum yönetimi ve loglama yanlış çalışır; mantığın tamamı ters vekil sunucu karşılaştırmasında.

Wildcard sertifika: ne zaman gerekli?

Çok sayıda alt alan adı kullanıyorsanız (her müşteri veya her ortam için bir alt alan adı), her biri için ayrı sertifika almak yerine tek bir wildcard sertifika mantıklı olur.

Kritik fark şudur: wildcard sertifika HTTP doğrulamasıyla alınamaz, DNS doğrulaması gerekir. Yani sertifika sağlayıcısı, alan adınızın DNS bölgesine geçici bir kayıt eklemenizi ister. Bu da Coolify’ın DNS sağlayıcınıza API erişimi olmasını gerektirir.

Pratik sonuç: wildcard sertifika kurulumu, tekil sertifikadan belirgin biçimde daha karmaşıktır ve DNS sağlayıcınızın API anahtarını sunucuda saklamanızı gerektirir. Alt alan adı sayısı azsa tekil sertifikalar daha az uğraştırır. API anahtarı kullanacaksanız yetkisini yalnız ilgili DNS bölgesiyle sınırlayın; tüm hesaba yetkili bir anahtar, gereksiz bir risktir.

Sertifika yenilemesi neden sessizce bozulur?

Bu, alan adı yönetiminin en sinsi tarafıdır. Otomatik yenileme kurulmuş bir sistemde yenileme şu sebeplerle durabilir:

• 80 portu sonradan kapatılmış
• DNS kaydı değişmiş veya alan adı başka bir yere taşınmış
• Disk dolmuş, sertifika yazılamıyor
• Sertifika deposu kalıcı değil, her yeniden başlatmada sıfırlanıyor
• Bir yönlendirme kuralı doğrulama isteğini engelliyor
• CDN proxy’si sonradan açılmış

Hiçbiri anında görünmez. Sertifika süresi dolana kadar site normal çalışır ve bir sabah erişilemez hâle gelir.

Tek güvenilir önlem, bitiş tarihini dışarıdan bağımsız olarak izlemektir. Panelin kendi durumuna güvenmeyin; panel sertifikayı almaya çalıştığını bilir, tarayıcının ne gördüğünü bilmez.

# Sertifikanın gerçek bitiş tarihi (dışarıdan bakış)
echo | openssl s_client -servername uygulama.ornek.com \
  -connect uygulama.ornek.com:443 2>/dev/null | openssl x509 -noout -dates -issuer

Bu kontrolü izleme sisteminize ekleyin ve en az üç hafta önceden uyarı üretsin. Kurgusu sunucu izleme rehberinde; orada anlattığım “uyarı gerçekten ulaşıyor mu” testi burada da geçerlidir.

Dağıtım başarılı ama site eski görünüyorsa ne yapmalı?

Sertifikayla ilgisiz ama aynı sıklıkta karşılaşılan bir durum: panel dağıtımı başarılı gösterir, siteye girersiniz ve eski içerik durur.

Kontrol sırası:

1. Doğru dal mı dağıtıldı? Uygulama main dalını dinlerken siz başka bir dala gönderdiyseniz dağıtım eski koddan yapılmıştır.
2. Tarayıcı önbelleği mi? Özel pencerede veya curl ile kontrol edin:

curl -sI https://uygulama.ornek.com | head -20

3. CDN önbelleği mi? CDN kullanıyorsanız önbelleği temizleyin; CDN eski sürümü servis etmeye devam ediyor olabilir.
4. Gerçekten yeni konteyner mi çalışıyor? Sunucuda konteynerin başlatılma zamanına bakın:

docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Image}}"

Genel kural: panelin yeşil göstermesi, canlıda doğrulanmış olmak demek değildir. Dağıtım sonrası her zaman davranış kanıtı arayın: sayfayı açın, değişikliği gözle görün veya curl ile içeriği doğrulayın. Bu alışkanlık, “deploy başarılı ama kimse yeni sürümü görmüyor” durumunu saatler yerine saniyeler içinde yakalar.

Kontrol listesi

• DNS A kaydı sunucunun genel IP’sine işaret ediyor, dig ile doğrulandı
• Hem kök hem www adresi (kullanılıyorsa) panelde tanımlı
• Biri tercih edilen adres, diğeri ona yönlendiriliyor
• 80 portu açık (doğrulama ve yönlendirme için gerekli)
• CDN kullanılıyorsa SSL modu tam, esnek mod kullanılmıyor
• Gerçek ziyaretçi IP’si uygulamaya doğru taşınıyor
• Sertifika deposu kalıcı bir hacimde
• Sertifika bitiş tarihi dışarıdan izleniyor, 21 gün önceden uyarı var
• Yapılandırma denemeleri hazırlık ortamında yapıldı (hız sınırı korunuyor)
• Dağıtım sonrası canlıda davranış kanıtı kontrol ediliyor

Alan adı ve sertifika tarafı oturduktan sonra sıradaki konu kalıcı veridir: Coolify kalıcı veri tuzakları. Kurulumun tamamı Coolify kurulum rehberinde, platformun genel çerçevesi Coolify nedir yazısında, ters vekil sunucunun altındaki mantık nginx, Traefik ve Caddy karşılaştırmasında.

Kaynaklar

• Coolify Documentation (alan adı ve sertifika yapılandırması)
• RFC 8555: ACME (HTTP-01 ve DNS-01 doğrulama akışları)
• Let’s Encrypt Rate Limits (hız sınırları ve hazırlık ortamı)