Membuat Sertifikat Elektronik yang Mendukung LTV pada EJBCA

LTV – Saat ingin melakukan penandatanganan secara elektronik, kita tidak bisa lepas dari yang namanya PAdES. Apa itu PAdES? PAdES (PDF Advanced Electronic Signatures) merupakan sekumpulan batasan dan juga ekstensi untuk PDF dan ISO 32000-1 yang membuatnya sesuai untuk Advanced Electronic Signatures (AdES). PAdES ini menjadi penting sebab profiling yang mereka terapkan ini memenuhi aturan dari European eIDAS, yaitu sekumpulan aturan untuk identifikasi secara elektronik dan layanan kepercayaan untuk transaksi elektronik.

PAdES mengetahui bahwa dokumen yang sudah ditandatangani secara elekronik bisa saja digunakan atau diarsipkan selama bertahun-tahun – bahkan mungkin ratusan tahun. Kapan pun di masa yang akan datang, terlepas dari kemajuan teknologi dan faktor lainnya, dokumen yang sudah ditandatangani secara elektronik ini harus tetap bisa divalidasi untuk mengonfirmasi bahwa signature-nya masih valid saat waktu penandatanganan dilakukan. Konsep inilah yang dikenal dengan istilah LTV (Long-Term Validation). (source: Docusign)

Saat LTV ini aktif, status dari waktu penandatanganan (timestamp) akan ditangkap dan disimpan ke dalam dokumen PDF. Tidak hanya itu, bahkan CRL (Certificate Revocation List) pun dimasukkan ke dalam dokumen. Dengan adanya waktu penandatanganan dan CRL di dalam dokumen, proses verifikasi sertifikat bisa dilakukan di dalam dokumen itu sendiri, terlepas dari apakah sertifikat telah kedaluwarsa, dicabut, atau otoritas penerbit tidak lagi ada kedepannya.

Dengan adanya LTV, kita tidak akan terlalu tergantung pada sistem eksternal dan mengurangi potensi ambiguitas di masa depan seputar sertifikat yang kadaluarsa atau dicabut.

Lalu bagaimana cara membuat sertifikat elektronik yang saat melakukan penandatanganan nanti, CRL dan Timestamp otomatis di-embed di dalamnya (Karena memang fitur LTV ini tidak otomatis aktif)? Berikut ini saya akan coba membuatkan tutorialnya dengan menggunakan EJBCA sebagai software untuk menerbitkan sertifikat elektroniknya dan Adobe Acrobat Reader sebagai software untuk melakukan penandatanganan elektronik di atas sebuah dokumen.

*Bagi yang belum melakukan instalasi EJBCA, kalian bisa membacanya terlebih dahulu DI SINI

1. Membuat Crypto Token

Sebelum membuat CA, yang perlu dibuat pertama kali adalah crypto token. Dalam EJBCA, crypto token merupakan sebuah area memori yang berisi kunci, entah itu di dalam HSM atau pun soft keystore yang dibuat secara lokal.

Untuk membuat crypto token, masuk ke dalam halaman admin dari EJBCA dan pilih Crypto Tokens yang berada di bawah menu CA Functions. Pilih Create New dan masukkan nama crypto token yang kalian inginkan. Oh ya, pilih tipe-nya soft ya.

Dalam tutorial kali ini, saya akan membuat 2 crypto token dengan tipe soft bernama “Darius Testing Root CA” untuk Root CA dan “Darius Testing CA” untuk CA-nya.

Pembuatan crypto token untuk Root CA yang bernama Darius Testing Root CA

FieldDeskripsi
NameHanya sebuah nama untuk Crypto Token
TypePKCS#11 untuk HSM atau Soft PKCS#12 keystore yang berada di database
Authentication CodePIN atau password PKCS#11 yang akan memproteksi soft keystore
Repeat Authentication Codehanya mengulang kode autentikasi. Isinya harus sama dengan Authentication Code
Auto Activation pilih jika Authentication Code harus disimpan (encrypted) di database dan crypto token dalam keadaan aktif
Allow export of private keysPilih jika kalian mengizinkan soft crypto token ini diekspor

Jika sudah, silakan kalian menambahkan key yang kalian inginkan untuk crypto token Root CA dan CA. Dalam tutorial kali ini, saya akan membuat 3 key untuk Darius Testing Root CA dan 4 key untuk Darius Testing CA. Untuk algoritma enkripsi, silakan pilih yang kalian suka ya. Kalau saya sih menggunakan RSA 4096.

Crypto toke Darius Testing Root CA
Crypto token Darius Testing CA
Total ada 2 crypto tokens. crypto token yang paling atas merupakan cotnoh crypto token yang disimpan di dalam HSM

2. Membuat Root CA

Dalam hierarki CA, Root CA menempati posisi paling atas. Root CA inilah yang akan menerbitkan CA dengan menandatangani certificate dari CA tersebut, sebelum akhirnya nanti sebuah CA akan mengeluarkan sertifikat untuk entitas akhir.

Untuk membuat CA, masuk ke dalam menu Certification Authorities. Tuliskan nama Root CA yang kalian inginkan pada field Add CA dan setelah itu tekan tombol Create. Kalian akan diarahkan untuk membuat pengaturan pada Root CA.

