Caddy ऑटोमैटिक HTTPS: Caddy का ऑटो TLS कैसे काम करता है और समस्याओं का समाधान

संक्षेप में: Caddy हर उस साइट एड्रेस के लिए HTTPS अपने-आप चालू कर देता है जो एक सार्वजनिक डोमेन नाम हो। यह ACME के ज़रिए सर्टिफ़िकेट माँगता है (डिफ़ॉल्ट रूप से Let's Encrypt या ZeroSSL), पोर्ट 80 और 443 पर HTTP-01 या TLS-ALPN-01 चैलेंज से डोमेन पर नियंत्रण साबित करता है, HTTP को HTTPS पर रीडायरेक्ट करता है, और सर्टिफ़िकेट की मियाद ख़त्म होने से पहले उसे रिन्यू कर देता है — बिना किसी अतिरिक्त कॉन्फ़िगरेशन के।

Caddy reverse proxy का मतलब बस इतना है कि Caddy वह HTTPS कनेक्शन टर्मिनेट करता है और `reverse_proxy` डायरेक्टिव से रिक्वेस्ट को किसी दूसरे पोर्ट, कंटेनर या होस्ट पर चल रहे ऐप तक भेज देता है। कुछ ही लाइनों में TLS और प्रॉक्सी — यही संयोजन लोगों के इसे चुनने की मुख्य वजह है।

तीन लाइनों में SSL के साथ reverse proxy

DNS सर्वर की ओर पॉइंट हो और पोर्ट 80 व 443 पहुँच में हों, तो यह Caddyfile दो होस्टनेम के लिए पूरा HTTPS reverse proxy है। Caddy स्टार्टअप पर दोनों नामों के सर्टिफ़िकेट ले लेता है, HTTP/1.1, HTTP/2 और HTTP/3 सर्व करता है, और बैकएंड को `X-Forwarded-For`, `X-Forwarded-Proto` और `X-Forwarded-Host` भेजता है। `email` विकल्प ज़रूरी नहीं है, लेकिन इससे CA आपको एक्सपायर होने वाले या रद्द किए गए सर्टिफ़िकेट के बारे में सूचित कर सकता है।

आधिकारिक apt रिपॉज़िटरी से इंस्टॉलेशन और systemd की बुनियादी बातें Caddy reverse proxy गाइड में हैं; कंटेनरों के लिए Docker reverse proxy के रूप में Caddy देखें। बदलाव `sudo systemctl reload caddy` से लागू करें।

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

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

Caddy का ऑटो TLS अंदर से कैसे काम करता है

कॉन्फ़िग लोड करते समय Caddy साइट एड्रेस से हर होस्टनेम इकट्ठा करता है और तय करता है कि हर सर्टिफ़िकेट कौन जारी करेगा। सार्वजनिक डोमेन सार्वजनिक ACME जारीकर्ताओं के पास जाते हैं; `localhost`, IP एड्रेस और केवल-आंतरिक नामों को Caddy के अपने लोकल CA से सर्टिफ़िकेट मिलते हैं (`tls internal` लिखने के बराबर)। सर्टिफ़िकेट, कीज़ और ACME अकाउंट Caddy की डेटा डायरेक्टरी में रहते हैं: apt पैकेज में `/var/lib/caddy/.local/share/caddy`, आधिकारिक Docker इमेज में `/data`।

रिन्यूअल बैकग्राउंड में मियाद ख़त्म होने से काफ़ी पहले हो जाता है, और जहाँ CA सपोर्ट करे वहाँ Caddy OCSP रिस्पॉन्स स्टेपल करता है। अगर सर्टिफ़िकेट जारी होने में विफलता हो, तो Caddy exponential backoff के साथ दोबारा कोशिश करता है और प्रोडक्शन रेट लिमिट बचाने के लिए रीट्राई में CA का staging एंडपॉइंट इस्तेमाल करता है। एक ही स्टोरेज साझा करने वाले कई Caddy इंस्टेंस आपस में तालमेल रखते हैं ताकि किसी सर्टिफ़िकेट को सिर्फ़ एक ही माँगे।

DNS-01 से वाइल्डकार्ड सर्टिफ़िकेट

`*.example.com` जैसे वाइल्डकार्ड सर्टिफ़िकेट सिर्फ़ DNS-01 चैलेंज से जारी हो सकते हैं। सामान्य Caddy बाइनरी में DNS प्रोवाइडर प्लगइन नहीं होते, इसलिए xcaddy से अपना बिल्ड बनाएँ (या आधिकारिक डाउनलोड पेज पर प्रोवाइडर चुनें) और Caddy को ऐसा API टोकन दें जो सिर्फ़ उस ज़ोन का DNS एडिट कर सके। DNS-01 तब भी काम करता है जब पोर्ट 80 और 443 इंटरनेट से पहुँच में न हों, जैसे किसी केवल-आंतरिक सर्वर पर।

टोकन को Caddyfile से बाहर रखें: उसे systemd यूनिट द्वारा इस्तेमाल होने वाली environment फ़ाइल में डालें (`sudo systemctl edit caddy`, फिर `[Service]` के नीचे `EnvironmentFile=/etc/caddy/caddy.env`) और फ़ाइल को `chmod 600` से सीमित करें।

# 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 और staging

On-demand TLS से Caddy किसी ऐसे होस्टनेम के लिए, जिसे उसने पहले नहीं देखा, पहले TLS हैंडशेक के दौरान सर्टिफ़िकेट ले लेता है। यह उन प्लेटफ़ॉर्म के लिए है जहाँ ग्राहक अपने डोमेन आपके सर्वर की ओर पॉइंट करते हैं। हमेशा `ask` एंडपॉइंट कॉन्फ़िगर करें: Caddy उसे `?domain=name` के साथ कॉल करता है और सिर्फ़ 200 रिस्पॉन्स मिलने पर आगे बढ़ता है। इसके बिना कोई भी मनमाने नाम आपके IP की ओर पॉइंट करके आपको रेट लिमिट तक पहुँचा सकता है।

प्रयोग करते समय ग्लोबल `acme_ca` विकल्प से Let's Encrypt के staging CA पर स्विच करें। Staging सर्टिफ़िकेट पर ब्राउज़र भरोसा नहीं करते, लेकिन उसकी लिमिट कहीं ज़्यादा हैं, इसलिए आप बेझिझक चीज़ें तोड़-जोड़ सकते हैं। काम पूरा होने पर विकल्प हटा दें, और चाहें तो डेटा डायरेक्टरी से staging सर्टिफ़िकेट भी मिटा दें।

{
	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
}

Caddy TLS की आम गड़बड़ियाँ और उनका समाधान

1. 01.DNS पॉइंट नहीं है: A या AAAA रिकॉर्ड मौजूद नहीं है, अब भी पुराने सर्वर की ओर है, या कैश में है। पुराना AAAA रिकॉर्ड एक क्लासिक जाल है, क्योंकि IPv6 मौजूद होने पर CA उसे प्राथमिकता देता है। `dig` से दोनों जाँचें।
2. 02.पोर्ट 80 या 443 बंद: होस्ट फ़ायरवॉल, क्लाउड फ़ायरवॉल या राउटर इनबाउंड ट्रैफ़िक रोक रहा है, इसलिए न HTTP-01 पूरा हो पाता है न TLS-ALPN-01। 80/tcp और 443/tcp खोलें (और HTTP/3 के लिए 443/udp)।
3. 03.पोर्ट पहले से इस्तेमाल में: Apache, nginx या कोई और कंटेनर 80 या 443 पर बँधा है, इसलिए Caddy उन पर listen नहीं कर पाता। दूसरी सर्विस बंद करें या उसे Caddy के पीछे ले जाएँ।
4. 04.आगे CDN प्रॉक्सी: orange-cloud जैसी प्रॉक्सी Caddy से पहले ही TLS टर्मिनेट कर देती है, जिससे TLS-ALPN-01 टूट सकता है। DNS-01 इस्तेमाल करें, या सर्टिफ़िकेट जारी होने के दौरान रिकॉर्ड को DNS-only पर रखें।
5. 05.रेट लिमिट: बार-बार विफल प्रयास या डेटा डायरेक्टरी मिटाने से आप CA की लिमिट तक पहुँच जाते हैं (Let's Encrypt प्रति होस्टनेम प्रति घंटे विफल वैलिडेशन और प्रति सप्ताह डुप्लिकेट सर्टिफ़िकेट सीमित करता है)। मूल कारण ठीक करें, staging इस्तेमाल करें, और डेटा डायरेक्टरी को स्थायी रखें।
6. 06.CAA रिकॉर्ड: ऐसा CAA रिकॉर्ड जो सिर्फ़ किसी दूसरे CA को अनुमति देता है, सर्टिफ़िकेट जारी होने से रोक देता है। `letsencrypt.org` और `sectigo.com` (ZeroSSL द्वारा इस्तेमाल) को अनुमति दें या प्रतिबंध हटा दें।

# 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

बैकएंड तक भी HTTPS

एक ही होस्ट पर ज़्यादातर बैकएंड localhost पर सादा HTTP बोलते हैं, और यह ठीक है। जब upstream किसी दूसरी मशीन पर हो या TLS पर ज़ोर दे, तो `https://` upstream इस्तेमाल करें और Caddy को बताएँ कि कौन-सा नाम वेरिफ़ाई करना है और किस CA पर भरोसा करना है। त्वरित टेस्ट के अलावा `tls_insecure_skip_verify` से बचें, क्योंकि यह प्रॉक्सी और बैकएंड के बीच इंटरसेप्शन से सुरक्षा हटा देता है। सर्वरों के बीच ट्रैफ़िक के लिए बैकएंड सर्टिफ़िकेट संभालने से अक्सर एक निजी WireGuard टनल आसान रहती है।

पूरे root और डेडिकेटेड IPv4 एड्रेस वाले NoctisNode VPS पर आम सेटअप यह है: सर्वर की ओर A रिकॉर्ड पॉइंट करें (AAAA तभी जब सर्वर पर IPv6 हो), 80 और 443 खोलें, और बाक़ी Caddy पर छोड़ दें। अगर आपको गैर-HTTP ट्रैफ़िक फ़ॉरवर्ड करना है, तो Caddy से TCP और SSH प्रॉक्सी देखें।

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
		}
	}
}

अक्सर पूछे जाने वाले सवाल