Belajar PKI - Advanced X.509 & Certificate Formats

#Pendahuluan

Di episode 16 kalian belajar mengelola CA secara bertanggung jawab: pemisahan root, rotasi, dan audit. Kini saatnya menyelami detail teknis yang selama ini mungkin kalian lewati. Ketika kalian melihat file sertifikat di terminal, apa yang sebenarnya kalian lihat? Apa beda file .crt, .pem, .p12, dan .jks? Episode 17 menjawab semua itu.

Selain format, kita akan menelusuri fitur lanjutan yang sering menentukan keamanan sertifikat di dunia nyata: Certificate Transparency yang menjaga penerbitan tetap terbuka, Extended Key Usage yang membatasi pemakaian sertifikat, name constraints yang mengontrol cakupan CA, dan struktur yang diatur RFC 5280.

Format dan detail ini bukan teori kosong. Kesalahan memilih format menyebabkan aplikasi tidak bisa membaca kunci, salah menempatkan EKU membuat sertifikat ditolak server, dan tanpa CT, sertifikat bisa diterbitkan tanpa jejak.

#Format Sertifikat: PEM dan DER

PEM adalah format teks yang paling umum. Ia berupa blok base64 dengan pembatas seperti BEGIN CERTIFICATE dan END CERTIFICATE. Karena berbasis teks, PEM mudah dilihat, mudah disalin, dan bisa berisi banyak objek sekaligus dalam satu file. DER adalah versi binernya, yang sering dipakai oleh Java, Windows, dan perangkat embedded.

Kebanyakan file dengan ekstensi .crt, .cer, dan .pem menyimpan konten PEM. DER biasanya muncul dengan ekstensi .der atau sebagai output kriptografi mentah. Konversi antara keduanya sederhana.

openssl x509 -in cert.pem -outform der -out cert.der
openssl x509 -inform der -in cert.der -out cert.pem

Perintah pertama mengubah PEM menjadi DER, perintah kedua mengembalikannya. openssl x509 dengan -outform der adalah pasangan yang selalu dipakai untuk konversi ini.

#PKCS 12: Satu File untuk Semua

PKCS 12, dengan ekstensi .p12 atau .pfx, adalah wadah biner yang membungkus sertifikat dan private key dalam satu file terenkripsi. Ini format andalan untuk ekspor dari browser dan import ke server Windows atau load balancer. Keuntungannya jelas: satu file membawa semua yang dibutuhkan.

Kelemahannya juga perlu diketahui: karena isinya sensitif, file PKCS 12 harus dilindungi passphrase yang kuat, dan saat disimpan harus diperlakukan seperti private key, bukan file biasa. Sertifikat yang sudah beredar tanpa kunci tidak masalah, tetapi file .p12 membawa keduanya.

openssl pkcs12 -export \
  -inkey server.key -in server.crt \
  -certfile ca.crt \
  -out server.p12

openssl pkcs12 -export menggabungkan private key, sertifikat leaf, dan rantai CA menjadi satu file .p12. Perhatikan urutannya: -inkey untuk kunci, -in untuk sertifikat, -certfile untuk CA tambahan.

#JKS dan Keytool

JKS alias Java KeyStore adalah format biner milik ekosistem Java. Ia menyimpan kunci dan sertifikat dengan alias, dan dikelola lewat tool bernama keytool. Meski formatnya biner, isinya bisa diekspor dan diimport ke format lain.

keytool -importkeystore \
  -srckeystore server.p12 -srcstoretype PKCS12 \
  -destkeystore server.jks -deststoretype JKS

Perintah di atas mengimport isi file .p12 ke dalam JKS. keytool -importkeystore adalah cara standar memindahkan material kunci antara PKCS 12 dan JKS tanpa mengetik ulang sertifikat secara manual.

#Konversi antar Format

Dalam karier kalian, kalian akan bolak-balik antara PEM, PKCS 12, dan JKS. Tiga perintah berikut merangkum pola yang paling sering dipakai.

openssl pkcs12 -in server.p12 -nodes \
  -out server.pem

keytool -exportcert -alias mycert -rfc \
  -keystore server.jks -file server.crt

openssl x509 -in server.pem -text -noout

openssl pkcs12 -in ... -nodes membongkar file .p12 menjadi konten PEM yang bisa dibaca, sedangkan keytool -exportcert -rfc mengekspor sertifikat dari JKS dalam format PEM. Terakhir, openssl x509 -text menampilkan seluruh isi sertifikat untuk inspeksi manual.

#Certificate Transparency dan SCT

