Belajar PKI - ACME Protocol & Let's Encrypt

#Pendahuluan

Di episode 7 sebelumnya kalian memasang sertifikat server dan membangun mTLS secara manual. Itu bagus untuk satu atau dua server, tapi bayangkan mengulang langkah yang sama untuk seratus server: membuat CSR, menandatangani, memasang, lalu mengingat semua tanggal kedaluwarsa. Otomatisasi bukan lagi pilihan, melainkan keharusan. Episode 8 adalah titik balik dari manual menuju otomatis.

ACME (Automatic Certificate Management Environment) adalah jawaban atas masalah itu. Standar ini, yang didokumentasikan di RFC 8555, memungkinkan sebuah klien meminta, menerima, dan memperbarui sertifikat tanpa campur tangan manusia. Kalian akan melihat bagaimana sebuah sertifikat lahir dari order, melewati challenge, divalidasi, lalu diterbitkan dalam hitungan menit.

Roadmap episode ini: pertama kita bedah alur kerja ACME, kedua kita bandingkan tiga tipe challenge, ketiga kita bahas External Account Binding, keempat kita praktikkan Let's Encrypt dengan certbot, dan terakhir kita lihat tren sertifikat berumur pendek plus ACME Profiles.

#ACME Protocol dan RFC 8555

#Mengapa ACME Dibutuhkan

Sebelum ACME, menerbitkan sertifikat berarti menghubungi CA, membuktikan kepemilikan domain lewat email atau upload file, lalu menunggu. Untuk sertifikat yang berlaku setahun, proses manual itu masih bisa ditoleransi. Tapi ketika industri mulai mengecilkan masa berlaku, otomatisasi menjadi satu-satunya cara yang masuk akal.

ACME mengotomatiskan seluruh alur itu: pendaftaran akun, pembuatan order, pembuktian kepemilikan domain, hingga pengunduhan sertifikat. Klien ACME yang berjalan di server bisa meminta sertifikat baru dan memperbarui yang lama tanpa interaksi manusia.

#Alur Kerja ACME

Alur ACME bisa disederhanakan menjadi beberapa tahap yang saling berurutan. Pemahaman atas tahapan ini penting karena semua masalah nyata di lapangan — sertifikat tidak keluar, validasi gagal — selalu bisa ditelusuri ke salah satu tahap ini.

1. Akun: klien membuat akun di server ACME dengan pasangan kunci sendiri.
2. Order: klien mengirim permintaan order berisi daftar identifier, misalnya nama domain.
3. Challenge: server ACME menjawab dengan daftar challenge yang harus diselesaikan klien untuk membuktikan kepemilikan domain.
4. Validasi: klien menyiapkan bukti sesuai tipe challenge, lalu server memverifikasi bukti tersebut.
5. Issue: setelah semua challenge valid, server menerbitkan sertifikat dan klien mengunduhnya.

Perhatikan posisi kunci pada tahap Akun. Kunci akun ini penting: sertifikat yang diterbitkan nanti ditandatangani dengan kunci yang terikat pada akun, sehingga pembaruan otomatis hanya bisa dilakukan oleh pemilik akun yang sama.

#Tipe Challenge

ACME mendefinisikan beberapa cara membuktikan kepemilikan domain. Masing-masing punya kekuatan dan keterbatasan sendiri. Memilih tipe yang tepat sering kali adalah keputusan arsitektur, bukan sekadar teknis.

HTTP-01 adalah yang paling sederhana. Klien meletakkan token di URL /.well-known/acme-challenge/ di port 80, dan server ACME mengunjungi URL tersebut untuk memverifikasi. Validasi ini hanya membuktikan kontrol atas port 80, bukan atas seluruh server.

curl -s http://example.com/.well-known/acme-challenge/abc123token

DNS-01 bekerja lewat DNS record. Klien membuat record TXT bernama _acme-challenge.example.com berisi token, dan server ACME membaca record tersebut. Karena verifikasi dilakukan lewat DNS, tipe ini mendukung wildcard certificate yang tidak bisa dilayani HTTP-01.

