Membuat Certificate Authority
Seperti telah dijelaskan di beberapa postingan sebelumnya, Crypto Token adalah Struktur logikal dimana kunci sebuah CA diletakkan. Karena kita menggunakan “Soft” Crypto Token, kita bisa membayangkannya sebagai tabel-tabel dalam database kita.
- karena bentuknya yang “Soft”, fakta ini membuat keamanan database menjadi sesuatu yang harus lebih diperhatikan.
kita punya 2 opsi untuk mendefinisikan Crypto Token yang digunakan oleh CA yang kita buat:
- Membuat Crypto Token terlebih dahulu kemudian mengasosiasikannya dengan CA yang baru.
atau:
- Mengizinkan EJBCA untuk membuat Crypto Token secara otomatis
Ada konsekuensi ketika kita mengizinkan EJBCA untuk membuat Crypto Token: Itu menggunakan kunci RSA 2048-bit dalam sertifikat CA, dan tidak memberikan kita sebuah opsi untuk memilih yang lain.
Saat sebuah sertifikat CA dikeluarkan, sertifikat tersebut tidak bisa dengan mudah di-update dengan sebuah kunci baru yang lebih kuat. Faktanya, hal tersebut memang tidak bisa dilakukan. Jadi kalau kita berharap menggunakan kunci yang lebih kuat untk CA kita, maka kita harus membuat Crypto Token tersebut secara manual.
Membuat Crypto Token sangatlah mudah. Pertama, masuk ke dalam interface Crypto Token:
Kemudian kita pilih “Create New” yang akan membawa kita ke halaman “New Token”:
‘Authentication Code” adalah sebuah password yang digunakan untuk mengenkrip Crypto Token itu sendiri. Kita akan membutuhkan Authentication Code tersebut ketika memperbarui CA yang menggunakan Crypto Token tersebut. “Auto Activation” juga harus dicentang.
Crypto Token harus diisi dengan satu set kunci sebelum kita dapat menggunakannya:
Dalam contoh di atas, saya menambahkan beberapa kunci yang penting:
- certSignKey – Digunakan untuk menandatangani sertifikat.
- defaultKey – digunakan untuk semuanya.
- testKey – digunakan untuk pengecekkan internal saja.
Pada contoh di atas juga, kita akan melihat sebuah key dengan nama “crlSignKey”. Kunci ini sudah tidak diperlukan lagi. Kita juga menambahkan sebuah kunci yang disebut “ec2561pKey” untuk tujuan uji coba, untuk menunjukkan bahwa kunci EC dapat dihasilkan dan digunakan oleh CA dengan sebuah RSA sebagai defaultKey.
Ketika selesai, kita akan melihat crypto token kita dengan label “Active”, tapi belum digunakan. Setelah ktia menghubungkan antara CA dengan Crypto Token, status tersebut akan berubah menjadi “Used”.
Setelah kita membuat Crypto Token tersebut maka sekarang kita bisa membuat sebuah CA.
Pada opsi ini, kita tidak punya pilihan untuk menggunakan CA yang sudah ada sebagai template.
Berikut ini adalah beberapa pengaturan yang akan kita gunakan untuk membuat CA yang saya beri nama “Real Root CA“:
- Type of CA: X509
Ini adalah standar untuk komunikasi internet - Signing Algorithm: Sha256WithRSA
Pilih ini karena SHA-1 sudah tidak layak untuk digunakan. - Crypto Token: NamaKriptoToken
Dibawah ini merupakan beberapa nama pada key (dari Crypto Token yang kita buat tadi) yang digunakan untuk tujuan standar:
defaultkey: defaultKey
certSignKey: certSignKey
keyEncryptKey: – Use default key
hardTokenEncrypt: – Use default key
testKey: testKey
Extended Service Key Specification: RSA 2048 - Enforce Unique Serial Number: Enabled
Kita akan memaksa agar sertifikat yang dikeluarkan selalu memiliki nomor seri yang unik. - Use Certificate Request History: Enabled
Pada dasarnya ini untuk kepentingan audit. - Validity: 3652d
Lamanya waktu CA ini akan valid - Subject DN: CN= ca.perusahaanlo.com, O=perusahaan lo, C=negara lo
Ini adalah DN yang akan masuk ke dalam sertifikat CA. CN akan ada secara default tapi akan lebih baik jika kita juga menambahkan O dan C. - Signed By: Self Signed
Karena ini akan menjadi Root CA baru, dia akan menandatangani sertifikatnya sendiri. - Subject Alternative Name: dNSNme=nama.perusahaanlo.com
Seperti yang sudah dibicarakan, ini adalah FQDN dari CA. Namun, dalam field ini, FQDN harus diawali dengan prefix “dNSName=“. Sepertinya, ini satu-satunya area dalam EJBCA dimana kita harus menulis prefix ini terlebih dahulu. “dNSName” dituangkan dalan RFC4985 untuk X.509 Subject Alternative Name. - Use Issuing Distribution Point on CRLs: Enabled
Ini mengaktifkan sebuah field yang akan menampung URL untuk pengambilan CRL CA ini di CA’s own certificate. - Generate Default CRL Distribution Point: Generated, tetapi hapus “:8080” dari URL, dan ganti protokol dari “http://” ke “https://”
Kita melakukan ini karena aturan pada firewall yang sudah kita tetapkan, yang memaksa semua request menggunakan HTTPS. - Generate Default CRL Issuer: Generated
Jangan Edit string ini. ini harus menjadi DN kita. - CA Defined FreshestCRL Extension: Not Generated
Kita tidak menggunakan “Delta CRL” dalam CA kita, jadi field ini tidak kita perlukan. - CA Issuer URI: Empty
Ini opsi field yang dapat kita abaikan. - Default OCSP Service Locator: Generated, hilangkan “:8080” dan ganti “http://” dengan “https://”, alasannya sama seperti di atas.
Sekarang buat CA. Jika pembuatan CA gagal, tekan “back” di browser dan settingan kita akan kembali. perbaiki yang salah dan coba lagi.
Berikut ini kurang lebih tahapannya:
Setelah CA kita jadi, kita masih punya langkah terakhir sebelum CA ini berfungsi dengan baik. Kita harus mengaktifkan “Internal Health Check” pada halaman “CA Activation”:
Proses Health Check adalah sebuah pemeriksaan secara otomatis status dari suatu CA dimana sebuah sesi HTTPS melakukannya secara periodik. Akses ke URL healthcheck ini terbatas untuk localhost, dan secara default URL selalu mengembalikan string “ALLOK” (Seperti yang sudah didefinisikan di file ejbca.properties).
- URL untuk OCSP juga melakukan health-checked, seperti yang ditulis dalam va.properties.
Okay sampai di situ dulu postingan kali ini. Semoga bisa membantu kalian dalam membuat sebuah CA.
Di postingan selanjutnya kita akan mencoba untuk membuat sebuah entitas akhir alias End Entity.
Terima Kasih 🙂
Comments are closed.