Membuat Root CA dengan nama Testing Root CA
  • CA Type (X509)
    Ada 2 pilihan yaitu X509 atau CVC. X509 merupakan sebuah CA normal untuk secure email, login, autentikasi web, VPN, dll. Sedangkan CVC merupakan CA yang mengeluarkan CV Certificates, yang merupakan sertifikat spesial untuk EU EAC ePassports. Info lebih lanjut soal CVC CA bisa dibaca DI SINI.
  • Signing Algorithm (SHA256WithRSA)
    Algoritma penandatangan yang digunakan untuk mengeluarkan sertifikat, menandatangani CRLs, dll.
  • Crypto Token (Darius Testing Root CA)
    Nah, crypto token yang sudah dibuat sebelumnya, akan diaplikasikan di sini. Karena ini Root CA, pilih “Darius Testing Root CA”. Crypto token merupakan tempat pemetaan CA Key diharapkan berada.
    FieldDeskripsi
    defaultKeyKey default yang akan digunakan
    certSignKeyKey yang digunakan untuk mengeluarkan sertifikat. Harus comply dengan algoritma penandatanganan dan hanya pilihan yang valid yang akan ditampilkan
    crlSignKeyKey yang digunakan untuk menandatangani CRL. Meskipun secara teori bisa dipisahkan dari certSignKey menurut RFCs, klien supportnya sangat jarang dan certSignKey lebih sering digunakan
    keyEncryptKeyKey yang digunakan untuk key recovery bila memang diaktifkan. Kunci untuk dekripsi di-escrow dan harus RSA
    hardTokenEncryptDeprecated. Sudah tidak dipakai
    testKeyKey yang digunakan oleh pemeriksaan kesehatan untuk memverifikasi bahwa crypto token bisa digunakan. Biasanya hanya kunci pendek untuk pemeriksaan koneksi secara cepat

    Jika tidak menentukan crypto token diawal, maka soft token (PKCS#12) akan dibuat secara otomatis dan akan punya nama yang sama dengan nama CA-nya. Crypto token akan diatur aktif secara otomatis dan memiliki password default foo123. Crypto token ini juga akan memiliki NODEFAULTPWD dengan nilai false, yang mengizinkan crypto token untuk dimanipulasi tanpa menggunakan sebuah password. Ubah password  (via CLI) atau non-aktifkan fitur aktivasi otomatis untuk membatalkan penggunaan kata sandi default.
  • Extended Services Key Spesification (RSA 4096)
  • Key Sequence Format (alphanumeric [0-90][a-z])
    Dengan EAC, ada beberapa opsi terkait format sequence. Format bisa dipilih pada field “Key Sequence Format” berikut ini adalah beberapa opsi yang tersedia:
    FieldDeskripsi
    5 byte numericSequence harus berisi karakter numerik [0-9]. Sequence bisa bertambah dari 00000 sampai 99999
    5 byte alphanumericSequence harus berisi karakter alfanumerik [0-9][A-Z]. Sequence bisa bertambah dari 00000 ke ZZZZZ
    2 byte country code, 3 byte numericSequence harus dimulai dengan 2 byte kode negara (contoh: ID). bytes lainnya bisa berupa nomor yang dimulai dari 000 - 999
    2 byte country code, 3 byte alphanumericSequence harus dimulai dengan 2 byte kode negara (contoh: ID). bytes lainnya bisa berupa alfanumerik yang dimulai dari 000 - ZZZ
     
  • Key Sequence (diamkan saja)
    Key Sequence ini digunakan dalam referensi pemegang sertifikat dari sebuah sertifikat EAC CVC atau permintaan sertifikat. Sesuai dengan spesifikasi BSI, panjang sequence ini haruslah 5 bytes. Nilai awal harus ditulis dalam field yang sudah disediakan. Sequence boleh dimulai dengan standar ISO 3166-2 (kode negara).
    Untuk CA dengan tipe X509, Key Sequence ini tidaklah terlalu penting, kecuali untuk labeling  ketika memperbarui kunci. Jika kalian tidak yakin dengan key sequence ini, tinggalkan saja dan biarkan ditangani secara otomatis oleh EJBCA.
Directive
  • Enforce Unique Public Keys
    Enforce Unique Public Keys memastikan sertifikat dengan kunci publik yang sama hanya dapat dikeluarkan untuk user yang sama dari CA ini. Artinya seorang user diizinkan memiliki banyak sertifikat (contoh: karena pembaruan) dengan key yang sama selama username yang sama digunakan. Namun 2 user tidak bisa berbagi kunci publik yang sama. Saat opsi ini dipilih, maka hanya akan dijalankan ketika sertifikat baru dikeluarkan.
    Untuk menggunakan fitur ini secara efektif, kalian harus punya sebuah database index (subjectKeyId,issuerDN)pada tabel CertificateData
  • Enforce Unique DN
    Enforce Unique DN memastikan user dengan SubjectDN yang sama tidak bisa diterbitkan sertifikatnya dari CA ini. Ini artinya seorang user diizinkan untuk memiliki banyak sertifikat (contoh: untuk tujuan yang berbeda) dengan SubjectDN yang sama selama username-nya sama, tapi 2 user tidak bisa berbagi SubjectDN yang sama.
    Pemeriksaan hanya berdampak pada pengguna baru. Misalkan kalian memiliki 2 user yang sama sebelum mengaktifkan fitur ini, maka user yang lama tetap dapat berbagi DN dan mendapatkan sertifikat baru.
    Untuk menggunakan fitur ini secara efektif, kalian harus punya sebuah database index (subjectKeyId,issuerDN)pada tabel CertificateData
  • Enforce Unique Subject DN Serial Number
    Enforce Unique Subject DN Serial Number memastikan hanya satu entitas dengan spesifik Subject DN Serial Number dapat diterbitkan dari CA ini. Ketika menambahkan entitas baru, pemeriksaan dilakukan untuk memastikan tidak ada entitas lainnya, yang dikeluarkan oleh CA ini sebelumnya, memiliki Subject DN SerialNumber yang sama. Catatan, entitas yang dikeluarkan dari CA lain bisa memiliki Subject DN SerialNumber yang sama dengan yang dikeluarkan dari CA ini.
    *catatan: opsi ini sangat tidak efisien dan hanya akan bekerja bila jumlah user sangat sedikit, ratusan atau beberapa ribu. Hal ini karena CA akan memeriksa semua entitas yang pernah diterbitkan terlebih dahulu ke dalam databse sebelum sertifikatnya diterbitkan.
  • Use Certificate Request History
    Use Certificate Request History menyimpan nilai-nilai yang digunakan saat membuat sertifikat untuk sebuah entitas. Karena nilai-nilai dari entitas, seperti DN, bisa diedit saat membuat request, fungsi ini memastikan ada kemungkinan untuk menyusuri jejak dari nilai yang digunakan untuk mengeluarkan sertifikat tertentu.
    Informasi yang disimpan adalah fingerprint, serialNumber, issuerDN, username, timestamp, UserDataVO.
    Secara default, Certificate Request History dinonaktifkan pada versi 6.0 ke atas. Mengaktifkan fitur ini akan mengurangi performa dan menggunakan banyak space di database. Jika kalian merasa perlu menggunakan fitur ini, pertimbangkan untuk mengaudit log-nya juga.
  • Use User Storage (√)
    Sertifikat normalnya dikeluarkan dalam 2 langkah dimana seorang user pertama kali ditambahkan ke database dengan sebuah username, password (atau kode penerbitan), dan informasi tambahan yang harus berada di dalam sertifikat. Kemudian EJBCA memproses sebuah permintaan dimana user tersebut harus diterbitkan sertifikatnya dan kredensial yang disediakan (username dan password) diverifikasi dengan data pengguna yang disimpan.
    Di EJBCA, Admin GUI saat ini hanya bisa untuk mencari user dan bukan sertifikatnya, Jadi tanpa ini diaktifkan, Admin GUI tidak akan terlalu berguna. user storage ini aktif dengan sendirinya secara default. Jika EJBCA digunakan sebagai pabrik sertifikat, dimana fungsionalitas dari Admin GUI tidak terlalu dibutuhkan, user data storage ini bisa di-non-aktifkan untuk meningkatkan performa.
  • Use Certificate Storage (√)
    Sertifikat yang dikeluarkan tersimpan di dalam database untuk memungkinkan penyediaan informasi bila ada permintaan atau juga untuk menyediakan informasi terkait pencabutan. Certificate Storage ini juga bisa di-non-aktifkan di Certificate Profiles. Me-non-aktifkannya membuat sertifikat tidak akan tersimpan.
CA Certificate Data
  • Subject DN
    Subject DN merupakan field yang mengidentifikasi entitas yang berhubungan dengan kunci publik yang tersimpan di dalam sertifikat. Subject DN bisa berisi sebuah nomor yang sudah terstandarisasi, seperti:
    FieldDeskripsi
    Sertifikat tanda tangan digital personalCN=Firstname Lastname, SURNAME=Lastname, GIVENNAME=Firstname, SERIALNUMBER=213243-1234, C=ID
    Sertifikat untuk login sebuah organisasiCN=Firstname Lastname, UID=firstnamelastname, OU=Finance, O=Organization, C=ID
    Sertifikat Web ServerCN=www.domainlo.com
    Sertifikat Web Server (EV)SERIALNUMBER=5566283064,OU=Infra, O=Training Aja AB,POSTALCODE=17163, STREETADDRESS=Lundagatan 16, BUSINESSCATEGORY=Private Organization, L=Solna,jurisdictionCountry=ID, C=ID
    Sertifikat untuk perangkat IoTCN=DeviceID

    Untuk melihat semua komponen DN yang standar di dalam EJBCA, kalian bisa buka src/java/dncomponents.properties.sample 
  • Signed By (Self Signed)
    Karena ini merupakan Root CA, maka yang menandatangani sertifikatnya adalah dirinya sendiri. Oleh sebab itu, pada bagian ini, pilihlah self signed.
  • Certificate Profile (ROOTCA)
    Karena ini adalah Root CA, kalian bisa menggunakan Certificate Profile yang sudah dibuat oleh EJBCA bernama ROOTCA.
  • Validity (15y)
    Masa aktif dari Root CA ini
  • Certificate Policy OID
    Mengatur Certificate Policy ID ketika membuat CA akan mempengaruhi ekstensi Certificate Policy yang ada di dalam sertifikat CA. Kalian bisa mengatur Certificate Policy ID di CA Settings, Certificate Profile ataupun keduanya.
    Saat sebuah CA dibuat, Certificate Policy ID yang ada di pengaturan CA dan yang ada di Certificate Profile akan digabungkan. Maka dari itu, agar tidak membingungkan, lebih baik Certificate Policy ID ini diatur pada Certificate Profile saja
  • Use UTF-8 in Policy Notice Text (√)
  • PrintableString encoding in DN (√)
  • LDAP DN Order (√)
CRL Spesific Data
  • Authority Key ID (√)
  • CRL Number (√)
  • Issuing Distribution Point on CRLs (√)
    Mengaktifkan ini akan menempatkan default CRL Dist. Point ke dalam ekstensi Issuing Distribution Point di CRL yang dihasilkan. Menurut RFC5280, ekstensi CRL harus critical. 
  • Keep Expired Certificates on CRL
    Pengaturan ini mengatur apa yang terjadi dengan sertifikat kadaluwarsa yang sudah dicabut. Secara default, ini di-non-aktifkan dan hanya diaktifkan untuk kasus yang sangat jarang.
    Bila fitur ini diaktifkan, maka sertifikat yang sudah kadaluwarsa akan tesimpan di dalam CRL dan menambah besar file CRL yang utamanya berisi daftar sertifikat yang dicabut. Hati-hati dalam menggunakan fitur ini karena ukuran CRL kalian bisa membesar secara signifikan.
  • CRL Period
    Berikut ini pengaturan dari sebuah CA ketika sebuah CRL dihasilkan:
    FieldDeskripsiMandatori
    CRL Expire PeriodPeriode validitas untuk CRL yang dihasilkan. Contoh, jika kalian mengisi 24 jam, maka update berikutnya untuk generate CRL baru adalah waktu penerbitan + 24 jamYa
    CRL Issue IntervalInterval tetap ketika CRL dikeluarkan. Jika diatur misalkan 1 jam, CRL baru akan dikeluarkan setiap jam, meskipun yang lama masih berlaku selama 23 jam, sesuai dengan CRL overlap time 23 jam. Nilai defaultnya adalah 0, yang berarti CRL baru akan dikeluarkan ketika yang lama berakhir. Membuat nilainya 0 memiliki efek yang sama dengan nilai yang ada pada CRL Expire PeriodTidak
    CRL Overlap TimeCRL yang baru akan dikeluarkan dalam jumlah waktu yang ditetapkan ini sebelum CRL lama berakhir. Nelai default adalah 10 menit, yang artinya jika CRL Expire Period adalah 24 jam, CLR baru akan dikeluarkan setelah 23 jam 50 menitTidak
    Delta CRL PeriodPeriode validitas untuk delta CRL yang dihasilkan jika delta CRL dikeluarkan. Delta CRL hanya dikeluarkan jika nilai ini lebih dari 0Tidak

    Kalian hanya perlu menentukan antara CRL Issue Interval atau CRL Overlap Time (meskipun memungkinkan untuk mengatur keduanya). Nilai default memastikan tidak ada time period ketika tidak ada CRL valid yang dikeluarkan, dan memberikan klien jeda waktu 10 menit untuk mengunduh CRL baru sebelum yang lama berakhir. Jika kalian ingin memperbesar jeda waktu, kalian antara mengurangi CRL Issue Interval atau meningkatkan CRL Overlap Time.
CA Defined Validation
  • Default CRL Distribution Point (Generate)
    Link untuk mengunduh CRL yang diterbitkan oleh CA tersebut
  • Default CRL Issuer (Generate)
    Yang mengeluarkan CRL
  • OCSP Service Default URI (Generate)
    Link untuk memeriksa status sertifikat secara online.
Bagian terakhir
  • CMS Service (√)
    Menurut Gartner, CMS merupakan sebuah perangkat lunak yang digunakan untuk menemukan, mengidentifikasi, melacak, memberitahu, dan pada akhirnya secara otomatis memperbarui dan mengaudit instalasi sertifikat X.509
    Ada 4 fungsionalitas yang ditawarkan EJBCA sebagai CMS yaitu kepemilikan sertifikat, pelaporan sertifikat, provisi sertifikat dan validasi sertifikat.
  • Finish User (√)
    Konfigurasi Finish User ini menentukan jika sebuah CA memanggil sebuah proses yang disebut “finishuser” setelah sebuah sertifikat dikeluarkan untuk sebuah entitas akhir.
    Dengan diaktifkannya fitur ini, password entitas akhir hanya bisa digunakan 1x (atau sebanyak yang diizinkan dalam pengaturan “Number of allowed device” ketika menambahkan entitas akhir) untuk menerbitkan sertifikat. Setelah sertifikat terakhir diterbitkan, status user akan berubah menjadi “generated” dan password akan kosong. Ketika status menjadi “generated” maka sertifikat baru tidak bisa diterbitkan hingga statusnya berubah kembali menjadi “new”, biasanya dengan mengubah entitas akhirnya.
    Bila di-non-aktifkan, password dapat digunakan tanpa batas untuk menerbitkan sertifikat, dan status akan selalu baru setiap waktu.

    Perlu diingat bahwa password akan tetap kosong untuk token dengan tipe spesifik ketimbang user generated.
  • Monitor if CA active (healthcheck) (√)

3. Membuat Certificate Profile untuk CA

Usai membuat Root CA, sekarang waktunya untuk membuat certificate profile untuk menerbitkan CA, satu tingkat di bawah Root CA. Apa itu certificate profile? Certificate Profile merupakan sebuah template yang digunakan untuk membatasi bentuk dan tujuan dari sebuah sertifikat.

Untuk tujuan ini, hal yang paling mencolok di layar adalah berkaitan dengan tujuan, algoritma kunci, dan ukuran algoritma itu sendiri. Salah satu tujuan utama dari certificate profiles adalah untuk bisa mendefinisikan key usage, yang membatasi tugas apa saja yang bisa dilakukan oleh sebuah pasangan kunci. Certificate profile juga dapat dibatasi hanya bekerja di bawah suatu CA

Untuk membuat certificate profile, silakan masuk ke halaman admin dari EJBCA lalu pilih certificate profiles.

Kalian akan menemukan beberapa profiles yang sudah dibuat oleh EJBCA. Karena ingin membuat profile untuk Root CA yang nantinya akan menandatangani penerbitan sebuah CA, maka clone saja profil ROOTCA dan ubah namanya sesuai dengan yang kalian inginkan, dalam hal ini saya memberi nama Testing Root CA.

Kalau sudah, silakan pilih profile Testing Root CA dan edit.

Copy certificate profile ROOTCA
Ubah namanya sesuai dengan yang kalian inginkan
11 Edit Testing Root CA
Edit Testing Root CA
  • Type (Sub CA)
    Karena akan menerbitkan sertifikat untuk sebuah CA, maka yang perlu dipilih di sini adalah Sub CA.
  • Available Key Algorithms (RSA)
    Daftar dari algoritma yang bisa digunakan oleh kunci publik dalam sebuah permintaan sertifikat
  • Available Bit Lengths (4096 Bits)
    Daftar dari ukuran kunci yang diizinkan untuk digunakan oleh kunci publik dalam sebuah permintaan sertifikat.
  • Signature Algorithm (Inherit from issuing CA)
    Algoritma penandatanganan. Untuk bagian ini, sudah ditangani oleh CA.
  • Validity (10y)
    validitas di sini adalah untuk menentukan tanggal berakhirnya sebuah sertifikat dan bisa dikonfigurasi seperti berikut:
    fixed date dengan ISO8601 dengan format ‘yyyy-MM-dd HH:mm:ssZZ’ contoh ‘2020-06-06 22:20:20+00:00’
    relative time dengan menentukan tahun, bulan, hari, jam, menit dan detik dengan bentuk ‘*y *mo *d *h *m *s’ Contoh: ‘5y-10d’
    Untuk validitas yang bersifat relatif, tanggal berakhirnya sertifikat dihitung dari dimulainya tanggal ditambah dengan nilai yang dimasukkan. Waktu mulai biasanya adalah waktu ketika dikeluarkan
X.509 extensions
  • Basic Constraints (√)(√)
  • Path Length Constraints
    Ekstensi ini hanya bisa diaplikasikan untuk sertifikat immediate CA dan menentukan kedalaman hierarki sertifikat berikutnya. Jika diberikan nilai 0, sertifikat CA ini adalah yang terakhir dalam rantai CA dan hanya bisa menerbitkan sertifikat untuk entitas akhir.
  • Key Usage (√) (√)
    Ekstensi Key Usage menentukan tujuan dari sertifikat ini. Untuk user, biasanya sertifikat dipisahkan untuk tanda tangan digital dan sertifikat untuk enkripsi. Karena ini untuk CA, maka key usage-nya adalah Key Certificate Sign, Digital Signature dan CRL Sign.
  • Extended Key Usage
    Ini merupakan fungsi tambahan dan lebih spesifik. Tulisan lengkap mengenai key usage dan extended key usage bisa dibaca DI SINI.
  • Certificate Policies
    Certificate Policies menunjukkan kebijakan mana yang dikeluarkan sertifikat dengan profil ini. Certificate Policy biasanya ditulis dalam bentuk OID
  • Issuer Alternative Name
    Menggunakan Issuer Alternative Name berarti menduplikasi nilai Subject Alternative Name dari CA yang mengeluarkan sertifikat dan meletakkannya di dalam sertifikat yang dikeluarkan.
    Sebagai contoh. Gunakan Issuer Alternative Name untuk sebuah CA dengan Subject Alternative Name “[email protected]” dan memasukkannya ke dalam sertifikat CA. Jika kalian mengaktifkan Issuer Alternative Name di dalam certificate profile yang digunakan untuk mengeluarkan sertifikat bagi entitas akhir, sertifikat entitas akhir tersebut akan mendapat Issuer Alternative Name [email protected]” .
(masih) extension
  • CRL Distribution Points (√) (√)
    Ekstensi CDP ini menyediakan informasi bagi klien yang ingin memverifikasi sebuah sertifikat. Nilainya adalah sebuah URI yang mengarah ke sebuah CRL yang bisa digunakan untuk memeriksa jika sertifikat telah dicabut. CRL dikeluarkan oleh CA. Karena sudah didefinisikan di CA, maka pilih “Use CA defined CDP” dan ini dan biarkan CRL didapat dari CA yang mengeluarkannya.
  • Freshest CRL
    Freshest CRL atau yang biasa juga disebut Delta CDP digunakan untuk Delta CRLs. Karena tidak menggunakan Delta CRL, ini bisa diabaikan saja.
  • Authority Information Access (√)
    Sama halnya seperti CDP, hanya saja dalam Authority Information Access ini yang diaktifkan adalah OCSP (Online Certificate Status Protocol). Karena sudah diurus oleh CA yang mengeluarkan, maka pilih “Use CA defined OCSP Locator” agar menyerahkannya kepada CA.
  • Private Key Usage Period
    Ekstensi ini dijelaskan pada RFC 3280. EJBCA menghitung komponen ekstensi notBefore dan notAfter berdasarkan waktu dikeluarkannya sebuah sertifikat dan nilai Start offset dan Period Length dengan formula:
    notBefore = cert.notBefore + startOffset
    notAfter = notBefore + periodLength
Other Data
  • LDAP DN Order (√)
    Dalam sebuah sertifikat, urutan komponen DN (CN,O,OU, dll) bisa diletakkan dengan urutan yang berbeda. Yang pertama adalah last-to-first atau dalam sejarah EJBCA disebut LDAP DN Order. (CN, O, OU)
    Yang kedua adalah first-to-last atau kebalikan dari yang pertama. (OU, O, C)
    Ketika menggunakan string yang direpresentasikan di DN, urutan sebenarnya tidak ditampilkan, tapi tool yang digunakan akan menampilkan urutannya. Gunakanlah asn1 parsing tool, seperti OpenSSL untuk melihatnya.
  • Subset of Subject DN
    Dengan menggunakan subset of subject DN dalam sebuah sertifikat, kalian bisa mendaftarkan user dengan lebih banyak informasi daripada yang ada dalam sertifikat yang dikeluarkan. Contoh:
    Gunakan subset of subject DN dalam certificate profile dengan memilih CN, O, dan C. Jika sudah, daftarkan sebuah entitas dengan nilai “CN=Darius, O=dailyvoyagers, C=ID” dan pilih certificate profile yang sudah diaktifkan subset of subject DN-nya. Selanjutnya, terbitkan sertifikatnya. Sertifikat yang dikeluarkan akan terdiri dari DN “CN=Darius, O=dailyvoyagers, C=ID”.
    Catatan: Jangan menggunakan fitur ini ketika mengeluarkan sertifikat untuk CA.
  • Available CAs (Testing Root CA)
    Karena akan menerbitkan sertifikat untuk CA, maka kalian harus memilih Root CA “Testing Root CA” yang sudah dibuat sebelumnya.

4. Membuat Sebuah CA/SubCA

Prosesnya hampir sama seperti membuat Root CA. Kembali masuk ke halaman adminstrator EJBCA lalu pilih Certification Authority. Tuliskan nama Root CA yang kalian inginkan pada field Add CA dan setelah itu tekan tombol Create. Kalian akan diarahkan untuk membuat pengaturan pada CA.

Membuat CA
  • CA Type (X509)
  • Crypto Token (Darius Testing CA)
    Karena usdah mendefinisikan crypto token untuk CA, maka gunakanlah crypto token tersebut, dalam hal ini adalah “Darius Testing CA”. Untuk Key yang perlu digunakan, silakan dipilih sendiri ya (defaultKey, certSignKey, dll).
  • Extended Key Spesification (RSA 4096)
    Samakan saja seperti milik Root CA.
  • Key Sequence Format (Alphanumeric [0-9][A-Z])
Lanjutan membuat CA
  • Use User Storage (√)
  • Use Certificate Storage (√)
  • Subject DN (CN=Testing CA)
  • Signed By (Testing Root CA)
    Karena sertifikat ini adalah untuk sebuah CA, yang ditandatangani oleh sebuah Root CA, maka kali ini kalian akan memilih untuk ditandatangani oleh Root CA yang sudah kalian buat, dalam hal ini adalah Testing Root CA.
  • Certificate Profile (Testing Root CA)
    Sama seperti signed by, sekarang kalian pun harus menggunakan certificte profile yang sudah dibuat sebelumnya, dalam hal ini adalah Testing Root CA.
  • Validity (10y)
    Untuk validitas ini, buatlah lebih rendah dari Root CA.
  • Use UTF-8 in policy notice text (√)
  • PrintableString encoding in DN (√)
  • LDAP DN Order (√)
CRL Spesific Data
  • Authority Key ID (√)
  • CRL Number (√)
  • Issuing Distribution Point on CRLs (√)
  • Default CRL Distribution Point (Generate)
    Link untuk mengunduh CRL yang diterbitkan oleh CA tersebut
  • Default CRL Issuer (Generate)
    Yang mengeluarkan CRL
  • OCSP Service Default URI (Generate)
    Link untuk memeriksa status sertifikat secara online.
Approval
  • CMS Service (√)
  • Finish User (√)
  • Monitor if CA active (healthcheck) (√)

5. Membuat Certificate Profile untuk End Entity

Usai membuat CA, sekarang adalah waktunya untuk membuat certificate profile yang digunakan untuk menerbitkan sertifikat bagi end entity. Masuk ke halaman administrator dari EJBCA dan pilih Certificate Profiles. EJBCA sudah menyediakan profil untuk sebuah CA bernama SUBCA. Silakan pilih clone dan rename dengan nama yang kalian suka, dalam hal ini saya memberi nama Testing CA dan setelah itu edit.

Membuat Certificate Profile Testing CA
Cert Profile untuk CA
  • Type (End Entity)
    Karena ini digunakan untuk menandatangani sebuah entitas akhir, maka tipe yang dipilih adalah End Entity.
  • Available Key Algorithms (RSA)
  • Available Bit Lengths (2048 Bits)
  • Signature Algorithm (Inherit from issuing CA)
  • Validity (1y)
field lainnya
  • Basic Constraints (√)(√)
  • Key Usage (√) (√)
    Ekstensi Key Usage menentukan tujuan dari sertifikat ini. Untuk user kali ini, pilih digital signature dan non repudiation.
  • Certificate Policies
    Certificate Policies menunjukkan kebijakan mana yang dikeluarkan sertifikat dengan profil ini. Certificate Policy biasanya ditulis dalam bentuk OID
  • CRL Distribution Points (√) (√)
    Ekstensi CDP ini menyediakan informasi bagi klien yang ingin memverifikasi sebuah sertifikat. Nilainya adalah sebuah URI yang mengarah ke sebuah CRL yang bisa digunakan untuk memeriksa jika sertifikat telah dicabut. CRL dikeluarkan oleh CA. Karena sudah didefinisikan di CA, maka pilih “Use CA defined CDP” dan ini dan biarkan CRL didapat dari CA yang mengeluarkannya.
  • Authority Information Access (√)
    Sama halnya seperti CDP, hanya saja dalam Authority Information Access ini yang diaktifkan adalah OCSP (Online Certificate Status Protocol). Karena sudah diurus oleh CA yang mengeluarkan, maka pilih “Use CA defined OCSP Locator” agar menyerahkannya kepada CA.
Other Data
  • LDAP DN Order (√)
  • Available CAs (Testing CA)
    Karena akan menerbitkan sertifikat untuk End Entity, maka kalian harus memilih CA “Testing CA” yang sudah dibuat sebelumnya.
  • Single Active Certificate Constraint (√)

6. Membuat End Entity Profile

Sekarang adalah waktunya membuat profil yang akan digunakan untuk menerbitkan sertifikat bagi entitas akhir. End Entity Profile merupakan sebuah template untuk Subject DN bagi sebuah entitas akhir dengan cara mendefinisikan field mana saja yang harus ada, bisa diubah atau wajib ada.

Bagian ini juga berisi informasi yang spesifik untuk setiap individu di entitas akhir. End Entity Profiles juga bisa digunakan untuk membatasi akses ke certificate profiles yang spesifik untuk menerbitkan sertifikat untuk end entities. 

Masuk ke halaman administrator dari EJBCA, lalu arahkan ke RA Functions dan pilih End Entity Profiles. Pada bagian Add Profile, ketik nama profil yang kalian inginkan dan kemudian tekan tombol add. Dalam hal ini namanya adalah LTV Testing.

End Entity Profile
End Entity Profile
  • Username
    Username merupakan unique identifier untuk sebuah entitas akhir (user, server, device, dll). Memilih Auto-generated checkbox berarti akan menghasilkan nilai yang unik ketika entitas akhir ditambahkan.
  • Password
    Password digunakan ketika seorang user meminta sebuah sertifikat dan atau ketika men-generate sebuah keystore. Ini sangat diperlukan dan tidak ada nilai default yang dikonfigurasikan di sini. Ketika password hanya digunakan selama prosesur request, ini disebut enrollment code, karena password hanya valid 1x dan tidak digunakan untuk mengamankan key. Tidak ada perbedaan antara enrollment code dan password. Itu hanya perbedaan nama saja.
    Kalian bisa menggunakan fitur auto-generation dengan pemberitahuan via email yang akan dikirimkan kepada user tentang bagaimana cara mengunduh sertifikat dan password yang dibuat secara otomatis.
    Kalian juga bisa menentukan bit-strength minimal dari sebuah password yang diizinkan
  • Maximum Number of Failed Login Attempts
    Dengan memilih fitur ini, status user akan berubah menjadi GENERATED jika kata sandi yang dimasukkan salah lebih dari batas yang sudah ditentukan. opsi use haruslah dipilih untuk menggunakan fitur ini. Jika modifiable, nomor yang ditentukan bisa berubah untuk entitas tertentu pada saat waktu pembuatannya.
Subject DN Attributes
  • Subject DN Attributes
    Untuk mengidentifikasi user. Silakan tambahkan field yang kalian inginkanPada contoh kali ini, saya hanya akan menggunakan field CN dan O.
Main Certificate Date
  • Default Certificate Profile (Testing CA)
    Certificate Profile yang otomatis akan diaplikasikan untuk menerbitkan sertifikat bagi entitas akhir jika tidak ada perubahan yang dilakukan. Kali ini, kalian akan memilih profil “Testing CA”
  • Available Certificate Profiles (Testing CA)
    Daftar CA yang bisa dipilih untuk diaplikasikan pada End Entity Profile ini. Karena hanya akan menggunakan profil “Testing CA” saja, maka pilihlah profil tersebut saja sehingga saat menambahkan entitas akhir nanti, tidak ada lagi certificate profile lain yang bisa dipilih.
  • Default CA (Testing CA)
    Daftar CA yang akan menandatangani sertifikat untuk entitas akhir yang akan dikeluarkan. Dalam hal ini kalian pilih “Testing CA”
  • Available CAs (Testing CA)
    Daftar CA yang bisa kalian pilih. Namun karena hanya membutuhkan 1 CA saja, pilihlah “Testing CA”
  • Default Token (P12 file)
    Jenis token untuk sertifikat yang akan dikeluarkan. Karena butuhnya adalah file .P12, pilihlah “P12 file”
  • Available Tokens (P12 file)
    Token yang bisa dipilih saat ingin menerbitkan sertifikat untuk entitas akhir. Batasi saja untuk 1 jenis token yaitu P12 file.

7. Menambahkan Entitas Akhir

Semua proses pengaturan sudah selesai. Sekarang waktunya untuk menambahkan entitas akhir. Apa itu entitas akhir? Entitas akhir merupakan pengguna sertifikat PKI dan atau pengguna akhir yang menjadi subjek sertifikat, seperti email klien, web server, web browser, atau gateway VPN.

Untuk menerbitkan sertifikat bagi entitas akhir, masuk ke halaman administrator dari EJBCA dan arahkan pandangan ke RA Functions kemudian pilih Add Entity.

Menambahkan entitas akhir
  • End Entity Profile (LTV Testing)
    Pilih End Entity Profile yang sudah dibuat sebelumnya yaitu “LTV Testing”
  • Username (testing99)
    Masukkan username yang diinginkan.
  • Password (******)
    Masukkan password yang diinginkan. Namun karena sudah diatur 48 bits pada pengaturan di end entity profile, maka password yang harus dimasukkan minimal 8 karakter.
  • Email Address ([email protected])
  • CN (Testing 99)
    Nama pemilik sertifikat
  • O (Testing Department)
    Tempat kerja atau organisasi dari si pemilik sertifikat
  • Certificate Profile (Testing CA)
  • CA (Testing CA)
  • Token (P12 File)
Pemberitahuan jika user berhasil ditambahkan

8. Menerbitkan Sertifikat untuk User

Setelah menambahkan entitas akhir, sekarang waktunya untuk menerbitkan sertifikatnya. Jadi tadi itu belum menerbitkan sertifikat? Belum. Saat menambahkan entitas akhir, statusnya masih new, sedangkan kalau sudah diterbitkan, statusnya akan berubah menjadi generated.

Untuk menerbitkan, masuk ke halaman depan dari EJBCA. Pada bagian Enroll, pilih Create Keystore. Di bagian authentication, masukkan username dan password sesuai dengan yang sudah didaftarkan. Dalam contoh kali ini adalah testing99.

menerbitkan sertifikat untuk user testing99
enroll
Sertifikat berhasil diterbitkan

9. Menandatangani Dokumen Secara Elektronik Menggunakan Sertifikat yang Baru Diterbitkan

Sertifikat sudah terbit, sekarang waktunya melakukan penandatangan dokumen menggunakan sertifikat tersebut pada aplikasi Adobe Acrobat. Silakan pilih file .pdf yang kalian inginkan dan buka dengan menggunakan aplikasi adobe acrobat.

Untuk menempelkan tanda tangan, pilih tools → certificates → digitally sign → configure new digital ID → Use a Digital ID from a file → Browse → Fill the Password → Add Digital ID → Choose Digital ID → Fill the password → sign

file pdf yang dibuka dengan menggunakan aplikasi adobe acrobat reader. Pilih tools
Pilih certificates
Pilih digitally sign
konfigur ID baru
Cari sertifikat
pilih sertifikat
Masukkan password setelah memilih file P12
Add digital ID
Gunakan File
masukkan password dan sign
Berhasil ditandatangani tapi masih ada masalah

Dokumen sudah berhasil ditandatangani. Namun bila melihat gambar di atas, tanda tangannya masih bermasalah. Masalah yang muncul adalah validitas tanda tangan belum bisa dipastikan. Hal ini memang hal yang biasa, sebab certificate dari Root CA yang digunakan untuk menandatangani belum ada di dalam repositori milik adobe alias belum terpercaya. Karena belum ada di dalam repositori, maka proses pemeriksaan tidak bisa dilakukan.

Untuk mengatasi masalah ini, buka signature panel dan klik kanan pada nama penandatanganan. Pilih show signature properties.

Belum ada tulisan “LTV enabled”. Silakan pilih Show Signature Properties

Jika sudah, pilih show signer’s certificate untuk melihat lebih detil mengenai sertifikat milik si penandatanganan. Pada bagian Root CA, pilih tab trust dan kalian akan melihat banyak tanda silang berwarna merah. Di sanalah letak permasalahannya dan itulah yang harus diperbaiki.

Pilih Show signer’s Certificate
Pilih add to trusted certificates

Tambahkan sertifikat ke dalam repositori secara manual dengan cara memilih tombol Add to Trusted Certificates. Selanjutnya, centang semua check box yang ada dan pilih OK

Pilih OK
Centang Semua

Jika sudah, tutup aplikasi adobe acrobat dan lakukan kembali penandatanganan baru pada dokumen yang kalian inginkan. Prosesnya sama persis. Setelah berhasil ditanda tangan, biarkan sertifikat divalidasi oleh adobe dan voilaaa, kalian akan melihat tulisan signature is LTV enabled pada signature panel.

LTV enabled

Itu tadi sedikit informasi mengenai cara membubuhkan tanda tangan elektronik yang mendukung LTV. Semoga informasi mengenai LTV ini bisa berguna ya. Jika masih ada pertanyaan seputar LTV, silakan tanyakan di kolom komentar ya.

Sampai jumpa di tutorial berikutnya 🙂

Please follow and like my page:
error0
fb-share-icon4673
Tweet 419
fb-share-icon20

Leave a Reply

Your email address will not be published. Required fields are marked *