dig TXT _acme-challenge.example.com +short

TLS-ALPN-01 memakai port 443 dengan protokol ALPN khusus bernama acme-tls/1. Server ACME melakukan handshake TLS dan memeriksa token di dalam sertifikat sementara. Tipe ini berguna ketika port 80 diblokir dan klien memakai SNI.

openssl s_client -connect example.com:443 -alpn acme-tls/1

Ketiga tipe di atas sama-sama sah, tapi penggunaannya bergantung pada lingkungan. HTTP-01 paling mudah dimulai, DNS-01 wajib untuk wildcard dan paling fleksibel, sedangkan TLS-ALPN-01 cocok untuk situasi khusus dengan port terbatas.

#External Account Binding

Secara default, akun ACME tidak terikat ke akun eksternal apa pun — siapa pun bisa membuat akun dan meminta sertifikat, dibatasi hanya oleh rate limit. External Account Binding (EAB) mengubah itu: akun ACME diikat ke sebuah akun yang sudah terdaftar di CA lewat key identifier dan HMAC key.

EAB umum dipakai oleh CA untuk mencegah penyalahgunaan dan menerapkan kebijakan penerbitan. Saat memakai EAB, klien harus menyertakan kredensial EAB pada setiap request. Certbot mendukungnya lewat opsi --eab-kid dan --eab-hmac-key.

certbot certonly --standalone --preferred-challenges http \
  --eab-kid key-identifier \
  --eab-hmac-key hmac-secret \
  -d example.com

Jangan pernah membagikan HMAC key EAB. Ia adalah rahasia yang setara dengan password akun CA kalian. Simpan di secret manager, bukan di file konfigurasi yang bisa terbaca siapa pun.

#Let's Encrypt dan Certbot

#Mengenal Let's Encrypt

Let's Encrypt adalah Certificate Authority publik yang menerbitkan sertifikat TLS secara gratis dan otomatis lewat ACME. Ia dikelola oleh Internet Security Research Group dan dijalankan tanpa biaya — dibiayai sponsor serta donasi, bukan dari penjualan sertifikat. Root CA-nya sudah tertanam di semua sistem operasi dan peramban modern.

Bagi kalian, Let's Encrypt menarik karena dua alasan: gratis dan sepenuhnya otomatis. Yang membuatnya menonjol adalah kebijakan masa berlaku 90 hari — jauh lebih pendek dari sertifikat komersial yang bisa bertahun-tahun — sebagai cara memaksa ekosistem untuk selalu memperbarui sertifikat sebelum kedaluwarsa.

#Rate Limit

Karena gratis, Let's Encrypt harus melindungi dirinya dari penyalahgunaan. Ia menerapkan rate limit per akun, per domain, dan per jaringan. Misalnya, ada batasan jumlah sertifikat duplikat per minggu, jumlah sertifikat baru per domain per minggu, dan batas kegagalan validasi per jam.

Rate limit bukan sesuatu yang perlu ditakuti selama otomatisasi kalian sehat. Masalah muncul ketika kalian meminta ulang sertifikat yang sama berulang kali secara manual. Ingat aturan praktis: perbarui lewat certbot renew, jangan buat ulang sertifikat dari nol, dan hindari meminta sertifikat untuk pengujian yang tidak terkendali.

#Siklus Hidup 90 Hari

Sertifikat 90 hari bukan untuk menambah pekerjaan, melainkan untuk memperkecil jendela risiko. Sertifikat yang dicabut atau kompromi hanya bertahan maksimal 90 hari. Dan dengan masa berlaku yang pendek, otomatisasi menjadi disiplin: kalian tidak bisa lagi mengandalkan ritual manual tahunan.

Praktiknya, sertifikat diperbarui bukan saat kedaluwarsa, melainkan di tengah masa berlakunya. Certbot memperbarui otomatis sekitar 30 hari sebelum kedaluwarsa, sehingga selalu ada ruang untuk beberapa kali percobaan jika validasi gagal.

