Konsep ACME #

Protokol Automated Certificate Management Environment (ACME) adalah standar terbuka yang mendefinisikan bagaimana server web membuktikan kepemilikan nama domain ke Certificate Authority (CA) untuk memperoleh sertifikat TLS secara otomatis. Sebelum kehadiran ACME, memperoleh sertifikat TLS merupakan proses manual yang rentan terhadap kesalahan, mahal, dan membutuhkan intervensi administrator secara berkala. Standarisasi ACME dalam RFC 8555 telah mengubah lanskap keamanan web dengan memungkinkan otomatisasi penuh siklus hidup sertifikat, mulai dari permohonan, verifikasi, penerbitan, hingga pembaruan sebelum masa berlaku habis.

Di dalam ekosistem Caddy, protokol ACME terintegrasi secara langsung pada tingkat sistem. Caddy bertindak sebagai klien ACME yang sangat cerdas, mengelola seluruh proses di latar belakang tanpa memerlukan perkakas tambahan seperti cronjob atau skrip eksternal. Memahami konsep dasar ACME dan cara kerja verifikasinya bukan sekadar teori akademis, melainkan keterampilan esensial untuk mendiagnosis kegagalan pembaruan, merancang arsitektur jaringan yang aman, dan memecahkan masalah konfigurasi TLS di lingkungan produksi.

Sejarah Singkat: Sebelum Era ACME #

Untuk mengapresiasi efisiensi yang ditawarkan oleh ACME, kita perlu melihat kembali bagaimana sertifikat TLS diperoleh dan dikelola pada masa lalu. Proses tersebut tidak hanya memakan waktu, tetapi juga menjadi beban operasional yang signifikan bagi tim infrastruktur.

Proses mendapatkan sertifikat TLS tradisional sebelum ACME:

1. Pembuatan Kunci Privat & CSR:
   Administrator membuat private key dan Certificate Signing Request (CSR) di server.
   
2. Registrasi dan Pembayaran di CA Komersial:
   CSR dikirim ke CA komersial (seperti Symantec, DigiCert, Comodo) secara manual.
   Proses ini membutuhkan pembayaran biaya tahunan ($50 hingga ratusan dolar per domain).
   
3. Verifikasi Identitas Manual:
   CA melakukan verifikasi organisasi atau kepemilikan domain melalui email administrasi,
   panggilan telepon, atau pengiriman dokumen hukum (bisa memakan waktu berhari-hari).
   
4. Pemasangan Sertifikat:
   Sertifikat yang diterbitkan dikirim melalui email, lalu diunduh dan dipasang secara manual
   pada konfigurasi server web (Nginx, Apache, IIS).
   
5. Pemeliharaan dan Pembaruan Tahunan:
   Sertifikat biasanya berlaku selama 1 hingga 2 tahun. Administrator harus mencatat tanggal
   kedaluwarsa dan mengulangi seluruh proses di atas sebelum masa berlaku habis.

Kelemahan terbesar dari sistem tradisional ini adalah faktor manusia. Banyak insiden mati mendadak (downtime) pada situs-situs besar terjadi hanya karena administrator lupa memperbarui sertifikat yang kedaluwarsa. Kehadiran Let’s Encrypt pada tahun 2015 dengan protokol ACME-nya berhasil mendemokratisasi HTTPS dengan menjadikannya gratis, otomatis, dan dapat diakses oleh siapa saja.

Arsitektur Protokol ACME (RFC 8555) #

Di bawah spesifikasi RFC 8555, ACME menggunakan arsitektur RESTful di atas HTTPS. Klien ACME (dalam hal ini, Caddy) berkomunikasi dengan Server ACME (seperti Let’s Encrypt atau ZeroSSL) menggunakan format data JSON yang ditandatangani secara kriptografis menggunakan JSON Web Signature (JWS).

Protokol ini mendefinisikan beberapa jenis sumber daya (resources) utama yang memiliki siklus hidup dan hubungan terstruktur:

Setiap Order yang dibuat oleh Caddy akan melahirkan satu atau beberapa Authorization (satu untuk setiap nama domain unik yang diminta). Di dalam setiap Authorization, CA akan menyediakan beberapa pilihan Challenge. Caddy harus berhasil menyelesaikan salah satu dari tantangan tersebut agar status Authorization berubah menjadi valid, yang kemudian memungkinkan penerbitan sertifikat.

Konsep Inti: Mekanisme Domain Validation #

Inti dari protokol ACME adalah memastikan bahwa pihak yang meminta sertifikat benar-benar memiliki kendali atas domain yang diajukan. Proses pembuktian ini disebut sebagai Domain Validation (DV). Protokol ACME menyediakan tiga metode tantangan (challenges) standar untuk memverifikasi kepemilikan ini.

1. Challenge HTTP-01 #

Tantangan HTTP-01 adalah metode verifikasi yang paling banyak digunakan karena kesederhanaannya. Pada metode ini, CA meminta klien untuk menyajikan dokumen teks khusus pada jalur (path) URL tertentu di server web yang bersangkutan.

flowchart TD
    A["Minta Sertifikat untuk example.com"] -->|1. POST /newOrder| B["Berikan Token dan Path URL"]
    B -->|2. JWS Response| C["Buat File Token secara Otomatis"]
    C -->|3. Tulis Token ke URL| D["Lakukan Verifikasi HTTP GET"]
    D -->|4. HTTP GET ke Port 80| C
    D -->|5. Cocok & Valid| E["Terbitkan Sertifikat TLS"]
    E -->|6. Kirim Sertifikat| A

Mekanisme rinci dari alur di atas adalah sebagai berikut:

1. Caddy mengirimkan permohonan sertifikat untuk example.com ke CA.
2. CA memberikan token acak dan menentukan path verifikasi: http://example.com/.well-known/acme-challenge/TOKEN_ID.
3. Caddy secara otomatis menangkap permintaan ini secara internal dan menyiapkan respons berisi token yang telah ditandatangani dengan kunci akun (key authorization).
4. CA melakukan koneksi HTTP GET ke port 80 domain example.com pada jalur tersebut.
5. Jika token yang diterima cocok dengan perhitungan CA, kepemilikan domain dinyatakan valid dan sertifikat diterbitkan.

Persyaratan dan Batasan HTTP-01:

• Akses Port 80: Port HTTP standar (port 80) pada server harus terbuka untuk umum dan dapat diakses dari internet global.
• Resolusi DNS: Domain harus sudah diarahkan (memiliki A/AAAA record) ke IP publik server yang menjalankan Caddy.
• Tanpa Wildcard: Tantangan ini tidak mendukung pembuatan sertifikat wildcard (misalnya *.example.com) karena CA tidak dapat melakukan GET ke host acak secara dinamis.

2. Challenge TLS-ALPN-01 #

Tantangan TLS-ALPN-01 dirancang untuk situasi di mana port HTTP 80 diblokir oleh penyedia layanan internet (ISP) atau aturan firewall, tetapi port HTTPS 443 dapat diakses secara bebas. Metode ini menggunakan ekstensi TLS yang disebut Application-Layer Protocol Negotiation (ALPN) untuk menegosiasikan protokol khusus bernama acme-tls/1 selama proses jabat tangan (handshake) TLS.

Alur Proses TLS-ALPN-01 Challenge:

1. Klien (Caddy) membuat permohonan sertifikat ke CA.
2. CA merespons dengan memberikan token verifikasi khusus.
3. Caddy membuat sertifikat self-signed sementara yang berisi token verifikasi tersebut
   di dalam ekstensi Subject Alternative Name (SAN) dengan OID 1.3.6.1.5.5.7.1.30.
4. CA melakukan koneksi TLS ke port 443 server tujuan.
5. Selama handshake TLS, CA mengirimkan ekstensi ALPN dengan nilai "acme-tls/1".
6. Caddy merespons dengan menyajikan sertifikat self-signed sementara yang telah dibuat.
7. CA memverifikasi tanda tangan dan token di dalam sertifikat tersebut. Jika valid,
   sertifikat asli diterbitkan dan Caddy menghapus sertifikat sementara dari memori.

