Belajar PKI - Fitur Modern & Roadmap

#Pendahuluan

Episode 20 membawa kita ke kriptografi post-quantum dan tren modern. Tapi teori hanya berguna jika alat yang kalian pakai benar-benar mengikutinya. Pertanyaan yang wajar muncul: apakah OpenSSL yang saya instal sudah mendukung ML-DSA? Bagaimana dengan cert-manager dan step-ca yang saya pakai di production? Dan ke mana arah industri ini bergerak di tahun 2026?

Episode 21 menjawab semua itu. Kita bedah roadmap tiga alat yang paling sering dipakai sepanjang series ini — OpenSSL, cert-manager, dan step-ca — lengkap dengan angka versi dan kebijakan dukungan yang berlaku saat ini, lalu menutup dengan tiga tren besar 2026: mandatory mTLS di Kubernetes, TLS post-quantum yang sudah distandarkan, dan PKI-as-code.

#OpenSSL 4.0 dan Strategi Rilis

OpenSSL memiliki pola rilis yang penting dipahami agar tidak salah pilih versi. Versi mainline seperti 4.0 dirilis dengan fitur terbaru, tapi berumur pendek — dukungannya sekitar tiga belas bulan. Versi Long Term Support atau LTS hidup bertahun-tahun dan menerima backport keamanan, dan karena itu jadi pilihan utama untuk production.

Rilis utama OpenSSL 4.0 tiba pada April 2026, dan pembaruan terbarunya, OpenSSL 4.0.1, rilis pada Juni 2026 dengan perbaikan beberapa CVE di area PKCS7, CMS, dan QUIC. Kalau kalian sudah memakai 4.0, segera naik ke 4.0.1. Tapi ingat: 4.0 adalah mainline, bukan LTS — untuk workload yang butuh stabilitas jangka panjang, 3.5 LTS tetap rekomendasi utama.

openssl version -a

Cek versi kalian sekarang juga: openssl version cukup untuk tahu nomor build, sementara -a menampilkan detail kompilasi, tanggal rilis, dan direktori konfigurasi.

#Peta Dukungan yang Perlu Diketahui

Supaya tidak bingung di antara versi, berikut peta dukungan yang berlaku:

• OpenSSL 3.0 LTS resmi berakhir pada September 2026. Jika kalian masih memakainya, ini saat terakhir yang aman untuk migrasi.
• OpenSSL 3.5 LTS tetap direkomendasikan untuk production, dengan dukungan hingga April 2030. Stabil, teruji, dan menerima backport keamanan.
• OpenSSL 4.0 adalah mainline terbaru dengan dukungan sekitar tiga belas bulan, cocok untuk kalian yang butuh fitur terbaru dan rutin mengikuti rilis.

#Kebiasaan Upgrade yang Aman

Pergantian versi OpenSSL tidak bisa dilakukan tanpa rencana. Pertama, baca changelog untuk melihat perubahan perilaku default — kadang parameter yang dulu longgar kini diperketat, dan itu bisa mematahkan handshake yang selama ini berjalan. Kedua, uji seluruh rangkaian aplikasi yang bergantung pada TLS di staging, termasuk client lama yang memakai cipher usang.

Ketiga, siapkan jalur rollback. Dengan package manager, simpan versi sebelumnya atau gunakan image yang bisa dikembalikan, seperti pola Docker yang sudah kalian kenal dari episode awal. Terakhir, pantau selama beberapa hari setelah upgrade, bukan hanya saat proses selesai. Perilaku kriptografi sering baru terlihat saat beban tinggi atau saat koneksi yang jarang terjadi mencoba handshake.

#Provider dan Post-quantum di OpenSSL 4.0

OpenSSL 4.0 melanjutkan arsitektur provider yang sudah kita bahas di episode 20. Dukungan post-quantum diakses lewat provider tambahan, sehingga library inti tetap ramping dan adopsi algoritma baru tidak menunggu rilis besar berikutnya. ML-KEM, ML-DSA, dan SLH-DSA tersedia sebagai provider dan sudah bisa dipakai untuk handshake hybrid serta tanda tangan sertifikat.

openssl list -providers
openssl list -kem-algorithms | rg -i mlkem

Bagi operator, ini berarti kemampuan post-quantum tidak lagi bergantung pada versi OpenSSL, melainkan pada provider yang kalian pasang. Kebijakan provider bisa diatur per aplikasi lewat konfigurasi, sehingga transisi bertahap yang kita rancang di episode 20 bisa dijalankan per layanan, bukan serentak.

#cert-manager 1.21

cert-manager terus bergerak cepat. Rilis 1.21 menghadirkan ACME profiles, yang memungkinkan kalian mendefinisikan profil sertifikat standar — masa berlaku, algoritma, dan extension — lalu memakai kembali profil yang sama di banyak Certificate. Ini menghapus duplikasi konfigurasi dan membuat kebijakan konsisten di seluruh cluster.

Dukungan short-lived certificates juga semakin matang: Certificate dengan masa berlaku sangat pendek memanfaatkan penuh otomatisasi ACME, persis yang kita bahas di episode 20. Yang tak kalah penting, ekosistem ExternalIssuer terus tumbuh — provider pihak ketiga yang menghubungkan cert-manager ke CA mana pun, dari step-ca, Vault, hingga HSM kelas enterprise, melalui satu API yang sama.

helm upgrade cert-manager jetstack/cert-manager \
  --namespace cert-manager --version v1.21.0
kubectl apply -f cluster-issuer-stepca.yaml

Otomatisasi mTLS juga menjadi fokus: service mesh dan workload memakai identitas dari cert-manager untuk saling mengautentikasi, dan ini mendukung arah industri yang kita lihat di tren 2026.

