Belajar PKI - step-ca: Private CA Modern

#Pendahuluan

Di episode 8 sebelumnya kalian menguasai ACME dan Let's Encrypt — otomatisasi penerbitan untuk domain publik. Tapi tidak semua sertifikat di dunia adalah sertifikat publik. API internal, workload di Kubernetes, hingga SSH ke server internal tidak selalu ingin bergantung pada CA publik. Untuk itu kita butuh private CA yang modern, dan episode 9 membawanya: step-ca dari Smallstep.

Memang di episode 4 kita sudah membangun private CA dengan OpenSSL secara manual. Itu memberikan pemahaman fondasi yang dalam, tapi di produksi, mengelola CA manual adalah beban. step-ca hadir dengan satu binary yang siap produksi, mendukung banyak protokol, dan dirancang untuk otomatisasi sejak awal. Versi 0.30 yang dirilis tahun 2026 adalah titik fokus kita.

Roadmap episode ini: kita mulai dari init dan bootstrap, lalu menjelajahi provisioner, template-based issuance, SSH certificate authority, perbaikan keamanan di versi 0.30, dan terakhir memakai step CLI untuk kebutuhan sehari-hari.

#Mengenal step-ca 0.30

step-ca adalah Certificate Authority modern yang berjalan sebagai daemon, dirancang untuk lingkungan cloud native. Berbeda dari CA tradisional yang memakai banyak file konfigurasi rumit, step-ca mengelola root CA, intermediate CA, dan config-nya dalam satu direktori yang rapi. Ia lahir dari pengalaman Smallstep membangun tooling untuk TLS dan SSH di skala besar.

Versi 0.30 adalah rilis terbaru yang membawa perbaikan keamanan penting dan penyempurnaan protokol. Bagi kalian yang baru mulai, rilis ini adalah titik masuk yang ideal karena merupakan fondasi yang stabil untuk semua seri berikutnya, termasuk integrasi dengan cert-manager di episode 10.

#Init dan Bootstrap

Langkah pertama adalah membuat CA: step ca init membangun root CA dan intermediate CA sekaligus, lengkap dengan provisioner pertama dan password untuk melindungi kunci. Prosesnya interaktif, tapi semua parameter bisa diberikan lewat opsi agar bisa diotomatiskan.

step ca init --name "Internal CA" \
  --dns ca.internal --address ":443" \
  --provisioner admin@internal

Perintah di atas membuat root CA dan intermediate CA dengan nama Internal CA, menjadikan ca.internal sebagai alamat publik CA, dan membuat provisioner admin pertama. Saat selesai, kalian akan mendapat direktori berisi root, intermediate, dan config, plus password yang wajib disimpan aman.

Langkah berikutnya adalah bootstrap dari sisi klien. step ca bootstrap mengambil root certificate dari CA dan menaruhnya di lokasi yang dipakai step CLI serta trust store lokal.

step ca bootstrap --ca-url https://ca.internal \
  --fingerprint root-fingerprint-here

--fingerprint adalah sidik jari root certificate yang memastikan kalian berkomunikasi dengan CA yang benar — semacam out-of-band verification. Setelah bootstrap, semua perintah step CLI akan berbicara dengan CA ini secara langsung.

#Provisioner

Konsep kunci di step-ca adalah provisioner: mekanisme untuk mengautentikasi siapa yang boleh meminta sertifikat, dan dengan kebijakan apa. Bayangkan provisioner sebagai gerbang masuk — tanpa provisioner yang valid, tidak ada sertifikat yang diterbitkan. step-ca mendukung beberapa tipe.

• JWK: provisioner bawaan berbasis JSON Web Key, cocok untuk admin dan mesin.
• OIDC: memakai identity provider seperti Keycloak atau Entra, bagus untuk alur SSO.
• ACME: memungkinkan klien ACME seperti certbot meminta sertifikat dari step-ca.
• X5C: autentikasi berbasis sertifikat klien yang sudah ada.
• SCEP: protokol klasik untuk pendaftaran perangkat, banyak dipakai di MDM.

step ca provisioner add acme --type ACME
step ca provisioner add oidc --type OIDC \
  --client-id client-id --client-secret client-secret \
  --issuer-url https://idp.internal

Perintah step ca provisioner add di atas menambahkan provisioner ACME untuk integrasi klien standar, dan provisioner OIDC yang meneruskan autentikasi ke identity provider. Setiap provisioner bisa diberi kebijakan pembatasan sendiri, misalnya daftar email atau domain yang diizinkan.

#Issuance Berbasis Template

step-ca memakai pendekatan template untuk menerbitkan sertifikat. Alih-alih menuliskan seluruh detail di sisi klien, admin mendefinisikan template sertifikat yang akan dirender berdasarkan data dari provisioner. Ini mirip konsep ACME Profiles yang kita bahas di episode 8, tapi lebih fleksibel.

Keuntungannya besar: kebijakan sertifikat — SAN, masa berlaku, Extended Key Usage — dikendalikan oleh admin, bukan oleh pemohon. Klien cukup menyebut identitas yang diinginkan, dan step-ca yang menentukan bentuk akhirnya. Kalian bisa membuat profil khusus untuk server, klien, atau bahkan untuk kasus yang sangat spesifik.

#SSH Certificate Authority

Keistimewaan step-ca yang sering diremehkan: ia bisa menjadi SSH Certificate Authority. Daripada menebar public key ke seluruh server, kalian bisa menerbitkan sertifikat SSH berumur pendek yang otomatis valid di semua mesin yang mempercayai step-ca. Ini menghapus masalah distribusi key dan rotasi.