Persyaratan dan Batasan TLS-ALPN-01:

• Akses Port 443: Port HTTPS standar (port 443) harus terbuka dan dapat diakses langsung dari internet.
• Tanpa Proxy Layer 7: Koneksi TLS harus diselesaikan langsung oleh Caddy. Jika ada reverse proxy atau CDN (seperti Cloudflare dengan enkripsi fleksibel/pemutus TLS) di depan Caddy, tantangan ini akan gagal karena CA akan bernegosiasi dengan proxy, bukan dengan Caddy.
• Tanpa Wildcard: Sama seperti HTTP-01, metode ini tidak dapat digunakan untuk memverifikasi sertifikat wildcard.

3. Challenge DNS-01 #

Tantangan DNS-01 membuktikan kepemilikan domain dengan membuat catatan teks (TXT record) khusus pada zona DNS domain yang bersangkutan. Ini adalah metode yang paling fleksibel dan kuat di antara ketiganya.

flowchart TD
    A["Minta Sertifikat *.example.com"] -->|1. Order| B["Berikan Token Tantangan"]
    B -->|2. Token| C["Buat TXT Record via DNS API"]
    C -->|3. API Call| D["Publikasikan TXT Record"]
    D -.->|4. Propagasi DNS| E["Lakukan Query DNS TXT"]
    E -->|5. Query TXT| D
    E -->|6. Valid| F["Terbitkan Sertifikat TLS"]
    F -->|7. Sertifikat| A
    A -->|8. Selesai| G["Hapus TXT Record (Cleanup)"]

Langkah-langkah eksekusi DNS-01:

1. Caddy meminta sertifikat untuk domain *.example.com (wildcard) atau domain standar.
2. CA mengirimkan token tantangan kriptografis.
3. Caddy menggunakan plugin API DNS yang dikonfigurasi untuk membuat TXT record baru dengan nama _acme-challenge.example.com yang berisi nilai token tersebut.
4. Caddy menunggu beberapa saat hingga catatan DNS tersebut menyebar (propagate).
5. CA melakukan kueri (query) DNS TXT ke server nama (nameserver) domain tersebut.
6. Jika nilai TXT record cocok, verifikasi berhasil dan sertifikat diterbitkan.
7. Caddy menghapus kembali TXT record tersebut untuk menjaga kebersihan zona DNS.

Keunggulan DNS-01:

• Satu-satunya untuk Wildcard: Ini adalah satu-satunya metode yang disetujui oleh CA untuk penerbitan sertifikat wildcard (*.domain.com).
• Server Tersembunyi (Private Network): Server Caddy tidak memerlukan port masuk (inbound ports) 80 atau 443 yang terbuka dari internet. Server di dalam jaringan lokal (LAN) atau di belakang firewall ketat tetap bisa mendapatkan sertifikat publik yang valid asalkan memiliki akses keluar (outbound) untuk memanggil API DNS and API ACME.

Mekanisme Multi-Perspective Validation (MPV) #

Salah satu aspek keamanan krusial yang diadopsi oleh Let’s Encrypt dan CA modern lainnya adalah Multi-Perspective Validation (MPV), yang terkadang disebut sebagai Multi-Perspective Verification.

Mengapa MPV Dibutuhkan? #

Pada masa awal ACME, verifikasi tantangan (misalnya HTTP-01) hanya dilakukan dari satu titik pusat data milik CA. Struktur tunggal ini memiliki celah keamanan serius terhadap serangan jaringan tingkat lanjut seperti BGP Hijacking atau DNS Spoofing lokalan.

Jika penyerang berhasil membajak rute lalu lintas BGP untuk IP server kita di dekat pusat data CA, penyerang dapat mengarahkan lalu lintas verifikasi ke server mereka sendiri, menjawab tantangan ACME, dan mendapatkan sertifikat TLS yang sah untuk domain kita tanpa izin.

Cara Kerja MPV #

Untuk memitigasi risiko ini, CA melakukan verifikasi tantangan dari beberapa wilayah geografis yang berbeda secara bersamaan:

flowchart TD
    Primary["Let's Encrypt US-East (Primary)"]
    
    subgraph Satellites["Satellites Nodes"]
        direction LR
        West["Let's Encrypt US-West"]
        Europe["Let's Encrypt Europe"]
        Asia["Let's Encrypt Asia"]
    end

    Primary -->|"Picu verifikasi"| West
    Primary -->|"Picu verifikasi"| Europe
    Primary -->|"Picu verifikasi"| Asia
    
    West -. "GET / DNS Query" .-> Caddy["Server Caddy Kita"]
    Europe -. "GET / DNS Query" .-> Caddy
    Asia -. "GET / DNS Query" .-> Caddy

    style Primary stroke:#0288d1,stroke-width:2px
    style Caddy stroke:#43a047,stroke-width:2px
    style Satellites stroke:#757575,stroke-width:1px,stroke-dasharray:5,5

CA utama (misalnya di Pantai Timur AS) meminta beberapa node satelitnya di seluruh dunia (misalnya Pantai Barat AS, Eropa, dan Asia) untuk melakukan verifikasi tantangan secara independen. Sertifikat hanya akan diterbitkan jika seluruh atau mayoritas node tersebut melaporkan hasil verifikasi yang sukses dan konsisten.

[!WARNING] Keberadaan MPV membuat praktik membuat daftar putih (whitelisting) IP Let’s Encrypt pada firewall menjadi anti-pattern. Karena Let’s Encrypt menggunakan banyak IP satelit yang terus berubah secara dinamis untuk melakukan validasi dari berbagai sudut pandang global, upaya membatasi akses verifikasi ke IP tertentu pasti akan menyebabkan kegagalan pembaruan (renewal). Cara yang benar adalah membiarkan port 80 terbuka untuk semua IP publik, atau beralih ke DNS-01 challenge yang tidak membutuhkan port terbuka.

Siklus Hidup Sertifikat di Caddy #

Otomatisasi siklus hidup sertifikat pada Caddy dirancang untuk meminimalkan keterlibatan manusia. Gambar di bawah menjelaskan bagaimana Caddy mengambil keputusan saat pertama kali dijalankan atau saat melayani permintaan domain baru.

flowchart TD
    A["Mulai Caddy / Deteksi Konfigurasi Baru"] --> B{"Apakah sertifikat ada di penyimpanan lokal?"}
    B -- Ya --> C{"Apakah sisa waktu aktif > 30 hari?"}
    B -- Tidak --> E["Buat Akun ACME & Buat Pesanan"]
    C -- Ya --> D["Gunakan Sertifikat untuk TLS Handshake"]
    C -- Tidak --> F["Picu Pembaruan Latar Belakang (Renewal)"]
    E --> G["Pilih CA (Let's Encrypt / Fallback ZeroSSL)"]
    G --> H["Pilih dan Jalankan Tantangan (HTTP/TLS/DNS)"]
    H --> I{"Apakah verifikasi berhasil?"}
    I -- Ya --> J["Simpan Sertifikat Baru ke Penyimpanan"]
    I -- Tidak --> K{"Apakah ada CA Alternatif?"}
    K -- Ya --> L["Beralih ke CA Alternatif"]
    L --> H
    K -- Tidak --> M["Log Kesalahan & Jadwalkan Retry dengan Backoff"]
    J --> D
    F --> E

Penjelasan Detil Siklus Hidup: #

1. Pemeriksaan Penyimpanan Lokal: Caddy selalu memeriksa folder penyimpanannya terlebih dahulu sebelum membuat koneksi keluar. Penyimpanan bawaan Caddy berada pada sistem berkas lokal, terisolasi dengan aman dari akses pengguna biasa.
2. Pemicu Pembaruan (Renewal Window): Masa berlaku sertifikat ACME (Let’s Encrypt dan ZeroSSL) adalah 90 hari. Caddy secara proaktif akan memulai proses pembaruan saat sertifikat memasuki 30 hari terakhir masa berlakunya (setelah 60 hari aktif). Rentang waktu yang lebar ini memberikan toleransi yang cukup terhadap potensi gangguan jaringan atau masalah sementara pada sisi CA.
3. Mekanisme Retry dengan Exponential Backoff: Jika proses perolehan sertifikat gagal (misalnya karena DNS belum menyebar atau server CA mengalami gangguan), Caddy tidak akan terus-menerus membanjiri CA dengan permintaan baru. Caddy menjadwalkan ulang percobaan berikutnya menggunakan algoritma exponential backoff: mula-mula menunggu 1 menit, lalu 2 menit, 4 menit, hingga maksimal interval beberapa jam.

