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.
| Field | Deskripsi |
|---|---|
| Name | Hanya sebuah nama untuk Crypto Token |
| Type | PKCS#11 untuk HSM atau Soft PKCS#12 keystore yang berada di database |
| Authentication Code | PIN atau password PKCS#11 yang akan memproteksi soft keystore |
| Repeat Authentication Code | hanya 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 keys | Pilih 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.
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.
- 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.
Field Deskripsi defaultKey Key default yang akan digunakan certSignKey Key yang digunakan untuk mengeluarkan sertifikat. Harus comply dengan algoritma penandatanganan dan hanya pilihan yang valid yang akan ditampilkan crlSignKey Key yang digunakan untuk menandatangani CRL. Meskipun secara teori bisa dipisahkan dari certSignKey menurut RFCs, klien supportnya sangat jarang dan certSignKey lebih sering digunakan keyEncryptKey Key yang digunakan untuk key recovery bila memang diaktifkan. Kunci untuk dekripsi di-escrow dan harus RSA hardTokenEncrypt Deprecated. Sudah tidak dipakai testKey Key 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:
Field Deskripsi 5 byte numeric Sequence harus berisi karakter numerik [0-9]. Sequence bisa bertambah dari 00000 sampai 99999 5 byte alphanumeric Sequence harus berisi karakter alfanumerik [0-9][A-Z]. Sequence bisa bertambah dari 00000 ke ZZZZZ 2 byte country code, 3 byte numeric Sequence 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 alphanumeric Sequence 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.
- 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.
- 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:
Field Deskripsi Sertifikat tanda tangan digital personal CN=Firstname Lastname, SURNAME=Lastname, GIVENNAME=Firstname, SERIALNUMBER=213243-1234, C=ID Sertifikat untuk login sebuah organisasi CN=Firstname Lastname, UID=firstnamelastname, OU=Finance, O=Organization, C=ID Sertifikat Web Server CN=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 IoT CN=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 (√)
- 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:
Field Deskripsi Mandatori CRL Expire Period Periode validitas untuk CRL yang dihasilkan. Contoh, jika kalian mengisi 24 jam, maka update berikutnya untuk generate CRL baru adalah waktu penerbitan + 24 jam Ya CRL Issue Interval Interval 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 Period Tidak CRL Overlap Time CRL yang baru akan dikeluarkan dalam jumlah waktu yang ditetapkan ini sebelum CRL lama berakhir. Nilai default adalah 10 menit, yang artinya jika CRL Expire Period adalah 24 jam, CRL baru akan dikeluarkan setelah 23 jam 50 menit Tidak Delta CRL Period Periode validitas untuk delta CRL yang dihasilkan jika delta CRL dikeluarkan. Delta CRL hanya dikeluarkan jika nilai ini lebih dari 0 Tidak
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.
- 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.
- 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.
- 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
- 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 “rfc822Name=ca@org.org” 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 “rfc822Name=ca@org.org” .
- 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
- 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.
- 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])
- 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 (√)
- 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.
- 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.
- 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)
- 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.
- 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.
- 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
Untuk mengidentifikasi user. Silakan tambahkan field yang kalian inginkan. Pada contoh kali ini, saya hanya akan menggunakan field CN dan O.
- 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.
- 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 (testing99@gmail.com)
- 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)
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.
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
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.
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.
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
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.
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 🙂
Comments are closed.