EJBCA menggunakan Certificate Profile untuk menyimpan beberapa set data field sertifikat yang umumnya digunakan. Hal ini merupakan mandatori atau wajib untuk menggunakan Certificate Profile ketika membuat sebuah sertifikat. Secara default, EJBCA memiliki 5 profil yang telah ditetapkan dan berisi informasi yang masih sangat minim. Kelima profil tersebut tidak dapat diubah atau dihapus. Dan mereka adalah:

Pada kesempatan kali ini, kita akan membuat profil baru dengan nama “Sertifikat untuk TLS” yang didasari dari profil “SERVER“. Seperti yang kalian duga, Profil SERVER ini dimaksudkan untuk mengeluarkan sertifikat bagi server yang mendukung TLS.

Berikut ini adalah data field yang akan digunakan dalam profil ini. Perhatikan, beberapa field disini berisi data yang berasal dari profil SERVER:

• Available Bit Lengths: 192, 256, 384, 512, 2048, 4096, 8192
  Ketika sebuah sertifikat diminta dengan menggunakan profil ini, hanya request yang menggunakan algoritma-algoritma dengan Key Lengths inilah yang akan terpenuhi. EJBCA tidak membedakan jenis algoritmanya pada field ini, Jadi adalah sebuah ide yang bagus untuk menyediakan kunci mulai dari panjang 192-512 bit untuk mendukung permintaan Elliptic Curves, dan panjang 2048-8192 untuk permintaan RSA.
• Signature Algorithm: “Inherit” atau “SHA256 with RSA”
  Semua sertifikat ditandatangani oleh CA yang mengeluarkannya dengan menggunakan algortima hash tertentu. SHA-1 dulu masih menjadi standard de-facto di internet untuk penandatanganan, namun sekarang sudah berubah ke SHA256 atau SHA512. Ingat bahwa memilih antara RSA atau ECDSA pada field ini tidak mempengaruhi algortima public key utama yang digunakan dalam sertifikat yang dikeluarkan. Namun, kita harus menggunakan nilai yang tepat untuk algoritma yang akan kita gunakan. Memilih “Inherit” berarti semua sertifikat yang dikeluarkan dari profile ini akan mengikuti algoritma dari CA yang mengeluarkannya.
• Validity: 3652d
  Ini adalah lamanya waktu sertifikat akan valid. “d” disitu maksudnya adalah “days” alias “hari”. nilai di atas berarti sertifikat ini valid untuk 10 tahun
• Overrides: Do not allow overrides
  Kita memiliki opsi untuk mengizinkan nilai yang ditetapkan dalam sebuah Certificate Signing Request (CSR) untuk “ditimpa” oleh nilai yang ditentukan dalam Profil. Memang mungkin ada alasan yang bagus untuk mengizinkan hal tersebut, tapi dalam profil kali  ini kita tidak akan mengizinkan ini.
• Key Usage: Digital Signature, Key Enchiperment
  Nilai-nilai ini menentukan kegunaan yang diizinkan boleh ada dalam sertifikat. Jadi kalau pada kasus di atas, sertifikat hanya bisa digunakan untuk penandatanganan digital dan enkripsi.
• Extended Key Usage: Server Auth, Client Auth
  Sama seperti Key Usage, field ini juga ditentukan dalam sertifikat. Namun pelaksanaannya terserah dari aplikasi yang menggunakan sertifikat
• Subject Alternative Name: Enabled
  Konvensi standar penamaan untuk mengidentifikasi pemilik sertifikat adalah dengan X.500 Standard. Namun, kebanyakan sertifikat digunakan oleh perangkat yang menggunakan DNS untuk identifikasi. Field ini secara khusus mengandung FQDN dari pemilik sertifikat jika itu adalah sebuah perangkat, atau sebuah alamat email jika pemiliknya adalah manusia.
• Use CRL Distribution Point: Enabled
  opsi ini akan mengaktifkan sebuah field dalam Certificate Profile yang merupakan URL/URI yang menjelaskan lokasi dari sebuah CRL. Mengaktifkan field ini berarti CA akan menggunakan Certificate Profile ini harus mendukung fitur Validation Authority, dan mengurus proses update CRL.
• Use CA Defined Distribution Point: Enabled
  Kita akan menggunakan URL dari CA yang mengeluarkan sertifikat tersebut. Jika opsi ini tidak dipilih, Sebuah URL untuk CRL harus ditulis secara manual. Ini bisa merupakan sebuah alamat “http://” atau alamat “ldap://”. HTTP merupakan standar untuk penggunaan internet. Sementara Active Directory dari Microsoft menggunakan baik HTTP ataupun LDAP. Ada sedikit pengecualian soal aturan pengalamatan ini yang akan dijelaskan lebih lanjut nanti
• FreshestCRL Extension: Disabled
  Opsi ini akan mengaktifkan kegunaan dari Diferensial CRL atau yang lebih dikenal dengan Delta CRL. CRL bisa sangat panjang, dan kegunaan dari Delta CRL memungkinkan sebagian dari seluruh CRL saja yang didistribusikan. Kita tidak akan menggunakan fungsi ini. Jika fungsi ini diaktifkan, tipe alamat yang sama yang digunakan untuk CRL Primary harus diaktifkan juga.
• Certificate Policies: Disabled
  Certificate Policies adalah opsi-opsi RFC yang digunakan untuk tujuan administratif. Kita tidak akan menggunakan opsi ini.
• Authority Information Access: Enabled, Use CA Defined OCSP Locator
  Profil ini akan memasukkan informasi terkait URI target yang akan digunakan untuk mencapai service OCSP dari CA yang mengeluarkan sertifikat, tapi akan mewarisi detailnya dari CA yang mengeluarkan tersebut
• Subset of Subject Alt Name: Restrict to “DNS Name” Only
  Karena kita hanya akan  menggunakan sertifikat yang dihasilkan dari profil demonstrasi ini untuk Device-based TLS, kita hanya akan menggunakan DNS-Based Alternative Names.
• Available CA: Any CA
  Kita akan mengizinkan profil ini untuk digunakan oleh CA manapun yang ada di server EJBCA ini.

Berikut ini adalah Screenshot dari Aplikasi:

Itu tadi cara untuk membuat Certifitcate Profile dengan mengadopsi dari profil “Server” yang sudah ada. di postingan berikutnya akan dilanjutkan dengan cara membuat End Entity Profile.

Sampai jumpa di postingan berikutnya

Source: EJBCACENTOS

The post Membangun CA Production Awal (Bagian 2) first appeared on GoBlog.