Aturan dan Batasan Rate Limit Let’s Encrypt #

Untuk melindungi infrastruktur mereka dari penyalahgunaan dan serangan penolakan layanan (denial of service), Let’s Encrypt menerapkan aturan batas frekuensi (rate limits) yang ketat pada lingkungan produksinya. Memahami batasan ini sangat penting agar kita tidak terkunci dari akses HTTPS saat melakukan migrasi atau pengujian sistem.

Tabel Batas Frekuensi Let’s Encrypt (Production) #

Anti-Pattern di Lingkungan Kontainer (Docker) #

Salah satu penyebab paling umum habisnya kuota rate limit di Let’s Encrypt adalah kelalaian saat mengelola volume data pada lingkungan kontainer seperti Docker atau Kubernetes.

# ANTI-PATTERN: Menjalankan kontainer Caddy tanpa persistensi volume data
services:
  caddy:
    image: caddy:2.8.4
    ports:
      - "80:80"
      - "443:443"
    # ✗ JANGAN: Tidak menyertakan volume untuk direktori /data Caddy

Jika kontainer di atas dihentikan dan dibuat ulang (misalnya setiap kali kita melakukan pembaruan aplikasi), seluruh sertifikat yang telah diperoleh akan hilang dari dalam kontainer. Saat Caddy baru berjalan, ia terpaksa meminta sertifikat baru ke Let’s Encrypt. Setelah 5 kali siklus restart kontainer dalam seminggu, kita akan terkena batas Duplicate Certificate dan situs kita tidak bisa diakses menggunakan HTTPS selama seminggu penuh.

# BENAR: Selalu gunakan named volume untuk folder data dan config Caddy
services:
  caddy:
    image: caddy:2.8.4
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data          # ✓ MENYIMPAN SERTIFIKAT DAN KUNCI AKUN
      - caddy_config:/config      # ✓ MENYIMPAN KONFIGURASI AKTIF

volumes:
  caddy_data:
  caddy_config:

Menggunakan Staging Environment untuk Pengujian #

Ketika kita sedang melakukan uji coba skrip deployment, konfigurasi Caddyfile baru, atau migrasi server besar-besaran, gunakan selalu Staging Environment milik Let’s Encrypt. Lingkungan staging memiliki batas frekuensi yang sangat besar (hingga 30.000 sertifikat per domain per minggu) sehingga aman dari risiko terkunci.

Kita dapat mengaktifkan lingkungan staging dengan menentukan URL direktori staging pada opsi global Caddyfile:

{
    # Menggunakan server staging Let's Encrypt untuk pengujian
    acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
    email [email protected]
}

test.example.com {
    file_server
}

[!WARNING] Sertifikat yang diterbitkan dari lingkungan staging tidak dipercayai oleh browser. Browser akan menampilkan peringatan keamanan merah (Untrusted Connection). Gunakan lingkungan ini murni untuk memastikan bahwa alur verifikasi ACME (HTTP/TLS/DNS) berjalan sukses tanpa error di log Caddy. Setelah terbukti sukses, hapus konfigurasi acme_ca dan muat ulang Caddy untuk mendapatkan sertifikat resmi (production).

Pemecahan Masalah dan Debugging ACME #

Ketika Caddy gagal memperoleh sertifikat, langkah pertama yang harus kita lakukan adalah menganalisis log sistem. Caddy menyediakan pesan kesalahan yang sangat deskriptif yang menunjukkan di bagian mana proses ACME terhenti.

