Let’s Encrypt #

Let’s Encrypt adalah Certificate Authority (CA) nirlaba yang menyediakan sertifikat TLS gratis, otomatis, dan terbuka untuk siapa saja. Diluncurkan pada November 2015 oleh Internet Security Research Group (ISRG), Let’s Encrypt telah merevolusi web dengan menerbitkan lebih dari tiga miliar sertifikat dan menjadi CA paling banyak digunakan di dunia. Perannya sangat krusial dalam mendorong adopsi enkripsi HTTPS global dari sekitar 40% pada tahun 2015 menjadi lebih dari 80% saat ini.

Caddy dirancang dengan Let’s Encrypt sebagai CA utama bawaan (default). Integrasi ini bersifat native dan berjalan langsung tanpa memerlukan pustaka atau program pembantu eksternal. Bagi pengembang dan administrator sistem, ini berarti kita tidak perlu lagi pusing memikirkan siklus hidup sertifikat. Cukup cantumkan nama domain pada Caddyfile, dan Caddy akan mengurus seluruh proses permohonan, verifikasi, penyimpanan, hingga pembaruan sertifikat Let’s Encrypt secara otomatis di latar belakang.

Cara Kerja Otomatisasi Let’s Encrypt di Caddy #

Caddy menangani seluruh siklus hidup sertifikat Let’s Encrypt secara mandiri tanpa intervensi manual dari kita. Proses ini dikelola oleh mesin manajemen sertifikat internal Caddy yang sangat andal.

Saat Caddy pertama kali dimulai atau ketika domain baru ditambahkan:

1. Pembuatan Kunci Akun ACME:
   Caddy membuat pasangan kunci kriptografi baru untuk mewakili akun kita di Let's Encrypt
   (proses ini hanya terjadi sekali dan disimpan di penyimpanan persisten Caddy).
   
2. Permohonan Sertifikat:
   Caddy menghubungi endpoint ACME Let's Encrypt dan membuat pesanan (Order) baru untuk
   setiap nama domain unik yang tercantum dalam konfigurasi Caddyfile.
   
3. Penyelesaian Tantangan (Challenge):
   Caddy melakukan tantangan HTTP-01 (default) atau DNS-01 (jika dikonfigurasi). Untuk HTTP-01,
   Caddy secara otomatis menyajikan token challenge pada port 80.
   
4. Pengunduhan & Pemasangan:
   Setelah verifikasi oleh Let's Encrypt sukses, Caddy mengunduh sertifikat berformat DER,
   mengonversinya, menyimpannya di folder data, dan memasangnya pada mesin TLS aktif.

Secara berkelanjutan (Proses Daemon di Latar Belakang):
5. Pemeriksaan Berkala:
   Caddy memeriksa seluruh sertifikat di penyimpanan setiap ~10 menit.
   
6. Inisiasi Pembaruan (Renewal):
   Jika masa berlaku sertifikat tersisa <= 30 hari, Caddy akan memulai pembaruan latar belakang.
   
7. Pembaruan Tanpa Downtime:
   Setelah sertifikat baru diperoleh, Caddy langsung menggunakannya untuk koneksi baru tanpa
   memerlukan proses restart atau reload layanan yang dapat mengganggu pengguna.

Konfigurasi Minimal (Zero Configuration) #

Salah satu keunggulan terbesar Caddy adalah tidak dibutuhkannya konfigurasi TLS yang rumit untuk mendapatkan sertifikat Let’s Encrypt produksi. Untuk domain publik yang catatan DNS-nya sudah diarahkan ke IP server kita, Caddyfile hanya memerlukan baris seperti berikut:

# Konfigurasi minimal Caddyfile
example.com {
    root * /var/www/html
    file_server
}

Mekanisme otomatis di balik layar ketika Caddy memuat konfigurasi ini:

• Analisis Nama Host: Caddy memindai konfigurasi dan mendeteksi bahwa example.com adalah nama domain publik yang valid.
• Pemberian Hak TLS Otomatis: Caddy mengaktifkan Automatic HTTPS untuk domain tersebut.
• Inisiasi ACME: Caddy menghubungi server Let’s Encrypt, menjawab tantangan HTTP-01 di port 80 secara internal, menerima sertifikat, dan mengaktifkan port 443 dengan konfigurasi TLS modern.
• Pengalihan HTTP ke HTTPS: Caddy secara otomatis membuat server HTTP di port 80 untuk mengalihkan (redirect) semua lalu lintas tidak aman ke HTTPS secara permanen (301 redirect), kecuali untuk jalur /.well-known/acme-challenge/ yang digunakan oleh ACME.

Menambahkan Kontak Email (Sangat Direkomendasikan) #

Meskipun Caddy dapat berjalan tanpa alamat email untuk akun ACME (menggunakan akun anonim), kita sangat disarankan untuk menentukan alamat email di opsi global Caddyfile.

# Opsi global untuk menentukan email ACME
{
    email [email protected]
}

example.com {
    file_server
}

Mengapa Email Ini Penting? #

• Notifikasi Kegagalan Pembaruan: Jika server Caddy kita mengalami kegagalan pembaruan sertifikat secara terus-menerus (misalnya karena aturan firewall yang tidak sengaja memblokir port 80) dan masa kedaluwarsa tersisa kurang dari 20 hari, Let’s Encrypt akan mengirimkan email peringatan ke alamat tersebut.
• Pemberitahuan Perubahan Kebijakan: Let’s Encrypt menggunakan email kontak untuk memberitahu pengguna mengenai perubahan besar pada API, pencabutan sertifikat karena masalah keamanan, atau pembaruan syarat layanan.
• Pemulihan Akun ACME: Kunci akun ACME kita diasosiasikan dengan email ini, membantu proses pemulihan jika folder penyimpanan Caddy terhapus tanpa sengaja.

Arsitektur Rantai Kepercayaan (Chain of Trust) Let’s Encrypt #

Untuk memastikan sertifikat yang diterbitkan oleh Let’s Encrypt dipercayai oleh miliaran perangkat di seluruh dunia, Let’s Encrypt menggunakan arsitektur rantai kepercayaan (chain of trust) yang terstruktur dengan baik.

flowchart TD
    Browser["Root CA Terpercaya di Browser/Sistem Operasi"] --> ISRG["ISRG Root X1 (Root CA Let's Encrypt)"]
    
    ISRG --> R["R10 / R11 (Intermediate CAs)"]
    ISRG --> E["E5 / E6 (Intermediate CAs)"]
    
    R --> Leaf["Sertifikat Web Kita (Leaf Certificate)"]
    E --> Leaf

    style Browser stroke:#0288d1,stroke-width:2px
    style Leaf stroke:#43a047,stroke-width:2px

Komponen Rantai Kepercayaan Let’s Encrypt: #

1. ISRG Root X1: Sertifikat akar (root certificate) utama milik Let’s Encrypt. Saat ini telah di-trust secara langsung oleh hampir semua sistem operasi, browser web modern, dan perangkat pintar.
2. Intermediate CAs (R10, R11, E5, E6): Let’s Encrypt tidak menerbitkan sertifikat web langsung dari kunci akar ISRG Root X1 demi alasan keamanan. Mereka menggunakan sertifikat perantara (intermediate). Rantai R (seperti R10 dan R11) menggunakan algoritma RSA, sedangkan rantai E (seperti E5 dan E6) menggunakan algoritma ECDSA yang lebih cepat dan efisien.
3. Leaf Certificate: Sertifikat akhir yang diterbitkan untuk nama domain kita dengan masa berlaku 90 hari.

Sejarah Cross-Signing dengan DST Root CA X3 #

Pada masa awal pendiriannya, Let’s Encrypt belum dipercayai oleh sistem operasi lama. Oleh karena itu, ISRG Root X1 ditandatangani silang (cross-signed) oleh DST Root CA X3 milik IdenTrust yang sudah sangat tua.

Skema penandatanganan silang ini telah berakhir sepenuhnya pada September 2024. Saat ini, Let’s Encrypt beroperasi secara independen menggunakan rantai ISRG Root X1 murni. Caddy secara otomatis mengunduh rantai sertifikat (chain) yang paling kompatibel dan aman untuk disajikan ke browser pengguna selama jabat tangan TLS berlangsung.

