Caddy otomatik HTTPS: Caddy auto TLS nasıl çalışır ve sorunlar nasıl çözülür

Kısaca: Caddy, herkese açık bir alan adı olan her site adresi için HTTPS'i otomatik olarak etkinleştirir. ACME üzerinden sertifika ister (varsayılan olarak Let's Encrypt veya ZeroSSL), alan adının kontrolünü 80 ve 443 portlarında HTTP-01 veya TLS-ALPN-01 challenge'ı ile kanıtlar, HTTP'yi HTTPS'e yönlendirir ve sertifikayı süresi dolmadan yeniler — hiçbir ek yapılandırma gerekmez.

Caddy reverse proxy, Caddy'nin bu HTTPS bağlantısını sonlandırıp isteği `reverse_proxy` direktifiyle başka bir porttaki, container'daki veya hosttaki bir uygulamaya iletmesinden ibarettir. Birkaç satırda TLS artı proxy — insanların onu seçmesinin başlıca nedeni bu kombinasyondur.

Üç satırda SSL'li reverse proxy

DNS sunucuyu gösterdiğinde ve 80 ile 443 portları erişilebilir olduğunda, bu Caddyfile iki hostname için eksiksiz bir HTTPS reverse proxy'dir. Caddy başlangıçta her iki ad için sertifika alır, HTTP/1.1, HTTP/2 ve HTTP/3 sunar ve backend'e `X-Forwarded-For`, `X-Forwarded-Proto` ve `X-Forwarded-Host` iletir. `email` seçeneği isteğe bağlıdır, ancak CA'nın süresi dolan veya iptal edilen sertifikalar hakkında sizinle iletişim kurmasını sağlar.

Resmî apt deposundan kurulum ve systemd temelleri Caddy reverse proxy rehberinde anlatılıyor; container'lar için bkz. Docker reverse proxy olarak Caddy. Değişiklikleri `sudo systemctl reload caddy` ile uygulayın.

# /etc/caddy/Caddyfile
{
	email [email protected]
}

example.com, www.example.com {
	reverse_proxy 127.0.0.1:8080
}

Caddy auto TLS perde arkasında nasıl çalışır

Caddy bir yapılandırmayı yüklediğinde site adreslerindeki tüm hostname'leri toplar ve her sertifikayı kimin vereceğine karar verir. Herkese açık alan adları herkese açık ACME sağlayıcılarına gider; `localhost`, IP adresleri ve yalnızca dahili adlar Caddy'nin kendi yerel CA'sından sertifika alır (`tls internal` yazmakla aynı). Sertifikalar, anahtarlar ve ACME hesabı Caddy'nin veri dizininde saklanır: apt paketi için `/var/lib/caddy/.local/share/caddy`, resmî Docker imajında `/data`.

Yenileme, süre dolmadan çok önce arka planda gerçekleşir ve CA destekliyorsa Caddy OCSP yanıtlarını staple eder. Sertifika alma başarısız olursa Caddy üstel geri çekilmeyle yeniden dener ve production rate limit'lerini harcamamak için yeniden denemelerde CA'nın staging endpoint'ini kullanır. Aynı depolamayı paylaşan birden fazla Caddy örneği koordineli çalışır, böylece belirli bir sertifikayı yalnızca biri ister.

DNS-01 ile wildcard sertifikalar

`*.example.com` gibi wildcard sertifikalar yalnızca DNS-01 challenge'ı ile verilebilir. Standart Caddy binary'si DNS sağlayıcı eklentilerini içermez; bu yüzden xcaddy ile bir build oluşturursunuz (veya sağlayıcıyı resmî indirme sayfasında seçersiniz) ve Caddy'ye yalnızca o zone'un DNS'ini düzenlemeyle sınırlı bir API token'ı verirsiniz. DNS-01, 80 ve 443 portları internetten erişilebilir olmadığında da çalışır, örneğin yalnızca dahili bir sunucuda.

Token'ı Caddyfile'ın dışında tutun: systemd unit'inin kullandığı bir ortam dosyasına koyun (`sudo systemctl edit caddy`, ardından `[Service]` altında `EnvironmentFile=/etc/caddy/caddy.env`) ve dosyayı `chmod 600` ile kısıtlayın.

# Build Caddy with a DNS provider module (example: Cloudflare)
xcaddy build --with github.com/caddy-dns/cloudflare

# Caddyfile: one wildcard certificate for all subdomains
*.example.com {
	tls {
		dns cloudflare {env.CF_API_TOKEN}
	}

	@app host app.example.com
	handle @app {
		reverse_proxy 127.0.0.1:3000
	}

	handle {
		respond "Unknown host" 404
	}
}

On-demand TLS ve staging

