Dalam lanskap operasional web modern, penyediaan enkripsi Transport Layer Security (TLS) bukan lagi fitur opsional, melainkan fondasi wajib. Di masa lalu, administrator sistem terbebani oleh konfigurasi manual OpenSSL, pengelolaan Cron job untuk Certbot (Let’s Encrypt), serta penanganan sertifikat yang kedaluwarsa secara tak terduga. Kehadiran Caddy Server telah mengubah paradigma ini secara radikal melalui arsitektur Automatic HTTPS yang terintegrasi langsung di inti perutean (core engine).
Namun, bagaimana Caddy beroperasi ketika dipadukan dengan arsitektur jaringan privat modern seperti Cloudflare Tunnel (Zero Trust)? Artikel ini membedah arsitektur internal TLS Caddy, mengupas tantangan teknis saat berada di balik reverse proxy edge, dan mendokumentasikan alasan mengapa direktif auto_https off esensial untuk mencegah redirect loop mematikan.
1. Arsitektur Otomatisasi TLS pada Caddy
Secara bawaan (out of the box), Caddy adalah web server pertama yang mengimplementasikan protokol ACME (Automated Certificate Management Environment) secara mandiri tanpa memerlukan daemon eksternal.
+-------------------------------------------------------------------------+
| CADDY ENGINE |
| |
| +------------------+ ACME Challenge +-----------------------+ |
| | Core Router | <--------------------> | CertMagic Engine | |
| | (HTTP/2, HTTP/3)| | (Let's Encrypt / | |
| +------------------+ | ZeroSSL Fallback) | |
| ^ +-----------------------+ |
| | | |
| v v |
| +------------------+ +-----------------------+ |
| | Port 80 & 443 | | Storage: /var/lib/caddy| |
| | Inbound Listener | | (X.509 Keys & Certs) | |
| +------------------+ +-----------------------+ |
+-------------------------------------------------------------------------+
Mekanisme Manajemen Sertifikat (CertMagic)
Di balik layar, Caddy menggunakan pustaka Go bernama CertMagic. Alur kerjanya meliputi:
- Identifikasi Domain Otomatis: Begitu Anda menuliskan nama domain yang memenuhi kualifikasi (FQDN) seperti
example.comdi Caddyfile, Caddy secara otomatis mengasumsikan bahwa domain tersebut membutuhkan TLS. - Multi-CA Redundancy: Caddy menghubungi Let’s Encrypt secara default. Jika terjadi gangguan jaringan atau rate limit pada Let’s Encrypt, Caddy secara cerdas beralih (fallback) ke ZeroSSL tanpa intervensi manual.
- ACME Challenge: Caddy memvalidasi kepemilikan domain melalui
HTTP-01 challenge(pada port 80) atauTLS-ALPN-01 challenge(pada port 443). Jika plugin DNS ditambahkan, Caddy juga mendukungDNS-01 challengeuntuk sertifikat wildcard. - Perpanjangan Sertifikat Otomatis (Auto-Renewal): Sertifikat diperiksa setiap hari dan diperpanjang secara proaktif ketika masa berlaku tersisa 30 hari, meniadakan insiden situs down akibat sertifikat basi.
2. Dilema Arsitektur: Caddy di Belakang Cloudflare Tunnel
Ketika sebuah server diisolasi total tanpa port publik terbuka—seperti infrastruktur di Lab Regsi—pola interaksi berubah. Di sini, server tidak menerima koneksi internet langsung, melainkan melalui Cloudflare Tunnel (cloudflared).
[ Klien Internet ]
|
| HTTPS (Port 443) -> TLS di-terminate di Edge
v
+-------------------------------+
| Cloudflare Edge CDN |
| (Edge SSL: Universal / ACM) |
+-------------------------------+
|
| Outbound Encrypted QUIC Tunnel (Port 7844)
v
+-------------------------------+
| cloudflared Daemon (Lokal) |
+-------------------------------+
|
| Plain HTTP (127.0.0.1:80)
v
+-------------------------------+
| Caddy Web Server |
| (Listening on port 80) |
+-------------------------------+
Masalah 1: Kegagalan Validasi ACME
Jika Caddy tetap dibiarkan dalam mode default, Caddy akan berusaha melakukan binding ke port 443 dan menghubungi Let’s Encrypt untuk memvalidasi tantangan ACME. Namun, karena router lokal tidak membuka port 80 atau 443 ke internet publik, server Let’s Encrypt tidak akan pernah bisa menjangkau Caddy secara langsung. Akibatnya, proses booting Caddy mengalami handshake timeout berulang kali.
Masalah 2: Jebakan Infinite Redirect Loop (ERR_TOO_MANY_REDIRECTS)
Secara default, jika Caddy mendeteksi port 80 dipanggil untuk domain berkualifikasi HTTPS, Caddy akan merespons dengan header 308 Permanent Redirect mengarahkan klien ke skema https://:
HTTP/1.1 308 Permanent Redirect
Location: https://regsi.my.id/
Pada saat yang sama, Cloudflare Tunnel meneruskan request dari edge ke Caddy melalui http://localhost:80. Ketika Caddy membalas dengan kode 308, Cloudflare Edge meneruskan redirect tersebut kembali ke browser pengguna. Browser pengguna kemudian meminta kembali URL HTTPS ke Cloudflare Edge, yang selanjutnya diteruskan lagi ke Caddy via HTTP port 80. Lingkaran setan ini berulang puluhan kali hingga browser menghentikan koneksi dengan pesan error legendaris: ERR_TOO_MANY_REDIRECTS.
3. Solusi Elegan: Direktif Global auto_https off
Untuk mengintegrasikan Caddy secara harmonis dengan Cloudflare Tunnel, kita melakukan SSL/TLS Offloading. Enkripsi TLS publik ditangani sepenuhnya oleh Cloudflare Edge, sedangkan komunikasi internal antara daemon cloudflared dan Caddy berlangsung super cepat di loopback interface port 80.
Untuk menonaktifkan mekanisme ACME otomatis dan mematikan auto-redirect HTTP->HTTPS di Caddy, kita mendefinisikan blok global pada baris teratas Caddyfile:
{
auto_https off
admin off
}
http://regsi.my.id:80 {
root * /srv/www/lab
encode gzip zstd
try_files {path} {path}/ /404.html
@is404 path /404.html
file_server @is404 {
status 404
}
file_server
header {
X-Content-Type-Options "nosniff"
Referrer-Policy "strict-origin-when-cross-origin"
}
log {
output file /var/log/caddy/lab.log
}
}
Bedah Konfigurasi:
auto_https off: Menonaktifkan listener HTTPS port 443, menghentikan percobaan kontak ke Let’s Encrypt, dan menonaktifkan HTTP-to-HTTPS redirect handler. Caddy kini bertindak sebagai HTTP origin server murni yang fokus pada penyajian konten dan kompresi.http://regsi.my.id:80: Secara eksplisit mendefinisikan skemahttp://dan port80. Hal ini menegaskan kepada Caddy bahwa virtual host ini tidak mengharapkan negosiasi TLS langsung di tingkat socket lokal.encode gzip zstd: Mengaktifkan kompresi modern Zstandard (zstd) dan Gzip. Respons HTML/CSS/JS dikompresi sebelum diserahkan kecloudflared, memangkas penggunaan bandwidth dan mempercepat transfer data.try_files {path} {path}/ /404.html: Penanganan routing situs statis yang bersih, mengarahkan berkas yang tidak ditemukan ke halaman 404 kustom dengan status HTTP 404 asli.
4. Keuntungan Performa & Keamanan
Pemisahan tanggung jawab (separation of concerns) ini memberikan sejumlah keuntungan strategis:
- Nol Konsumsi Memori untuk Cert Storage: Caddy tidak perlu menyimpan ratusan sertifikat di RAM atau memantau status renewal di disk lokal.
- Zero TLS Overhead pada Origin Host: Beban komputasi enkripsi asimetris kurva elips (ECDSA/RSA) dialihkan ke infrastruktur server Anycast Cloudflare yang tersebar di lebih dari 300 kota di dunia.
- Perlindungan Terhadap Serangan MITM Lokal: Karena transmisi antara
cloudflareddan Caddy terjadi di memori internal kernel Linux (127.0.0.1), paket data tidak pernah melintasi kabel jaringan fisik lokal tanpa enkripsi.
5. Kesimpulan & Rekomendasi Praktik Terbaik
Caddy Server adalah perangkat lunak revolusioner untuk pengelolaan TLS modern. Namun, dalam arsitektur terisolasi di mana ingress publik diorkestrasi oleh Cloudflare Tunnel, menonaktifkan manajemen TLS lokal via auto_https off adalah langkah rekayasa sistem yang tepat dan presisi.
Dengan konfigurasi ini, Anda mendapatkan kombinasi terbaik: keamanan edge kelas dunia dari Cloudflare, performa kompresi Zstandard super cepat dari Caddy, dan lingkungan server lokal yang terisolasi total dari pemindaian bot internet liar.
Regsi Wahyu Saputra
Praktisi rekayasa sistem, pengembang software, dan operator homelab. Menulis tentang arsitektur jaringan, Caddy reverse proxy, Cloudflare Zero Trust, dan automasi mobile testing.