Belajar PKI - High Availability & Multi-CA

#Pendahuluan

Episode 17 mengupas format X.509 lanjutan: extension, SAN, hingga perbedaan encoding DER dan PEM. Kalian kini paham bahwa sertifikat hanyalah dokumen — kekuatannya datang dari siapa yang menandatanganinya dan bagaimana infrastruktur di sekitarnya menjaga rantai kepercayaan. Di titik inilah banyak tim menghadapi dinding berikutnya: bagaimana cara menskalakan CA yang awalnya dibangun untuk satu server agar melayani seluruh organisasi tanpa menjadi titik tunggal kegagalan.

Episode 18 menjawab pertanyaan itu. Kita akan membangun high availability dan multi-CA: memisahkan intermediate CA per environment, cross-signing untuk menjaga kompatibilitas saat migrasi root, root rotation yang dilakukan dengan risiko rendah, strategi HA untuk step-ca dan cert-manager, lalu menutupnya dengan skenario recovery. Di akhir episode, kalian akan punya peta jalan menaikkan PKI dari skala homelab ke skala produksi.

#Mengapa Satu CA Tidak Cukup

Satu CA terasa simpel: satu root, satu intermediate, satu kunci untuk mengatur semuanya. Tapi di lingkungan nyata, kesederhanaan itu berubah menjadi risiko. Satu CA yang dipakai bersama untuk development, staging, dan production berarti satu kesalahan konfigurasi di environment uji bisa meracuni rantai kepercayaan environment production. Satu CA juga berarti tidak ada pemisahan tugas: admin yang bisa menerbitkan sertifikat development otomatis juga bisa menerbitkan sertifikat production.

Prinsip dari episode 16 kembali relevan di sini: pemisahan kewenangan. Semakin kecil ruang lingkup sebuah CA, semakin mudah mengamankannya, mengauditnya, dan membatasinya saat terjadi insiden. Multi-CA bukan tentang menambah kompleksitas tanpa alasan — ia adalah cara struktural untuk menjaga agar satu kegagalan tidak menjatuhkan semuanya.

#Multiple Intermediate CA per Environment

Model yang umum dipakai banyak organisasi adalah satu root CA offline untuk seluruh perusahaan, lalu satu set intermediate CA untuk setiap environment. Root bertindak sebagai sumber kepercayaan tertinggi yang jarang diakses, sementara setiap intermediate menerbitkan sertifikat di lingkungannya masing-masing.

root-ca:
  type: offline
  lifetime: 20y
  intermediates:
    - name: intermediate-dev
      profile: short-lived
    - name: intermediate-staging
      profile: standard
    - name: intermediate-prod
      profile: production

Struktur ini memberi beberapa keuntungan sekaligus. Pertama, revocation menjadi lebih terarah: jika intermediate dev bocor, kita mencabut sertifikat hanya untuk rantai dev tanpa menyentuh production. Kedua, kebijakan bisa berbeda per environment — masa berlaku sertifikat dev pendek, production lebih panjang. Ketiga, kompromi di satu environment tidak menyeret environment lain ke dalam rantai kepercayaan yang sama.

openssl x509 -req -in intermediate-dev.csr \
  -CA root-ca.crt -CAkey root-ca.key \
  -CAcreateserial -out intermediate-dev.crt \
  -days 730 -extfile intermediate-dev.ext

Proses ini dilakukan di mesin offline tempat root berada, lalu hasilnya dibawa keluar untuk didistribusikan. Kunci private intermediate juga harus diisolasi: simpan di HSM atau KMS seperti yang kita bahas di episode 13, dan batasi akses hanya untuk admin yang bertugas di environment tersebut.

#Cross-signing Antar Root

Cross-signing adalah teknik yang membuat dua root CA saling mempercayai secara tidak langsung: root lama menandatangani sertifikat dari root baru, dan sebaliknya. Hasilnya, client yang mempercayai root lama juga menerima sertifikat dari rantai root baru, tanpa perlu mengganti trust store mereka lebih dulu.

openssl x509 -req -in new-root.csr \
  -CA old-root.crt -CAkey old-root.key \
  -CAcreateserial -out new-root.cross.crt \
  -extfile new-root.ext

Kapan cross-signing dibutuhkan? Kasus paling umum adalah migrasi root: ribuan device di lapangan masih memercayai root lama dan tidak bisa di-update sekaligus. Dengan cross-signing, client lama tetap bisa memvalidasi sertifikat yang diterbitkan di bawah root baru selama masa transisi. Cek hasil rantai dengan openssl verify -verbose -CAfile old-root.pem new-chain.pem untuk memastikan jalur validasi benar sebelum disebar luas.

#Root Rotation

Root rotation adalah proses mengganti root CA dengan yang baru — biasanya karena kunci lama hampir habis masa berlakunya, standar kriptografi berubah, atau ada dugaan kompromi. Ini adalah salah satu operasi paling berisiko di dunia PKI karena seluruh trust store client harus diperbarui.

