Belajar Vault - PKI Secrets Engine (Automated X.509 Certificate Authority)

#Pendahuluan

Setelah di episode 6 sebelumnya kita membahas Transit Secrets Engine untuk mengamankan data at rest, pada episode kali ini kita akan mengamankan lapisan berikutnya: komunikasi antar service. Masalahnya sederhana namun nyata: hampir semua aplikasi modern memakai TLS/SSL, tapi siapa yang mengurus sertifikatnya? Jawaban klasiknya adalah "kadang-kadang", "saat teringat", atau "ketika sudah error di browser".

Kenapa topik ini penting di dunia nyata? Sertifikat TLS internal yang kadaluarsa adalah salah satu insiden paling umum dan paling memalukan di perusahaan. Sertifikat untuk api.internal.local atau koneksi antar microservice sering dibuat manual dengan OpenSSL, dipasang sekali, lalu dilupakan — sampai tiba-tiba staging environment error "certificate expired" di tengah malam. Belum lagi praktik buruk memakai sertifikat yang sama di banyak server, atau self-signed certificate yang membuat tim lain tidak percaya.

PKI Secrets Engine menyelesaikan masalah ini dengan cara yang sangat Vault: sertifikat menjadi short-lived (misal TTL 24 jam), diterbitkan otomatis lewat API, dan rotasi menjadi bagian dari siklus hidup normal — bukan acara tahunan yang dikerjakan manual. Mari kita bedah bagaimana Vault menjadi Certificate Authority (CA) yang sesungguhnya.

#Pembahasan Utama

#Konsep Vault sebagai Certificate Authority

PKI Secrets Engine memungkinkan Vault bertindak sebagai Certificate Authority: membuat key dan sertifikat X.509, menerbitkan sertifikat on-demand, dan mengelola pencabutannya.

Arsitektur yang direkomendasikan di produksi menggunakan dua tingkat CA:

Kenapa dua tingkat? Prinsip compartmentalization. Jika hanya ada satu Root CA dan kuncinya bocor, seluruh infrastruktur harus dibangun ulang. Dengan intermediate CA, jika kunci intermediate bocor, kita cukup mencabutnya (revoke) dan membuat intermediate baru — Root CA yang aman tidak terusik. Ini persis seperti struktur PKI di dunia nyata (misalnya Let's Encrypt memakai Root + Intermediate).

#Langkah 1: Menyiapkan Root CA

Pertama, kita mount PKI secrets engine untuk Root CA:

vault secrets enable -path=pki pki

Output:

Success! Enabled the pki secrets engine at: pki/

Batasi TTL maksimum untuk Root CA — 10 tahun:

vault secrets tune -max-lease-ttl=87600h pki

Generate self-signed Root CA:

vault write pki/root/generate/internal \
    common_name="devvnull.local Root CA" \
    ttl=87600h

Output:

Key             Value
---             -----
certificate     -----BEGIN CERTIFICATE-----
MIIFxzCCA6+gAwIBAgIUDhH... (certificate PEM di sini)
-----END CERTIFICATE-----
expiration      2036-08-02T09:15:00.000Z
issuing_ca      -----BEGIN CERTIFICATE-----
MIIFxzCCA6+gAwIBAgIUDhH... (sama dengan certificate untuk root self-signed)
-----END CERTIFICATE-----
serial_number   4a:7c:...

Konfigurasi URL untuk CRL (Certificate Revocation List) dan OCSP:

vault write pki/config/urls \
    issuing_certificates="http://vault.local:8200/v1/pki/ca" \
    crl_distribution_points="http://vault.local:8200/v1/pki/crl"

#Langkah 2: Menyiapkan Intermediate CA (melalui CSR)

Sekarang mount PKI kedua untuk intermediate CA:

vault secrets enable -path=pki_int pki

vault secrets tune -max-lease-ttl=43800h pki_int

Generate Certificate Signing Request (CSR) di mount intermediate:

vault write -format=json pki_int/intermediate/generate/internal \
    common_name="devvnull.local Intermediate CA" \
    ttl=43800h

Output (CSR dalam format JSON, karena panjangnya besar):

{
  "data": {
    "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIICzzCCAbc...\n-----END CERTIFICATE REQUEST-----",
    "key_id": "b0a2c46d...",
    "private_key_type": "rsa"
  }
}

CSR ini adalah "permintaan" dari intermediate ke Root. Untuk menandatanganinya, simpan CSR ke file lalu tanda tangani dengan Root CA mount:

vault write pki/root/sign-intermediate \
    csr=@/tmp/intermediate.csr \
    format=pem_bundle \
    ttl=43800h

Output:

Key                 Value
---                 -----
certificate         -----BEGIN CERTIFICATE----- (sertifikat intermediate yang ditandatangani Root)
...
ca_chain            -----BEGIN CERTIFICATE----- (chain Root + Intermediate)
...
expiration          2034-08-02T09:20:00.000Z
issuing_ca          -----BEGIN CERTIFICATE----- (Root CA)

Terakhir, set certificate yang sudah ditandatangani sebagai intermediate CA di mount pki_int:

vault write pki_int/intermediate/set-signed certificate=@/tmp/intermediate.crt

Output:

Success! Data written to: pki_int/intermediate/set-signed

#Langkah 3: Membuat Role Penerbitan Sertifikat

Sebelum bisa menerbitkan sertifikat, kita harus mendefinisikan role — aturan tentang sertifikat seperti apa yang boleh diterbitkan (domain apa, TTL berapa):

vault write pki_int/roles/my-role \
    allowed_domains="internal.local" \
    allow_subdomains=true \
    max_ttl="720h" \
    default_ttl="24h" \
    key_type="rsa" \
    key_bits="2048"

Output:

Success! Data written to: pki_int/roles/my-role

#Langkah 4: Menerbitkan Sertifikat On-Demand

Inilah momen inti episode ini — menerbitkan sertifikat lewat satu perintah:

vault write pki_int/issue/my-role common_name="api.internal.local" ttl="24h"

Output:

Key                 Value
---                 -----
certificate         -----BEGIN CERTIFICATE-----
MIIE... (certificate PEM untuk api.internal.local)
-----END CERTIFICATE-----
ca_chain            [-----BEGIN CERTIFICATE----- (intermediate) -----END CERTIFICATE-----
                     -----BEGIN CERTIFICATE----- (root) -----END CERTIFICATE-----]
expiration          2026-08-03T09:30:00.000Z
issuing_ca          -----BEGIN CERTIFICATE-----(intermediate)-----END CERTIFICATE-----
private_key         -----BEGIN RSA PRIVATE KEY-----
MIIE... (kunci privat yang sesuai dengan sertifikat ini)
-----END RSA PRIVATE KEY-----
private_key_type    rsa
serial_number       6c:1f:9a:...

Sertifikat yang dihasilkan punya masa hidup 24 jam (expiration: 2026-08-03). Artinya, aplikasi yang sadar-PKI akan meminta sertifikat baru setiap hari — dan otomatis mendapat key + sertifikat segar. Pola inilah yang membuat serangan "sertifikat kadaluarsa yang lupa diperbarui" menjadi tidak mungkin terjadi.

#Sertifikat Short-Lived vs Tradisional

#CRL, OCSP, dan Revocation

Meski short-lived mengurangi kebutuhan revokasi, Vault tetap menyediakan mekanisme standar PKI:

• CRL (Certificate Revocation List) — daftar serial number sertifikat yang dicabut. Vault memelihara CRL otomatis di endpoint /v1/pki/crl (dan /v1/pki_int/crl untuk intermediate).
• OCSP (Online Certificate Status Protocol) — protokol untuk mengecek status satu sertifikat secara real-time. Vault menyediakan endpoint OCSP.

Mencabut sertifikat yang terlanjur bermasalah:

vault write pki_int/revoke serial_number="6c:1f:9a:..."

Output:

Key                    Value
---                    -----
revocation_time        1722570000
revocation_time_rfc3339 2026-08-02T10:00:00.000Z
state                  revoked

Setelah revoke, serial number tersebut masuk ke CRL dan koneksi yang memverifikasi lewat CRL/OCSP akan menolak sertifikat itu.

#Mengelola Inventaris Sertifikat & Otomatisasi Renewal

Salah satu keuntungan paling terasa dari PKI engine adalah visibilitas total. Mari lihat sertifikat apa saja yang pernah diterbitkan:

vault list pki_int/certs

Output:

Keys
----
2a:1f:9c:...
6c:1f:9a:...
a3:8e:2b:...

Setiap serial number mewakili satu sertifikat. Kalian bisa menarik detailnya:

vault read pki_int/cert/6c:1f:9a:...

Output:

Key                Value
---                -----
certificate        -----BEGIN CERTIFICATE-----
MIIE... (certificate PEM)
-----END CERTIFICATE-----
revocation_time    <nil>
revocation_time_rfc3339 <nil>
state              issued

Perhatikan kolom state: issued dan revocation_time: <nil> — tanda bahwa sertifikat ini masih aktif. Dengan inventaris seperti ini, tim tidak perlu lagi membuat spreadsheet manual untuk melacak "siapa yang punya sertifikat apa".

Tapi visibilitas saja tidak cukup — bagian tersulit adalah renewal otomatis. Sertifikat TTL 24 jam tidak berguna jika proses memintanya masih manual. Di produksi, pola yang dipakai:

Kunci keberhasilannya ada di satu pola pikir: jangan menunggu sertifikat kadaluarsa — jadwalkan renewal jauh sebelum TTL habis (misalnya pada 2/3 umur sertifikat). Dengan begitu, "sertifikat kadaluarsa" berubah dari insiden menjadi kejadian yang tidak pernah terjadi.

#Kesalahan Umum PKI

#Penutup

Pada episode 7 ini kita telah membahas PKI Secrets Engine: mengapa sertifikat internal yang kadaluarsa adalah masalah nyata, arsitektur Root CA + Intermediate CA yang dianjurkan, alur lengkap pembuatan Root, CSR intermediate yang ditandatangani Root, pembuatan role, hingga penerbitan sertifikat short-lived on-demand. Kita juga melihat CRL, OCSP, mekanisme revocation, dan jebakan-jebakan umumnya.

Inti episode ini: sertifikat short-lived mengubah rotasi sertifikat dari acara tahunan yang melelahkan menjadi siklus hidup otomatis harian. Dengan TTL 24 jam, tidak ada lagi yang namanya "sertifikat kadaluarsa yang terlupakan" — dan jika terjadi kebocoran, dampaknya dibatasi oleh umur sertifikat, bukan oleh kecepatan manusia merespons.

Di episode 8 selanjutnya, kita akan melengkapi pengetahuan secrets engine dengan tiga engine tambahan yang sering dipakai di lapangan: TOTP (2FA terpusat), SSH (OTP & CA signing), dan AWS (dynamic IAM credentials). Tiga persoalan keamanan berbeda, satu pola pikir yang sama: rahasia tidak disimpan, melainkan dikelola. Pastikan tetap semangat!