Perintah Diagnosis Esensial #

Berikut adalah beberapa perintah terminal yang wajib dijalankan untuk melacak masalah ACME:

# 1. Memeriksa log Caddy secara real-time untuk mendeteksi kegagalan verifikasi
sudo journalctl -u caddy -f --no-pager | grep -i "acme\|certificate\|challenge"

# 2. Untuk deployment berbasis Docker, periksa log kontainer
docker logs caddy 2>&1 | grep -i -E "error|warn|acme"

# 3. Memeriksa apakah domain publik sudah mengarah ke IP server kita
dig +short example.com
nslookup example.com

# 4. Memverifikasi port 80 dapat diakses dari internet luar
# (Jalankan perintah ini dari komputer luar atau server lain)
curl -Iv http://example.com/.well-known/acme-challenge/test-check

# 5. Memeriksa aplikasi lain yang mungkin memonopoli port 80 atau 443
sudo ss -tlnp | grep -E ':80|:443'

Klasifikasi Kesalahan ACME Umum #

Saat menganalisis log, kita sering menemui beberapa kesalahan standar dari server ACME. Berikut adalah arti dan solusi dari masing-masing kesalahan tersebut:

1. urn:ietf:params:acme:error:connection #

• Penyebab: Server CA tidak dapat menghubungi server Caddy pada port 80 (HTTP-01) atau port 443 (TLS-ALPN-01).
• Solusi: Periksa aturan firewall pada server kita (misalnya ufw, iptables, AWS Security Group, atau Cloudflare SSL settings). Pastikan lalu lintas dari IP manapun di internet diperbolehkan masuk ke port tersebut.

2. urn:ietf:params:acme:error:dns #

• Penyebab: Server CA gagal melakukan resolusi DNS untuk domain yang diminta, atau tidak menemukan TXT record yang diharapkan saat menggunakan tantangan DNS-01.
• Solusi: Periksa kembali nama domain pada Caddyfile. Jika baru saja mengubah DNS record, tunggu hingga propagasi merata atau bersihkan cache DNS resolver lokal kita.

3. urn:ietf:params:acme:error:rateLimited #

• Penyebab: Kita telah melampaui salah satu batas frekuensi yang ditetapkan oleh Let’s Encrypt.
• Solusi: Alihkan konfigurasi sementara ke staging environment atau gunakan ZeroSSL sebagai CA alternatif sampai batas waktu reset terlewati (biasanya 7 hari untuk batas domain terdaftar).

Ringkasan #

• Protokol ACME (RFC 8555) — Standar terbuka yang digunakan oleh Let’s Encrypt dan ZeroSSL untuk mengotomatisasikan siklus hidup sertifikat TLS secara penuh.
• Challenge HTTP-01 — Metode pembuktian domain menggunakan file token di port 80. Ini adalah metode bawaan (default) Caddy. Tidak mendukung wildcard.
• Challenge TLS-ALPN-01 — Metode pembuktian menggunakan negosiasi protokol handshake TLS di port 443. Berguna jika port 80 diblokir. Tidak mendukung wildcard dan tidak boleh di belakang proxy layer 7.
• Challenge DNS-01 — Metode pembuktian menggunakan catatan TXT record DNS. Wajib digunakan untuk sertifikat wildcard (*.domain.com) dan server di dalam jaringan privat.
• Multi-Perspective Validation (MPV) — Teknik CA memvalidasi tantangan dari beberapa wilayah geografis untuk mencegah serangan pembajakan jaringan (BGP hijacking). Jangan membatasi IP CA pada firewall.
• Manajemen Siklus Hidup — Caddy secara cerdas mendeteksi status sertifikat, memulai pembaruan otomatis 30 hari sebelum masa aktif berakhir, dan melakukan percobaan ulang teratur jika terjadi kegagalan.
• Penyimpanan Persisten — Selalu arahkan volume data /data di kontainer Docker ke penyimpanan persisten host agar sertifikat tidak terbuang sia-sia dan menghindari pemblokiran rate limit.

← Sebelumnya: Global Options   Berikutnya: Let’s Encrypt →