Langkah aman untuk root rotation: pertama, terbitkan root baru dengan algoritma dan ukuran kunci terkini. Kedua, cross-sign root lama dengan root baru agar masa transisi tidak memutus layanan. Ketiga, sebarkan root baru ke semua trust store internal secara bertahap, sambil menambahkan root lama ke list revoked agar tidak ada yang bisa menyalahgunakannya. Terakhir, saat trafik lama sudah nol, nonaktifkan root lama dan bersihkan dari semua sistem.

#step-ca Distributed dan High Availability

step-ca dari episode 9 memang punya state, tapi ia tetap bisa dijalankan secara distributed. Kuncinya ada di pemilihan backend dan penyimpanan kunci. Untuk setup multi-instance, taruh step-ca di belakang load balancer dengan dua atau lebih instance, bagikan data store antar instance, dan simpan kunci CA di HSM melalui PKCS#11 sehingga kunci tidak pernah meninggalkan perangkat keras.

step ca init --name "Production Root" --dns ca.example.com --address ":8443" \
  --provisioner admin --with-ca-url https://ca.example.com
step-ca ./config/ca.json --badger-dir ./data/ca \
  --kms-uri pkcs11:module-path=/usr/lib/softhsm/libsofthsm2.so

Saat salah satu instance mati, instance lain tetap melayani permintaan selama data store bersama masih bisa diakses. Health check rutin membantu kita tahu kapan instance perlu diganti — biasakan mengecek dengan step ca health secara berkala dan ikutkan ke dalam monitoring, yang akan kita bangun di episode 19.

#cert-manager High Availability

cert-manager dari episode 10 juga punya mode high availability. Deployment default dengan satu replica cukup untuk lab, tapi untuk produksi kita menaikkan jumlah replica dan mengaktifkan leader election. Dengan leader election, hanya satu controller yang memproses sertifikat pada satu waktu, sementara pod lain siap mengambil alih saat leader mati.

replicas: 3
leaderElection:
  enabled: true
  namespace: cert-manager
extraArgs:
  - --max-concurrent-changes=30

Controller yang aktif menulis status ke Certificate object; pod lain hanya menonton. Jika leader gagal, follower melakukan failover dalam hitungan detik tanpa intervensi manual. Pantau peristiwa di namespace dengan kubectl get events -n cert-manager untuk melihat pergantian leader dan error yang muncul sebelum menjadi masalah besar.

#Recovery Scenarios

HA bukan tentang menghindari kegagalan sepenuhnya — itu mustahil. HA adalah tentang tahu apa yang terjadi saat komponen gagal. Mari kita bahas tiga skenario umum yang wajib kalian latih.

#Lost Intermediate CA

Jika kunci intermediate CA hilang, dampaknya tidak separah root hilang, tapi tetap signifikan. Sertifikat lama tetap valid sampai masa berlakunya habis karena client hanya butuh sertifikat dan rantai, bukan kunci. Yang hilang adalah kemampuan menerbitkan sertifikat baru. Solusinya: terbitkan intermediate baru dari root, distribusikan rantai baru, dan perbarui CA bundle di semua client. Semua sertifikat lama tetap bisa divalidasi sampai kedaluwarsa.

#Root CA Compromised

Root compromised adalah skenario terburuk. Langkah pertama: segera revoke semua sertifikat di rantai itu melalui CRL dan OCSP. Kedua, buat root baru dan jalankan proses rotation yang sudah kita bahas. Ketiga, publikasikan komunikasi insiden dan timeline transisi. Dokumentasikan semua langkah sebagai playbook sebelum insiden terjadi — saat panik, otak tidak bisa diajak berunding.

#Split Brain dan Partial Outage

Ketika setengah instance step-ca atau cert-manager mati, sistem yang sehat harus tetap melayani. Di sisi step-ca, instance yang tersisa melanjutkan penerbitan selama data store bersama masih bisa diakses. Di sisi cert-manager, leader election memastikan hanya satu controller yang bertindak; jika leader mati, follower mengambil alih secara otomatis. Latih skenario ini secara sengaja agar tim tidak kaget saat benar-benar terjadi.

kubectl scale deploy cert-manager --replicas=0
kubectl scale deploy cert-manager --replicas=3
kubectl get certificate --all-namespaces

#Penutup

Episode 18 membawa PKI kalian dari satu server ke arsitektur siap produksi: pemisahan intermediate CA per environment, cross-signing untuk transisi yang mulus, root rotation yang terukur, high availability untuk step-ca dan cert-manager, serta playbook recovery untuk skenario terburuk.

Inti yang harus dibawa pulang:

• Pisahkan intermediate CA per environment agar satu insiden tidak menyeret seluruh organisasi.
• Gunakan cross-signing saat migrasi root agar client lama tetap bisa memvalidasi rantai baru.
• Rancang root rotation bertahap: terbitkan, cross-sign, sebarkan, lalu pensiunkan root lama.
• step-ca bisa berjalan distributed dengan data store bersama; simpan kunci di HSM atau KMS.
• cert-manager HA memakai replicas dan leader election untuk failover otomatis.
• Latih skenario recovery secara berkala dan simpan semuanya sebagai playbook tertulis.

HA tanpa observasi adalah perjalanan buta. Di episode 19 kita pasang matanya: monitoring, observability, dan automation pipeline agar setiap sertifikat dan setiap CA selalu terpantau. Sampai jumpa di sana!