On-demand TLS, Caddy'nin daha önce görmediği bir hostname için ilk TLS handshake sırasında sertifika almasını sağlar. Müşterilerin kendi alan adlarını sunucunuza yönlendirdiği platformlar için tasarlanmıştır. Her zaman `ask` endpoint'ini yapılandırın: Caddy onu `?domain=name` ile çağırır ve yalnızca 200 yanıtında devam eder. Bu olmadan herkes rastgele adları IP'nize yönlendirip sizi rate limit'lere takabilir.

Deneme yaparken global `acme_ca` seçeneğiyle Let's Encrypt staging CA'sına geçin. Staging sertifikalarına tarayıcılar güvenmez, ama limitler çok daha yüksektir; böylece rahatça bozup düzeltebilirsiniz. İşiniz bitince seçeneği kaldırın ve isterseniz staging sertifikalarını veri dizininden silin.

{
	on_demand_tls {
		ask http://127.0.0.1:5555/allowed
	}
}

https:// {
	tls {
		on_demand
	}
	reverse_proxy 127.0.0.1:8080
}

# Global options block for testing
{
	email [email protected]
	# Test against Let's Encrypt staging; remove when everything works
	acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

Sık görülen Caddy TLS hataları ve çözümleri

1. 01.DNS yönlendirilmemiş: A veya AAAA kaydı eksik, hâlâ eski bir sunucuyu gösteriyor ya da önbellekte. Eskimiş bir AAAA kaydı klasik bir tuzaktır, çünkü CA varsa IPv6'yı tercih eder. Her ikisini de `dig` ile kontrol edin.
2. 02.80 veya 443 portu kapalı: host firewall'u, bir bulut firewall'u veya router gelen trafiği engelliyor, bu yüzden ne HTTP-01 ne de TLS-ALPN-01 tamamlanabiliyor. 80/tcp ve 443/tcp'yi (HTTP/3 için 443/udp'yi de) açın.
3. 03.Port zaten kullanımda: Apache, nginx veya başka bir container 80 ya da 443'e bağlı, bu yüzden Caddy dinleyemiyor. Diğer servisi durdurun veya Caddy'nin arkasına taşıyın.
4. 04.Önde CDN proxy: turuncu bulut tarzı bir proxy TLS'i Caddy'den önce sonlandırır ve bu TLS-ALPN-01'i bozabilir. DNS-01 kullanın veya sertifika alımı sırasında kaydı DNS-only yapın.
5. 05.Rate limit'ler: tekrarlanan başarısız denemeler veya veri dizinini silmek sizi CA limitlerine takar (Let's Encrypt, hostname başına saatlik başarısız doğrulamaları ve haftalık mükerrer sertifikaları sınırlar). Kök nedeni düzeltin, staging kullanın ve veri dizinini kalıcı tutun.
6. 06.CAA kaydı: yalnızca farklı bir CA'ya izin veren bir CAA kaydı sertifika alımını engeller. `letsencrypt.org` ve `sectigo.com`'a (ZeroSSL tarafından kullanılır) izin verin veya kısıtlamayı kaldırın.

# Does the name resolve to this server (both IPv4 and IPv6)?
dig +short A example.com
dig +short AAAA example.com
curl -4 -s https://ifconfig.me ; echo

# Are ports 80 and 443 open in the host firewall?
sudo ufw status
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 443/udp

# Is something else already bound to 80/443?
sudo ss -ltnp '( sport = :80 or sport = :443 )'

# What does Caddy say?
sudo journalctl -u caddy --no-pager -n 100

Backend'e de HTTPS

Aynı hosttaki backend'lerin çoğu localhost üzerinde düz HTTP konuşur ve bu sorun değildir. Upstream başka bir makinedeyse veya TLS'te ısrar ediyorsa, `https://` upstream kullanın ve Caddy'ye hangi adı doğrulayacağını ve hangi CA'ya güveneceğini söyleyin. Hızlı testler dışında `tls_insecure_skip_verify`'dan kaçının, çünkü proxy ile backend arasındaki dinlemeye karşı korumayı kaldırır. Sunucular arası trafik için özel bir WireGuard tüneli çoğu zaman backend sertifikalarını yönetmekten daha basittir.

Tam root ve dedicated IPv4 adresine sahip bir NoctisNode VPS'inde olağan kurulum şudur: sunucuya bir A kaydı yönlendirin (sunucuda IPv6 yoksa AAAA yok), 80 ve 443'ü açın ve gerisini Caddy'ye bırakın. HTTP olmayan trafiği iletmeniz gerekiyorsa bkz. Caddy TCP ve SSH proxy.

example.com {
	reverse_proxy https://10.0.0.5:8443 {
		transport http {
			tls_server_name backend.internal
			tls_trust_pool file /etc/caddy/backend-ca.pem
		}
	}
}

SSS