Belajar PKI - CFSSL: Cloudflare PKI Toolkit

#Pendahuluan

Di episode 10 kalian mengotomatiskan sertifikat di Kubernetes lewat cert-manager dan merasakan kekuatan ekosistem step-ca. Namun sebelum era tersebut, ada satu toolkit yang pernah sangat populer untuk membangun PKI internal: CFSSL dari Cloudflare. Banyak organisasi membangun CA internal mereka di atasnya pada masanya, dan banyak sertifikat masih dikelola lewat alat ini sampai sekarang.

CFSSL bukan satu program besar, melainkan kumpulan utilitas untuk X.509. Ia bisa membuat kunci, menandatangani CSR, memeriksa isi sertifikat, memindai keamanan endpoint TLS, bahkan menjalankan online CA yang melayani penerbitan lewat HTTP API. Semua itu dibungkus dalam satu binary statis berbahasa Go.

Roadmap episode ini: kita kenali sejarah dan status CFSSL, pasang alatnya, jelajahi subperintah gencert, genkey, certinfo, dan scan, pahami ca-config.json dengan profiles-nya, jalankan online CA dengan cfssl serve, lalu tutup dengan studi kasus PKI service internal dan catatan jujur kapan harus beralih ke step-ca.

#Mengenal CFSSL dan Statusnya Hari Ini

CFSSL dikembangkan oleh Cloudflare dan menjadi salah satu toolkit PKI paling populer sebelum munculnya step-ca. Keunggulannya saat itu jelas: satu binary, mudah didistribusikan, mendukung pembuatan CA, penandatanganan sertifikat, dan layanan API dalam satu paket. Ia juga menjadi dasar dari layanan Keyless SSL milik Cloudflare.

Sayangnya proyek ini kini berada dalam mode maintenance. Perbaikan bug masih dilakukan, tetapi fitur baru jarang ditambahkan. CFSSL tidak memiliki pembaruan otomatis, protokol ACME, atau dukungan SSH seperti yang kalian kenal di episode 9. Untuk proyek baru, step-ca adalah pilihan yang lebih sehat; CFSSL tetap relevan untuk sistem lama yang sudah berjalan.

#Pasang CFSSL dan Kenali Subperintah Inti

Pemasangan paling mudah lewat go install. Kalian butuh dua binary: cfssl sebagai alat utama dan cfssljson untuk mengubah output JSON menjadi file PEM.

install.sh

go install github.com/cloudflare/cfssl/cmd/cfssl@latest
go install github.com/cloudflare/cfssl/cmd/cfssljson@latest

#gencert dan genkey

Dua subperintah yang paling sering dipakai adalah genkey dan gencert. genkey hanya membuat pasangan kunci beserta CSR tanpa menandatangani. gencert melakukan semuanya sekaligus: membuat kunci, membuat CSR, lalu menandatanganinya dengan CA yang kalian tunjukkan.

#certinfo dan scan

certinfo menampilkan isi sertifikat dari file PEM secara terperinci: subjek, masa berlaku, penggunaan kunci, dan rantai. scan memeriksa endpoint TLS dari jarak jauh: protokol yang didukung, cipher yang lemah, hingga kerentanan kelas tertentu. Keduanya berguna untuk audit cepat.

cfssl certinfo -cert web01.pem

Perintah cfssl certinfo bekerja offline pada file lokal, sedangkan cfssl scan membutuhkan host yang bisa dijangkau. Kombinasi keduanya memberi gambaran cepat tentang kondisi sertifikat di lapangan.

#CSR dalam Bentuk JSON

Berbeda dengan OpenSSL yang memakai file konfigurasi, CFSSL mendeskripsikan CSR dalam JSON. Elemen utama adalah CN, daftar hosts, algoritma kunci, dan informasi pemilik.

csr.json

{
  "CN": "web01.internal",
  "hosts": [
    "web01.internal",
    "api.internal",
    "10.0.0.10"
  ],
  "key": {
    "algo": "ecdsa",
    "size": 256
  },
  "names": [
    {
      "C": "ID",
      "L": "Jakarta",
      "O": "DevNull Labs"
    }
  ]
}

Hosts diisi dengan nama DNS dan alamat IP yang ingin dicantumkan sebagai SAN. Jika kalian lupa menulis hosts, sertifikat yang dihasilkan tidak akan cocok untuk nama yang dipanggil klien — pelajaran yang sama seperti episode 4.

#ca-config.json dan Profiles

Kebijakan penandatanganan dipegang oleh ca-config.json. File ini berisi pengaturan default dan daftar profiles yang bisa dipilih saat gencert. Setiap profile mendefinisikan usages dan expiry.

ca-config.json

{
  "signing": {
    "default": {
      "expiry": "8760h"
    },
    "profiles": {
      "server": {
        "usages": ["signing", "key encipherment", "server auth"],
        "expiry": "8760h"
      },
      "client": {
        "usages": ["signing", "key encipherment", "client auth"],
        "expiry": "8760h"
      },
      "peer": {
        "usages": ["signing", "key encipherment", "server auth", "client auth"],
        "expiry": "8760h"
      }
    }
  }
}