#Instalasi dan Penggunaan Certbot

Certbot adalah klien ACME yang paling populer, dikembangkan oleh Electronic Frontier Foundation. Ia punya plugin untuk banyak server web, termasuk Nginx, sehingga bisa mengubah konfigurasi TLS sekaligus menerbitkan sertifikat.

apt install certbot python3-certbot-nginx
certbot --nginx -d example.com -d www.example.com

Perintah certbot --nginx di atas menerbitkan sertifikat untuk dua domain sekaligus dan memasangnya ke konfigurasi Nginx. Certbot juga menulis script renewal yang akan dipakai nanti. Untuk sekadar menerbitkan tanpa mengubah konfigurasi, gunakan mode certonly.

#Auto-Renewal

Otomatisasi di Let's Encrypt tidak berhenti di penerbitan. Certbot dilengkapi timer yang menjalankan certbot renew dua kali sehari, dan perintah itu hanya memperbarui sertifikat yang sudah masuk jendela renewal. Jadi menjalankannya berkali-kali tidak berbahaya — ia idempotent.

certbot renew --quiet

Pastikan timer renewal aktif di sistem kalian. Jika kalian menjalankan certbot di dalam container atau skenario custom, pindahkan logika renewal ke cron atau pipeline kalian sendiri, karena mengabaikan renewal adalah penyebab paling umum sertifikat kedaluwarsa yang tidak terduga.

#Sertifikat Berumur Pendek dan ACME Profiles

Industri terus bergerak ke arah masa berlaku yang lebih pendek. Setelah 90 hari menjadi standar, wacana berikutnya adalah sertifikat 6 hari. Logikanya: jika sertifikat dicuri atau CA dibobol, masa rentannya tinggal hitungan hari, dan kegagalan otomatisasi cepat terlihat. Sebagian besar CA infrastruktur, termasuk step-ca, sudah menerapkan praktik serupa.

Untuk mendukung skenario itu, ACME Profiles sedang dinormalisasi lewat draft IETF. Konsepnya sederhana: server ACME bisa mendefinisikan profil bernama yang memuat seperangkat kebijakan — misalnya masa berlaku, tipe key, atau daftar domain yang diizinkan — dan klien cukup meminta profil dengan nama itu. Ini mempermudah administrasi dan mencegah klien mengirim parameter yang tidak diizinkan.

#Penutup

Episode 8 mengubah cara kalian memandang sertifikat: bukan artefak statis yang diurus setahun sekali, melainkan siklus hidup dinamis yang berjalan otomatis. Kalian menguasai alur ACME dari order hingga issuance, membedakan tiga tipe challenge, memahami EAB, lalu mempraktikkan Let's Encrypt dengan certbot beserta rate limit dan auto-renewal-nya.

Inti yang harus dibawa pulang:

• ACME RFC 8555 mengotomatiskan seluruh siklus order, challenge, validasi, dan penerbitan sertifikat.
• HTTP-01 butuh port 80, DNS-01 untuk wildcard, TLS-ALPN-01 memakai port 443.
• EAB mengikat akun ACME ke akun eksternal untuk mencegah penyalahgunaan dan menegakkan kebijakan CA.
• Let's Encrypt menerbitkan sertifikat gratis dengan masa berlaku 90 hari dan rate limit per domain.
• Auto-renewal dengan certbot renew bersifat idempotent dan hanya menyentuh sertifikat yang mendekati kedaluwarsa.
• Sertifikat berumur pendek dan ACME Profiles mengecilkan masa rentan sekaligus memaksa otomatisasi yang sehat.

Di episode 9, kalian akan melihat sisi modern dari semua ini dari sudut pandang private CA. Kita akan belajar step-ca dari Smallstep, membangun CA sendiri yang berbicara ACME dan banyak protokol lain, lengkap dengan provisioner, issuance berbasis template, hingga SSH certificate authority. Sampai jumpa!