Struktur Penyimpanan Sertifikat Caddy #

Caddy menyimpan kunci akun ACME, kunci privat domain, dan sertifikat di lokasi penyimpanan yang terstruktur dengan aman. Secara default, lokasi folder penyimpanan ini bergantung pada sistem operasi tempat Caddy dijalankan:

• Linux (Systemd): /var/lib/caddy/.local/share/caddy/
• Linux (User biasa): ~/.local/share/caddy/
• macOS: ~/Library/Application Support/Caddy/
• Windows: %APPDATA%\Caddy\

Berikut adalah visualisasi struktur pohon (directory tree) penyimpanan Caddy untuk Let’s Encrypt:

caddy/
  ├── certificates/
  │   └── acme-v02.api.letsencrypt.org-directory/
  │       └── example.com/
  │           ├── example.com.crt       # Sertifikat TLS (X.509 PEM format)
  │           ├── example.com.json      # Metadata sertifikat (tanggal expire, dll.)
  │           └── example.com.key       # Kunci privat domain (SANGAT RAHASIA)
  └── acme/
      └── acme-v02.api.letsencrypt.org-directory/
          └── users/
              └── [email protected]/
                  ├── registration.json # Registrasi akun ACME
                  └── user.key          # Kunci privat akun ACME

Setiap nama domain memiliki subdirektori tersendiri yang berisi file sertifikat (.crt), kunci privat (.key), dan file metadata pendukung (.json).

[!CAUTION] Jangan pernah memberikan hak akses baca atau tulis pada folder penyimpanan ini kepada pengguna lain yang tidak berwenang. Kunci privat domain (.key) dan kunci akun (user.key) adalah file yang sangat rahasia. Jika kunci ini bocor, pihak luar dapat melakukan intersepsi data TLS atau berpura-pura menjadi server kita. Set permission folder ini secara ketat (seperti chmod 700 untuk folder dan chmod 600 untuk file).

Shared Storage untuk Klaster Caddy #

Dalam skenario deployment skala besar dengan beberapa instansi Caddy berjalan di belakang penyeimbang beban (load balancer), menggunakan penyimpanan lokal pada disk masing-masing server akan menimbulkan masalah:

• Setiap instansi Caddy akan meminta sertifikat Let’s Encrypt yang terpisah untuk domain yang sama, sehingga menguras batas rate limit dengan cepat.
• Instansi Caddy yang menerima tantangan verifikasi ACME mungkin berbeda dengan instansi yang membuat permohonan awal.

Untuk mengatasi ini, Caddy memiliki kemampuan untuk menggunakan Penyimpanan Bersama (Shared Storage). Caddy mendukung berbagai modul penyimpanan eksternal yang di-compile menggunakan xcaddy:

# Contoh konfigurasi Caddyfile dengan Shared Storage Redis
{
    storage redis {
        host     "192.168.1.50"
        port     6379
        db       0
        password "sandi-redis-rahasia"
        timeout  5s
    }
}

example.com {
    reverse_proxy localhost:8080
}

Cara Kerja Shared Storage Caddy: #

1. Sinkronisasi Kunci (Distributed Locking): Ketika salah satu instansi Caddy ingin memperbarui sertifikat untuk example.com, ia membuat kunci kunci terdistribusi (distributed lock) di Redis.
2. Berbagi Sertifikat: Instansi Caddy pertama menyelesaikan tantangan ACME dan mengunduh sertifikat baru, lalu menyimpannya langsung di Redis.
3. Penggunaan Bersama: Instansi Caddy lainnya mendeteksi sertifikat baru di Redis, mengunduhnya ke memori lokal mereka, dan menggunakannya secara instan. Ini menjamin efisiensi kuota Let’s Encrypt dan menghilangkan redudansi proses.

Multiple Domain dan Subject Alternative Names (SAN) #