Certificate Transparency adalah sistem yang mencatat setiap sertifikat yang diterbitkan ke dalam log publik yang tidak bisa dipalsukan. Tujuannya sederhana: jika ada pihak tak berwenang menerbitkan sertifikat atas nama domain kalian, sertifikat itu akan terlihat di log, sehingga bisa dideteksi dan dicabut.

Bukti bahwa sebuah sertifikat sudah masuk log disebut SCT, kependekan dari Signed Certificate Timestamp. Sertifikat modern menyertakan SCT di dalamnya, dan banyak browser menolak sertifikat tanpa SCT yang valid. CT mengubah PKI dari sistem kepercayaan buta menjadi sistem yang bisa diaudit siapa saja.

step certificate inspect https://example.com \
  --format json

step certificate inspect dengan URL akan menarik sertifikat dari server dan menampilkan isinya. Kalian bisa memeriksa bagian extensions untuk melihat apakah SCT ada dan dari log mana ia berasal.

#Extended Key Usage (EKU)

Extended Key Usage menentukan fungsi yang diizinkan sebuah sertifikat. Tanpa EKU, sertifikat bisa dipakai untuk banyak hal. Dengan EKU, pemakaian dibatasi: sebuah sertifikat bisa khusus untuk TLS server, khusus untuk client auth, atau khusus untuk menandatangani kode.

Beberapa nilai EKU yang sering muncul: serverAuth, clientAuth, codeSigning, dan emailProtection. Jika sebuah sertifikat menandai hanya clientAuth, maka memakainya sebagai sertifikat server akan ditolak oleh lawan bicara yang memeriksa EKU. Ini kontrol penting yang mencegah sertifikat disalahgunakan.

Contoh dari episode 10: sertifikat client dengan usages client auth memastikan sertifikat tersebut tidak bisa dipakai untuk menerima koneksi server. EKU bekerja seperti sekat penggunaan.

#Name Constraints

Name constraints adalah fitur di sertifikat CA yang membatasi domain mana yang boleh diterbitkan. Sebuah CA internal bisa diberi constraint hanya untuk internal.example.com, sehingga CA tersebut secara teknis tidak bisa menerbitkan sertifikat untuk domain lain, bahkan oleh penyusup yang berhasil menguasainya.

Ini fitur yang sering diremehkan. CA publik seperti Let's Encrypt tidak bisa menerapkan constraint karena harus melayani domain apa pun, tetapi CA internal justru diuntungkan. Dengan name constraints, kesalahan konfigurasi atau penyusupan pada satu CA tidak langsung menghancurkan seluruh ruang nama.

#RFC 5280 dan Detail Struktur

RFC 5280 adalah spesifikasi yang mendefinisikan profil sertifikat X.509 dan CRL. Ia mengatur struktur field, aturan validasi, dan ekstensi yang diizinkan. Kalau kalian membaca output openssl x509 -text, hampir semua bagian yang muncul diatur di RFC 5280.

Beberapa elemen yang diatur RFC 5280: version, serial number, subject, issuer, validity period, public key, dan berbagai ekstensi seperti subjectAltName, keyUsage, dan basicConstraints. Validasi rantai juga diatur di sini, termasuk aturan bahwa setiap sertifikat harus ditandatangani oleh issuer yang sesuai sampai ke trust anchor.

#Penutup

Episode 17 melengkapi pengetahuan teknis kalian tentang X.509. Kalian mengenali perbedaan PEM dan DER, memahami PKCS 12 sebagai wadah sertifikat dan kunci, menggunakan keytool untuk JKS, dan menguasai konversi antar format. Kalian juga mempelajari Certificate Transparency, Extended Key Usage, name constraints, dan struktur yang diatur RFC 5280.

Inti yang harus dibawa pulang:

• PEM adalah format teks yang bisa dibaca, sedangkan DER adalah versi biner yang sering dipakai Java dan Windows.
• PKCS 12 membungkus kunci dan sertifikat dalam satu file yang harus dijaga seperti private key.
• keytool adalah alat utama untuk mengelola JKS di ekosistem Java.
• Certificate Transparency mencatat penerbitan ke log publik dan SCT menjadi bukti pencatatannya.
• Extended Key Usage membatasi fungsi sertifikat dan mencegah penyalahgunaan.
• Name constraints membatasi ruang nama yang boleh diterbitkan sebuah CA.

Di episode 18 kita menaikkan skala: high availability dan multi-CA. Kalian akan belajar memisahkan intermediate CA per environment, cross-signing untuk migrasi root, root rotation bertahap, strategi HA untuk step-ca dan cert-manager, serta skenario recovery. Sampai jumpa!