Profile server untuk sertifikat service, client untuk sertifikat pengguna atau aplikasi yang melakukan koneksi keluar, dan peer untuk koneksi dua arah seperti mTLS antar node. Dengan profile, kebijakan tersentralisasi di sisi CA, bukan di tangan pemohon.

#Menandatangani dengan cfssljson

Proses penandatanganan menggabungkan ca-config.json, CSR, dan kunci CA. Output gencert berupa JSON, jadi harus diteruskan ke cfssljson agar menjadi file PEM yang rapi.

sign-server.sh

cfssl gencert \
  -ca ca.pem \
  -ca-key ca-key.pem \
  -config ca-config.json \
  -profile server \
  csr.json | cfssljson -bare web01

cfssljson -bare web01 menghasilkan tiga file: web01.pem berisi sertifikat, web01-key.pem berisi kunci privat, dan web01.csr berisi permintaan asli. Perhatikan bahwa kunci privat CA harus dijaga sangat ketat — pembahasan lengkapnya menunggu episode 13.

#Online CA dengan cfssl serve

Untuk skala yang lebih besar, CFSSL bisa berjalan sebagai online CA. Mode ini membuka HTTP API yang melayani penandatanganan lewat jaringan, sehingga aplikasi bisa meminta sertifikat tanpa akses langsung ke kunci CA.

serve.sh

cfssl serve \
  -address 0.0.0.0 \
  -port 8888 \
  -ca ca.pem \
  -ca-key ca-key.pem \
  -config ca-config.json

Endpoint utama berada di jalur /api/v1/cfssl/sign untuk menandatangani CSR, /api/v1/cfssl/newcert untuk meminta sertifikat baru, dan /api/v1/cfssl/info untuk memeriksa info CA. Permintaan dikirim lewat curl dalam bentuk JSON.

call-api.sh

curl -X POST https://ca.internal:8888/api/v1/cfssl/sign \
  -d @sign-request.json

Ingat: API ini tidak memiliki mekanisme otentikasi bawaan yang kuat. Akses harus dibatasi jaringan dan ditempatkan di balik proxy yang menerapkan otorisasi. Semakin mudah sebuah API meminta tanda tangan, semakin besar risiko penyalahgunaan jika ia terbuka.

#Studi Kasus: PKI untuk Service Internal

Anggaplah kalian punya sepuluh microservice yang saling bicara lewat mTLS. Pola paling sederhana: siapkan ca-config.json dengan profile server dan client, jalankan cfssl serve di mesin yang dijaga, lalu setiap service meminta sertifikat sesuai profile-nya saat bootstrap.

Kelemahannya mulai terasa di operasional: tidak ada auto-renewal, tidak ada pemantauan kedaluwarsa otomatis, dan daftar sertifikat aktif harus dikelola manual. Untuk skala kecil dan lingkungan yang tenang, pola ini masih bisa berjalan. Untuk lingkungan yang dinamis, kalian akan lebih nyaman dengan step-ca dan cert-manager.

#Kapan Berpindah ke step-ca

step-ca unggul di hampir semua aspek yang modern: pembaruan otomatis, protokol ACME, dukungan SSH, provisioner berbasis OIDC, dan ekosistem step yang terus aktif. CFSSL layak dipertahankan hanya jika infrastruktur kalian sudah berjalan lama di atasnya dan biaya migrasi tidak sebanding manfaatnya.

Jika kalian memulai proyek baru hari ini, pilihan jelas jatuh ke step-ca. CFSSL tetap menarik untuk dipelajari karena banyak sistem warisan masih memakainya, dan memahami keduanya membuat kalian paham arah evolusi tooling PKI.

#Penutup

Episode 11 memperkenalkan CFSSL sebagai toolkit PKI yang pernah mendominasi. Kalian memasang cfssl dan cfssljson, memakai gencert, genkey, certinfo, dan scan, mengatur kebijakan lewat ca-config.json, menandatangani dengan cfssljson, menjalankan online CA dengan cfssl serve, serta menimbang kapan ia masih layak dibandingkan step-ca.

Inti yang harus dibawa pulang:

CFSSL adalah kumpulan utilitas X.509 dalam satu binary, bukan satu perintah tunggal.
genkey hanya membuat kunci dan CSR, sedangkan gencert langsung menandatangani.
ca-config.json memusatkan kebijakan penandatanganan melalui profiles server, client, dan peer.
cfssljson mengubah output JSON menjadi file PEM yang siap dipasang.
cfssl serve membuka online CA lewat HTTP API, tetapi otentikasinya harus dijaga eksternal.
CFSSL berada dalam mode maintenance; untuk proyek baru, step-ca adalah pilihan yang lebih tepat.

Di episode 12 kita menggeser fokus ke HashiCorp Vault. Kalian akan belajar PKI engine Vault: mount engine, penerbitan berbasis role, pengaturan masa berlaku, manajemen OCSP dan CRL, hingga integrasi dengan step-ca dan aplikasi lewat consul-template dan Vault Agent. Sampai jumpa!