#step-ca 0.30

Di sisi step-ca, rilis 0.30 membawa penyempurnaan pada manajemen provisioner, termasuk alur yang lebih baik untuk menerbitkan sertifikat mTLS dan short-lived. Kualitas production yang kita bangun di episode 9 dan 18 — HA, HSM, dan distribusi — terus diperkuat sebagai fondasi.

step version
step ca health

Roadmap step-ca mengarah ke adopsi post-quantum dan integrasi yang lebih dalam dengan trust-manager, proyek yang mengelola distribusi trust bundle ke seluruh cluster — persis kebutuhan episode 5 tentang distribusi root certificate. Dengan trust-manager, bundle CA disebar sebagai artefak yang dikelola secara terpusat, dan step-ca menjadi pemasoknya.

Bagi kalian yang baru bergabung di tengah perjalanan, kedua alat ini bisa dipelajari dari episode 9 dan 10 sebagai fondasi, lalu episode 18 dan 19 untuk sisi HA dan monitoring. Kombinasi cert-manager dan step-ca menutupi hampir semua kebutuhan identitas modern — dari sertifikat aplikasi, mTLS antar service, hingga SSH certificates.

#Tren 2026: Mandatory mTLS di Kubernetes

Tahun 2026 menandai langkah besar: mTLS menjadi kewajiban default di banyak platform Kubernetes, terutama lewat Gateway API. Jika dulu mTLS adalah pengaturan tambahan untuk yang rajin, kini ia menjadi bagian dari kebijakan yang ditegakkan di level API gateway, bukan lagi di aplikasi masing-masing.

Dengan pendekatan ini, setiap service punya identitas yang diverifikasi sebelum traffic diizinkan masuk. Deployment Kubernetes diwajibkan memiliki identitas workload yang valid — disediakan oleh cert-manager dan issuer seperti step-ca — sehingga klaster tanpa pengelolaan sertifikat yang rapi akan terlihat jelas saat audit.

#Tren 2026: Post-quantum TLS yang Distandarkan

Standar post-quantum yang kita bahas di episode 20 kini masuk fase adopsi nyata. Browsers, CDN, dan library TLS besar mulai mengaktifkan handshake hybrid secara default, dan NIST terus merampungkan detail interoperabilitas untuk sertifikat dan tanda tangan post-quantum. Harapannya, dalam beberapa tahun, rantai sertifikat penuh post-quantum menjadi hal biasa.

ssl_conf:
  system_default:
    options: default
    groups: X25519MLKEM768:MLKEM768

Jaringan yang tidak mendukung grup hybrid masih berjalan normal — handshake jatuh ke algoritma klasik secara otomatis. Inilah keindahan hybrid: aman untuk masa depan tanpa memutus kompatibilitas hari ini.

Yang perlu disiapkan operator hanyalah konfigurasi daftar grup di sisi server dan client. Karena handshake hybrid bernegosiasi otomatis, kalian tidak perlu mengubah aplikasi satu per satu — cukup pastikan versi library TLS sudah cukup baru, lalu aktifkan grup hybrid di konfigurasi sistem.

#Tren 2026: PKI-as-code

Terakhir, PKI-as-code menjadi pola yang lebih diterima: seluruh konfigurasi PKI — root, intermediate, issuer, sertifikat, bahkan kebijakan masa berlaku — dikelola sebagai kode di git, diterapkan lewat Terraform dan GitOps seperti yang kita bangun di episode 19. Ini membawa semua kebaikan Infrastructure as Code ke dunia identitas digital.

Reproducibility menjadi kuncinya: klaster baru dibangun dengan PKI yang sudah terdefinisi, bukan disusun manual. Audit jadi mudah karena setiap perubahan punya jejak. Dan yang paling penting, PKI-as-code membuat keamanan identitas menjadi bagian dari arus kerja pengembangan, bukan tugas terpisah yang menakutkan.

Kombinasikan dengan alerting dari episode 19 dan penerapan post-quantum dari episode 20, dan kalian punya fondasi yang bisa tumbuh: kebijakan berubah cukup lewat pull request, dipantau otomatis, dan siap menghadapi algoritma apa pun yang datang berikutnya.

#Penutup

Episode 21 memetakan jalan ke depan: OpenSSL 4.0.1 dengan perbaikan CVE di PKCS7, CMS, dan QUIC, kebijakan LTS yang jelas — 3.5 hingga April 2030, 3.0 berakhir September 2026 — fitur cert-manager 1.21 dengan ACME profiles dan ExternalIssuer, step-ca 0.30 yang mengarah ke post-quantum dan trust-manager, serta tiga tren besar 2026: mandatory mTLS, TLS post-quantum, dan PKI-as-code.

Inti yang harus dibawa pulang:

• OpenSSL 4.0 adalah mainline berumur pendek; pakai 3.5 LTS untuk production dan segera tinggalkan 3.0.
• Dukungan post-quantum di OpenSSL datang lewat provider, sehingga bisa diadopsi per layanan.
• cert-manager 1.21 memudahkan konsistensi lewat ACME profiles dan ekosistem ExternalIssuer.
• step-ca 0.30 memperkuat mTLS otomatis dan terhubung dengan trust-manager untuk distribusi bundle.
• Tahun 2026 menjadikan mTLS, TLS post-quantum, dan PKI-as-code sebagai standar yang harus diikuti.

Ini episode terakhir pembahasan alat dan tren. Di episode 22 kita rehat sejenak dan melihat seluruh peta: membandingkan semua ekosistem PKI yang pernah kita kenal, kapan memakai yang mana, rekap lengkap perjalanan ini, dan checklist produksi. Sampai jumpa di sana!