Caddy sangat fleksibel dalam mengelola banyak domain. Kita bisa menentukan domain secara terpisah di setiap blok site atau menggabungkannya dalam satu blok.

{
    email [email protected]
}

# Blok 1: Domain Tunggal
example.com {
    file_server
}

# Blok 2: Subdomain Terpisah
api.example.com {
    reverse_proxy localhost:8080
}

# Blok 3: Gabungan Beberapa Domain (SAN Certificate)
# Caddy akan meminta satu sertifikat yang mencakup kedua domain di bawah
app.example.com, staging.example.com {
    reverse_proxy localhost:3000
}

Ketika beberapa domain digabungkan dengan koma seperti pada Blok 3, Caddy akan meminta sertifikat SAN (Subject Alternative Names). Sertifikat ini memiliki satu nama umum (Common Name) di bagian subjek, tetapi menyertakan domain tambahan pada ekstensi SAN:

Subjek Sertifikat:
  CN = app.example.com

Ekstensi Subject Alternative Name (SAN):
  DNS Name = app.example.com
  DNS Name = staging.example.com

Penggunaan sertifikat SAN sangat baik untuk mengurangi jumlah pertukaran jabat tangan ACME dan mempercepat waktu deployment untuk layanan yang berjalan pada beberapa subdomain yang saling berkaitan.

Memantau dan Memverifikasi Status Sertifikat #

Untuk memastikan sertifikat Let’s Encrypt berjalan dengan benar di lingkungan produksi, kita perlu mengetahui beberapa metode untuk memeriksa statusnya secara berkala.

1. Kueri via Caddy Admin API #

Caddy menyediakan endpoint API administratif lokal yang mendengarkan di port 2019 secara default. Kita bisa mengambil konfigurasi TLS aktif dalam format JSON:

# Mengambil konfigurasi TLS yang sedang berjalan
curl -s http://localhost:2019/config/apps/tls/ | jq .

# Memeriksa daftar kebijakan otomatisasi ACME
curl -s http://localhost:2019/config/apps/tls/automation/policies/ | jq .

2. Pemeriksaan dengan OpenSSL #

Kita dapat memeriksa sertifikat SSL yang disajikan oleh Caddy secara eksternal menggunakan perkakas baris perintah openssl:

# Mengambil detail sertifikat lengkap dari luar
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text

# Hanya memeriksa masa berlaku (tanggal kedaluwarsa) sertifikat
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates
# Output ideal:
# notBefore=Jun 16 00:00:00 2026 GMT
# notAfter=Sep 14 00:00:00 2026 GMT

Analisis Komparatif: Certbot vs Caddy #

Bagi pengguna yang bermigrasi dari setup tradisional (seperti Apache/Nginx + Certbot), berikut adalah perbandingan arsitektural antara pendekatan Certbot dan manajemen TLS internal milik Caddy:

Ringkasan #

• Let’s Encrypt — Certificate Authority utama bawaan (default) di Caddy yang menyediakan sertifikat TLS gratis, otomatis, dan terpercaya secara universal.
• Konfigurasi Minimal — Caddy secara otomatis mengaktifkan HTTPS, redirect HTTP ke HTTPS, dan menyelesaikan tantangan ACME untuk setiap domain publik tanpa konfigurasi TLS tambahan.
• Email Kontak — Kita sangat disarankan untuk mengatur alamat email pada opsi global Caddyfile sebagai sarana notifikasi darurat terkait status kedaluwarsa sertifikat.
• Struktur Penyimpanan — Sertifikat dan kunci privat disimpan secara terstruktur di folder data lokal Caddy (misal /var/lib/caddy/ di Linux) dengan izin keamanan yang ketat.
• Shared Storage — Untuk deployment klaster multi-server, gunakan modul penyimpanan terdistribusi (seperti Redis) untuk sinkronisasi sertifikat dan menghindari batas limit Let’s Encrypt.
• Sertifikat SAN — Caddy otomatis mengemas beberapa domain dalam satu blok konfigurasi menjadi satu sertifikat menggunakan ekstensi Subject Alternative Name (SAN).

← Sebelumnya: Konsep ACME   Berikutnya: ZeroSSL →