step ssh certificate dev@internal ssh-user.crt \
  ssh-user.key --principal dev --ttl 8h

Perintah di atas menerbitkan sertifikat SSH untuk pengguna dev dengan masa berlaku 8 jam. Setelah kedaluwarsa, pengguna otomatis kehilangan akses — tanpa perlu mencabut apa pun. Host SSH di lingkungan kalian cukup mengonfigurasi TrustedUserCAKeys untuk mempercayai CA dari step-ca.

#Perbaikan Keamanan di 0.30

Setiap rilis step-ca membawa perbaikan keamanan, dan 0.30 tidak terkecuali. Yang paling penting adalah CVE-2026-30836, kelemahan pada SCEP UpdateReq yang memungkinkan penerbitan sertifikat tanpa autentikasi yang sah. Karena SCEP banyak dipakai untuk pendaftaran perangkat, kelemahan ini berpotensi dimanfaatkan untuk mendapatkan sertifikat yang tidak seharusnya.

Perbaikan di 0.30 menutup celah tersebut sehingga request pembaruan SCEP divalidasi dengan benar. Bagi kalian yang sudah menjalankan step-ca versi sebelumnya, upgrade ke 0.30 adalah prioritas, bukan pilihan. Jika step-ca kalian pernah terekspos publik, periksa juga apakah ada sertifikat mencurigakan yang diterbitkan.

#step CLI 0.30.x

#Membuat, Memeriksa, dan Memverifikasi Sertifikat

step CLI adalah pendamping wajib step-ca. Dengan satu binary, kalian bisa membuat sertifikat, memeriksa detailnya, memverifikasi validitas, dan memperbarui yang kedaluwarsa. Untuk pembuatan cepat tanpa CA, ada step certificate create.

step certificate create internal/web01 web01.crt \
  web01.key --profile leaf \
  --san web01.internal --san 10.0.5.12

Perintah di atas membuat leaf certificate dengan dua SAN sekaligus, satu nama DNS dan satu IP. Profil leaf memastikan sertifikat yang dihasilkan memang untuk entitas akhir, bukan CA. Untuk memeriksa isi sertifikat dan memverifikasi validitasnya:

step certificate inspect web01.crt
step certificate verify web01.crt \
  --roots /etc/ssl/certs/root-ca.crt

step certificate inspect menampilkan seluruh detail sertifikat dalam bentuk yang mudah dibaca, sedangkan verify memastikan rantai valid terhadap root yang diberikan. Kombinasi keduanya adalah pemeriksaan cepat yang andal sebelum memasang sertifikat.

#Memperbarui Sertifikat

Untuk sertifikat yang diterbitkan oleh step-ca, pembaruan dilakukan lewat step ca renew. Perintah ini memakai kredensial renewal dari sertifikat yang masih valid untuk mendapatkan versi baru tanpa proses autentikasi ulang yang panjang.

step ca renew web01.crt web01.key --force

Jadwalkan renewal sebelum masa berlaku habis, bukan saat kedaluwarsa. step-ca bisa dikonfigurasi menerbitkan sertifikat dengan masa berlaku pendek — 24 jam bahkan kurang — selama renewal berjalan otomatis. Ini selaras dengan tren sertifikat berumur pendek dari episode 8.

#Integrasi dengan Klien ACME

Salah satu alasan step-ca mudah diadopsi adalah ia berbicara ACME. Setelah menambahkan provisioner tipe ACME, klien standar seperti certbot bisa langsung meminta sertifikat dari step-ca, lengkap dengan mekanisme validasi yang sudah kita pelajari. Ini menjadikan step-ca semacam Let's Encrypt privat untuk lingkungan kalian.

certbot certonly --standalone \
  --server https://ca.internal/acme/acme/directory \
  -d web01.internal

Cukup arahkan --server ke endpoint ACME step-ca, dan certbot mengurus sisanya. Dengan cara ini, semua keahlian ACME dari episode 8 bisa dipakai ulang di atas private CA — fondasi yang akan kita manfaatkan lagi di episode 10.

#Penutup

Episode 9 memperkenalkan private CA modern yang layak produksi. Kalian belajar inisialisasi dan bootstrap step-ca, memahami peran provisioner sebagai gerbang autentikasi, memanfaatkan template untuk mengontrol bentuk sertifikat, sampai menjadikan step-ca sebagai SSH Certificate Authority. Perbaikan keamanan CVE-2026-30836 juga menegaskan pentingnya menjaga CA tetap terbaru.

Inti yang harus dibawa pulang:

• step-ca adalah private CA modern dengan satu binary yang dirancang untuk otomatisasi.
• step ca init dan step ca bootstrap adalah gerbang awal membangun dan memakai CA.
• Provisioner menentukan siapa yang boleh minta sertifikat: JWK, OIDC, ACME, X5C, dan SCEP.
• Template-based issuance memaksa profil sertifikat yang seragam dan dikendalikan admin.
• step-ca bisa menjadi SSH Certificate Authority dengan sertifikat berumur pendek tanpa distribusi key manual.
• CVE-2026-30836 memperbaiki kelemahan SCEP UpdateReq; upgrade ke 0.30 wajib bagi pengguna SCEP.
• CLI step mencakup create, inspect, verify, renew, dan integrasi dengan klien ACME.

Di episode 10, kalian akan melihat step-ca digunakan pada skala yang lebih besar. Kita akan belajar cert-manager, otomatisasi sertifikat di Kubernetes: resource Issuer dan Certificate, instalasi via Helm, integrasi step-ca sebagai ExternalIssuer, hingga trust-manager untuk mengelola bundle CA. Sampai jumpa!