Salah satu kegunaan Import Certificates adalah untuk migrasi data. Ada 2 cara untuk melakukan Import Certificates, yang pertama adalah dengan cara satuan dan yang kedua adalah secara bersamaan.

Import Single Certificate (satuan)

Perintah yang digunakan untuk import certificates secara satuan adalah:

• Mandatori

bin/ejbca.sh ca importcert --username <username> --password <password> --caname <nama CA> -a <status> -f <file certificate>

• Versi lengkap (ada tambahan parameter opsional)

bin/ejbca.sh ca importcert <username> <password> <Nama CA> <status> --email <email> <File Certificate> \[--eeprofile <End Entity Profile>\] \[--certprofile <Certificate Profile>\] \[--revocation-reason <Alasan Revoke>\] \[--revocation-time <Waktu revoke>\]

Berikut ini penjelasan mengenai beberapa parameter yang ada pada perintah di atas:

1. Username
   Username dari entitas akhir yang merupakan pemilik dari sertifikat. Jika entitas akhir tersebut belum ada, maka sertifikatnya akan dibuat secara otomatis. Jika entitas akhirnya sudah ada, sertifikat yang diimport akan berasosiasi dengan yang sudah ada, dan properti-properti yang ada (subject, subject alternative names) akan di-update.
2. Password
   Password yang akan diatur untuk entitas akhir ini. (Pada versi GUI, bagian ini biasa disebut dengan enrollment code)
3. Nama CA
   Nama dari CA yang sudah mengeluarkan sertifikat.  Signature dari CA yang mengeluarkan sertifikat ini akan diverifikasi dengan CA yang ada. Jika signaturenya tidak cocok, sertifikat tidak akan diimport. CA Certificate harus ada di dalam database (Paling tidak statusnya sebagai external CA) 
4. StatuscEmail
5. Email dari si entitas akhir. Jika email ini isinya string null, maka akan diambil dari email yang ada di dalam sertifikat.
6. File Certificate
   File Encoded PEM (BASE 64) dari entitas akhir (file PEM-nya).
7. End Entity Profile
   End Entity Profile yang ada di sini adalah End Entity Profile untuk sertifikat yang akan diimport, buka End Entity Profile dari CA dimana entitas akhir itu diekspor. Setiap atribut dari certificate yang akan diimport akan diverifikasi oleh End Entity Profile Existing. Jika ada atribut yang tidak terseda pada End Entity Profile, maka sertifikat tidak akan bisa diimport. Jika End Entity Profile tidak ditulis pada proses impor, maka End Entity Profile EMPTY (bawaan EJBCA) yang akan digunakan.
8. Certificate Profile
   Mirip seperti End Entity Profile, hanya saja profil di sini adalah untuk CA. Sekali sertifikat berhasil diimport, sertifikat tersebut akan ditandai sebagai milik dari Certificate Profile yang sudah ditetapkan. Jika tidak disertakan dalam perintah, maka Certificate Profile yang akan dipilih adalah ENDUSER (bawaan EJBCA).
9. Alasan Revoke
   Parameter ini ada untuk mengizinkan sertifikat yang sudah di-REVOKED tetap bisa diimport (dengan alasan pencabutannya). Gunakan perintah –help untuk melihat list alasan yang bisa digunakan. Jika tidak disertakan pada perintah di atas, UNSPECIFIED akan ditetapkan sebagai alasannya.
10. Waktu Revoke
    Untuk mengizinkan sertifikat yang sudah di-REVOKED agar tetap bisa diimport dengan waktu pencabutan yang spesifik (format yyyy.MM.dd-HH:mm). Jika tidak disertakan, maka waktu sekaranglah yang akan digunakan.

 Langsung saja saya berikan contoh dari penggunaan command importcert.

sh bin/ejbca.sh ca importcert t.mac hou1 CA ACTIVE --email t.mac@gmail.com /home/jboss/shell/Tracy\ McGrady.pem --eeprofile Person --certprofile tutorial

Pada perintah di atas, saya mencoba untuk mengimport sertifikat bernama Tracy Mcgrady.pem dengan detil:

• Username = t.mac
• Password = hou1
• Nama CA = CA
• Status = Active
• Email = t.mac@gmail.com
• File Certificate = /home/jboss/shell/Tracy\ McGrady.pem
• End Entity Profile = Person
• Certificate Profile = tutorial

Catatan:

• Jika menjalankan perintah (command) di atas tanpa ada parameter apapun, maka panduan penggunaan perintah tersebutlah yang akan muncul (lengkap dengan parameternya seperti caname, status, endentityprofile dan certificateprofile).
• Pastikan kalau Signature CA dari Cert yang akan kita impor itu sama, kalau tidak maka proses impor akan gagal.
• Pastikan nama Profile sudah benar dan atribut-atribut yang ada di dalam profile tersebut sudah terpenuhi semua syaratnya. Jika belum sama dan terpenuhi, maka proses impor akan gagal.

Baca juga: Instalasi EJBCA 6.10.1.2 dengan HSM Luna 7 pada CentOS 7 

Import Certificates in Bulk (Bersamaan)

Untuk mengimport banyak sertifikat secara bersamaan, jalankan perintah berikut:

• Mandatory

bin/ejbca.sh ca importcertdir --filter <filter> --caname <Nama CA> -a <status> --dir <lokasi sertifikat> --eeprofile <End Entity Profile> --certprofile <Certificate Profile>

• Versi Lengkap (ada tambahan parameter opsional)

bin/ejbca.sh ca importcertdir <username-source> <Nama CA> <status> <lokasi sertifikat> --eeprofile <End Entity Profile> --certprofile <Certificate Profile> \[-resumeonerror\] \[--revocation-reason <Alasan Revoke>\] \[--revocation-time <Waktu Revoke>\]

Berikut ini penjelasan mengenai beberapa parameter yang ada pada perintah di atas:

1. username-source atau filter
   Parameter ini digunakan untuk memperoleh username dari entitas akhir yang akan memiliki sertifikat tersebut. Karena kita akan mengimpor banyak sertifikat sekaligus, maka tidak mungkin menentukan username-nya satu per satu. Untuk itulah digunakan parameter ini. Nilai yang tersedia untuk parameter ini adalah FILE, DN, CN.
   Jika CN yang dipilih, username akan sama dengan atribut common name  yang ada di subjek sertifikat.
   Jika DN yan dipilih, username akan sama dengan seluruh distinguished name (subjek) yang ada pada sertifikat.
   Jika FILE yang dipilih, username akan sama dengan dengan nama file dari sertifikat.
   Jika CN yang dipilih namun CN tidak ada dalam subjek sertifikat, proses impor akan kembali ke belakang dan menggantinya dengan DN. Jika DN juga tidak tersedia, username akan diambil dari nama file.
   Jika DN yang langsung dipilih namun DN tidak ada dalam subjek sertifikat, proses impor akan mundur dan menggantinya dengan nama FILE.
2. Nama CA
   Nama dari CA yang sudah mengeluarkan sertifikat.  Signature dari CA yang mengeluarkan sertifikat ini akan diverifikasi dengan CA yang ada. Jika signaturenya tidak cocok, sertifikat tidak akan diimport. CA Certificate harus ada di dalam database (Paling tidak statusnya sebagai external CA) 
3. Status
   Nama dari CA yang sudah mengeluarkan sertifikat.  Signature dari CA yang mengeluarkan sertifikat ini akan diverifikasi dengan CA yang ada. Jika signaturenya tidak cocok, sertifikat tidak akan diimport. CA Certificate harus ada di dalam database (Paling tidak statusnya sebagai external CA) 
4. Lokasi Sertifikat
   Path dari lokasi folder yang berisi file-file sertifikat yang ingin diimport. Setiap filenya harus berisi single certificate. Folder tidak boleh berisi subfolder atau file yang bukan sertifikat.
5. End Entity Profile
   End Entity Profile yang ada di sini adalah End Entity Profile untuk sertifikat yang akan diimport, buka End Entity Profile dari CA dimana entitas akhir itu diekspor. Setiap atribut dari certificate yang akan diimport akan diverifikasi oleh End Entity Profile Existing. Jika ada yang subjek pada sertifikat yang tidak cocok, maka file tersebut tidak akan diimpor.
6. Certificate Profile
   Mirip seperti End Entity Profile, hanya saja profil di sini adalah untuk CA. Sekali sertifikat berhasil diimport, sertifikat tersebut akan ditandai sebagai milik dari Certificate Profile yang sudah ditetapkan.
7. Resumeonerror
   Opsi ini bisa digunakan untuk memaksa proses impor tetap dapat terus berjalan meskipun ada error serius yang terjadi. Secara default, opsi ini tidak diaktifkan. Error yang ditangani oleh opsi ini beberapa diantaranya adalah pelanggaran pada End Entity Profile, masalah dengan parsing sertifikat, dll.
8. Alasan Revoke
   Parameter ini ada untuk mengizinkan sertifikat yang sudah di-REVOKED tetap bisa diimport (dengan alasan pencabutannya). Gunakan perintah –help untuk melihat list alasan yang bisa digunakan. Jika tidak disertakan pada perintah di atas, UNSPECIFIED akan ditetapkan sebagai alasannya.
9. Waktu Revoke
   Untuk mengizinkan sertifikat yang sudah di-REVOKED agar tetap bisa diimport dengan waktu pencabutan yang spesifik (format yyyy.MM.dd-HH:mm). Jika tidak disertakan, maka waktu sekaranglah yang akan digunakan.

Langsung saja saya berikan contoh dari penggunaan command importcertdir.

sh bin/ejbca.sh ca importcertdir --filter FILE --caname CA -a ACTIVE --dir /home/jboss/cert --eeprofile Person --certprofile tutorial

Pada perintah di atas, saya mencoba untuk mengimport 4 sertifikat (s.curry.pem, k.bryant.pem, d.wade.pem, Tracy McGrady.pem) dari folder /home/jboss/cert dengan detil:

• filter = FILE
• Nama CA = CA
• Status = ACTIVE
• Lokasi Sertifikat = /home/jboss/cert
• End Entity Profile = Person
• Certificate Profile = tutorial

Catatan:

• Entitas akhir akan langsung terimpor apabila memang entitas tersebut belum ada. Jika Entitas akhir sudah ada, sertifikat yang diimport akan berasosiasi dengannya dan properties-nya akan diupdate.
• Jika menjalankan perintah (command) di atas tanpa ada parameter apapun, maka panduan penggunaan perintah tersebutlah yang akan muncul (lengkap dengan parameternya seperti username-source, status, endentityprofile dan certificateprofile)
• Sertifikat yang sudah ada di dalam database akan di-skip selama proses import. 
• Sertifikat yang CA-nya berbeda dari yang dispesifikasikan akan di-skip juga.
• Ketidaksesuaian lainnya seperti invalid format, adanya subdirectory, subjek yang tiak sesuai, akan menghentikan proses impor kecuali perintah –resumeonerror dimasukkan.
• Sertifikat yang sudah diimpor sebelum terjadinya ketidaksesuaian pada file berikutnya akan tetap tersimpan pada database. 

Baca juga: Cara Mengelola CA pada EJBCA 6.10.1.2

• Untuk setiap sertifikat yang di-skip, hasil keluaran akan menyebutkan serial number dan nama file-nya. Informasi file yang error pun akan ditampilkan juga.
• Saat proses impor sudah selesai, rangkuman singkat mengenai sertifikat yang berhasil diimpor, sertifikat yang sudah ada (redundant), dan sertifikat yang ditolak (yang tidak di sign oleh CA yang diminta) akan muncul.
• Tidak akan ada rangkuman yang akan ditampilkan jika abnormal error terjadi (seperti apapun kecuali yang sudah disebutkan di atas), kecuali kalian menyertakan paramete -resumeonerror
• Jika menggunakan -resumeonerror, import file akan berlanjut sampai semua file sertifikat dari dalam direktori diproses. Pesan error akan ditampilkan dan rangkuman akan berisi informasi tambahan seperti:
  • Jumlah sertifikat yang tidak bisa dibaca (karena salah format atau bentuknya dalam direktori lagi)
  • Jumlah sertifikat yang subjek end entity profilenya tidak sesuai (salah nilai untuk non-modifiable, dll)
  • Jumlah sertifikat yang tidak bisa dibaca karena error lainnya.

Ya, itu tadi sedikit informasi mengenai cara melakukan import certificates pada EJBCA 6.10.1.2. Semoga informasi mengenai import certificates tadi bisa bermanfaat buat kalian ya.

Sampai jumpa di postingan selanjutnya

Sumber: EJBCA Docs

The post Import Certificates pada EJBCA 6.10.1.2 first appeared on GoBlog.

Dalam bebarapa keadaan, melakukan backup terhadap CA Signature Keys dan Encryption Keys adalah hal yang cukup bijak. Namun ada satu hal yang perlu diingat saat melakukan backup CA Keys, yaitu lindungilah kunci tersebut sama seperti kita melindungi CA itu sendiri.

Soft token CA bisa diekspor dan di-backup secara langsung melalui EJBCA, tapi tidak dengan CA yang menggunakan HSM (Hardware Security Module). Untuk mengekspor kunci pada CA yang menggunakan HSM maka proses backup harus dilakukan melalui HSM.

Ada 2 cara untuk mengimpor EJBCA yaitu dengan CLI (Command Line Interface) dan GUI (Graphical User Interface), sementara HSM hanya bisa diimpor dengan menggunakan CLI.

Menggunakan CLI (Ekspor)

Untuk mengekspor sebuah CA dengan nama imporCA menjadi file PKCS#12 bernama /home/imporCA.p12 , jalankan perintah berikut di direktori $EJBCA_HOME:

$ sh bin/ejbca.sh ca exportca imporCA /home/jboss/imporCA.p12
Setting SignatureKeyAlias to SignatureKeyAlias
Setting EncryptionKeyAlias to EncryptionKeyAlias
Enter keystore password:

• Jika Password belum diubah, isi dengan foo123

Apabila menemukan error seperti ini, maka ada perubahan yang harus dilakukan pada crypto token yang ada pada CA Funtions:

• Error ini menandakan kalau private keys CA tidak diizinkan untuk diekspor

Untuk membenahinya, masuk ke CA Functions →Crypto Tokens & pilih Crypto Token yang digunakan oleh CA tersebut. Pada contoh kali ini, imporCA menggunakan crypto token bernama imporCA:

Kalau diperhatikan, bagian check box untuk allow export private keys masih belum tercentang. Untuk mengubahnya, pilih switch to edit mode:

Centang check box allow export private keys kemudian tekan tombol save:

Sekarang Private Key dari CA sudah bisa diekspor:

Menggunakan CLI (Impor)

Untuk mengimpor backup key yang sudah kita expor tadi ke CA lainnya, jalankan perintah berikut pada direktori $EJBCA_HOME:

$ sh bin/ejbca.sh ca importca imporCA /root/imporCA.p12 
Importing soft token.
Enter keystore password:

Pada versi GUI-nya pun pasti otomatis langsung muncul:

Untuk bisa melakukan import CA yang mengunakan HSM. Jalankan perintah berikut:

$ sh bin/ejbca.sh ca importca --help

*Baca deskripsi dan rajin coba ya*

Baca juga: Konsep pada EJBCA

Menggunakan GUI

Untuk bisa mengekspor dan mengimpor CA Keys dengan menggunakan admin GUI, kita terlebih dahulu harus memiliki akses superadministrator. Pastikan kalau file .p12 tidak secara otomatis tersimpan pada tempat yang diinginkan oleh browser. 

Untuk mengekspor CA Keys, lakukan tahap berikut:

• Pilih Certificate Authorities dari administrator menu.
• Pada CA yang ingin diekspor, tekan edit.
• Pergi ke baris yang bertuliskan CA export requires the token authentication code.
• Masukkan keystore password tepat di dalam kotak yang disediakan kemudiakan tekan Export CA keystore
• File PKCS#12 akan terdownload oleh browser ke lokasi yang sudah kamu atur sebelumnya.

Untuk melakukan impor, lakukan tahap berikut:

• Pilih Certificate Authorities dari administrator menu.
• Pilih tombol import CA keystore
• Isi Form yang muncul. Beberapa hal yang harus diisi adalah nama CA yang akan diimpor, path file PKCS#12, keystore password.
• Isi Alias of signature key dengan SignatureKeyAlias
• Isi Alias of encryption key dengan EncryptionKeyAlias
• Kalau sudah, tekan tombol Import CA keystore

Renew CA

Kita bisa me-renew CA dengan 2 cara yaitu:

• Hanya me-renew sertifikatnya saja, menggunakan key yang sama.
• me-renew sertifikat dan key-nya.

Untuk me-renew hanya sertifikat CA dengan menggunakan key yang sama, cukup tekan Renew CA. CA harus dalam keadaan on-line sehingga CA bisa memberi sign atas terbitnya sertifikat baru tersebut jika CA tersebut merupakan self signed atau CA bisa menandatangani permintaan sertifikat baru jika itu adalah SUBCA. 

Jika permintaan sertifikat ini adalah untuk SUBCA dengan ROOTCA yang berada dalam satu EJBCA, ROOTCA harus dalam keadaan on-line.

Untuk me-renew CA keys, atur Next CA key dengan Generate new key using KeySequence. kalau sudah, maka kita hanya perlu menekan tombol Renew CA. Proses renew key ini tidak selalu berhasil jika kita menggunakan HSM. Bisa saja cara ini berguna bagi suatu HSM tapi tidak dengan yang lainnya. (silahkan melapor ke EJBCA kalau terjadi kegagalan).

Ketika menggunakan HSM, kita bisa me-renew key secara manual. Caranya cukup men-generate key baru di HSM dengan menggunakan tools apapun yang kita gunakan di awal (lebih baik menggunakan EJBCA CLI Tools) dan memilih key baru sebagai Next CA Key. Tekan tombol Renew CA untuk men-generate sertifikat CA yang baru.

Remove and Restore CA Soft Keystore

Soft Token CA bisa dihapus dari database. Ketika keystore dihapus, CA tidak bisa mengeluarkan sertifikat dan status CA Token menjadi offline.

Untuk menghapus catoken keys dari CA imporCA, jalankan perintah berikut pada direktori $EJBCA_HOME:

$ sh bin/ejbca.sh ca removekeystore imporCA

Untuk me-restore catoken key kembali, dengan menggunakan file .p12 yang sudah diekspor sebelumnya, jalankan perintah berikut pada direktori $EJBCA_HOME:

$ sh bin/ejbca.sh ca restorekeystore imporCA /home/jboss/imporCA.p12 -s SignatureKeyAlias -e EncryptionKeyAlias

Revoke CA

Jika kita ingin me-revoke sebuah CA, kita hanya perlu mengaahkan kursor ke Certification Authorities yang ada pada admin GUI. Pada CA yang kamu inginkan, tekan edit dan pada bagian CA Life Cycle, Pilih revoke.

Ketika melakukan revoke, ada beberapa hal yang perlu diperhatikan:

• Jika kita me-revoke ROOTCA, maka kita akan me-revoke semua sertifikat yang ada di database yang dikeluarkan oleh ROOTCA tersebut, dan membuat CRL.
• Jika kita me-revoke SUBCA, maka kita akan me-revoke semua sertifikat di database yang dikeluarkan oleh SUBCA tersebut, SUBCA itu sendiri dan membuat CRL. Ini terjadi secara otomatis jika SUBCA dan ROOTCA ditangani oleh instance EJBCA yang sama. Jika SUBCA ditandatangani oleh external CA, sertifikat SUBCA harus di-revoke oleh external CA yang menandatanganinya.
• Jika kita me-revoke external CA, sertifikat dari external CA tersebut akan di-revoke dan ditempatkan pada CRL dari CA yang menerbitkannya.

Yup, itu tadi sedikit tulisan mengenai cara mengelola CA pada EJBCA 6.10.1.2. Semoga bisa membantu ya

sumber: EJBCA Docs

The post Cara Mengelola CA pada EJBCA 6.10.1.2 first appeared on GoBlog.

Merujuk pada Diagram Layout logical ASCII berikut:

Apa yang tidak diperlihatkan oleh diagram ini adalah VA (Validation Authority) memiliki datasource Jboss tersendiri yang berbeda dari datasource yang digunakan oleh CA (Certifictaion Authority). Namun, dalam environment standalone, koneksi ini mengarah ke database yang sama (database ejbca) yang digunakan oleh CA.

• Mendfinisikan datasource VA adalah tujuan utama dari file va-publisher.properties (file berada di /opt/ejbca/conf/ setelah di copy dari /opt/ejbca/conf/sample/).
• seperti datasource CA, konfigurasi datasource VA juga akan ditambahkan ke dalam file standalone.xml selama deployment. (setelah file . properties yang spesifik dengan VA dibuat).
• Perlu dicatat bagaimana PrimeKey menggunakan istilah “Publisher”. Publisher ini digunakan untuk menggambarkan gagasan tentang informasi dari komponen “publishing” EJBCA (dari sebuah datasource) ke sebuah server terpisah pada sebuah instalasi EJBCA yang terdistribusi.
• Misalkan server standalone kita hanya “publishing” ke service VA-nya sendiri , kita masih membutuhkan “publisher” untuk dimasukkan dalam va-publisher.properties.
• file va.properties menjelaskan operasi VA secara umum seperti fungsi pemeriksaan kesehatan (healthcheck).
• file ocsp.properties mendefinisikan fungsionalitas protokol OCSP.
• File va.properties berisi instruksi spesifik bagaimana mengizinkan download CRL/OCSP alias untuk beberapa (multiple) instance CA.

Langkah pertama untuk menjalankan VA adalah membuat file-file properties yang terkait validasi pada direktori /opt/ejbca/conf. caranya:

cd /opt/ejbca/conf
cp sample/ocsp.properties.sample ocsp.properties
cp sample/va.properties.sample va.properties
cp sample/va-publisher.properties.sample va-publisher.properties

Konfigurasi file-file Validation Authority

ocsp.properties

### Start ocsp.properties ###
 
 # ------------ OCSP responder configuration ---------------------
 
 ocsp.enabled=true
 #ocsp.enabled=false
 
 # ini path untuk URL OCSP
 ocsp.contextroot=/ejbca/publicweb/status
 #ocsp.contextroot=/status
 
 # ini adalah DN dari CA yang akan merespon untuk serifikat yang gak dikenal
 ocsp.defaultresponder=CN=NamaCALo,O=PerusahaanLo,C=ID
 
 ocsp.includecertchain=true
 ocsp.includesignercert=true
 ocsp.responderidtype=keyhash
 ocsp.signaturealgorithm=SHA1WithRSA;SHA1WithECDSA;SHA1WithDSA
 ocsp.signingCertsValidTime=300
 ocsp.warningBeforeExpirationTime=10000
 
 ocsp.nonexistingisgood=false
 
 #ocsp.nonexistingisgood.uri.1=.*/thisEndingIsGood$
 #ocsp.nonexistingisgood.uri.2=^http://good.myhost.nu:8080/.*
 #ocsp.nonexistingisbad.uri.1=.*/thisEndingIsBad$
 #ocsp.nonexistingisbad.uri.2=^http://bad.myhost.nu:8080/.*
 ocsp.nonexistingisrevoked=false
 #ocsp.nonexistingisrevoked.uri.1=.*/thisEndingIsRevoked$
 #ocsp.nonexistingisrevoked.uri.2=^http://revoked.myhost.nu:8080/.*
 
 ocsp.expiredcert.retentionperiod = 31536000
 #ocsp.expiredcert.retentionperiod = -1
 
 ocsp.untilNextUpdate = 0
 #ocsp.999.untilNextUpdate = 50
 ocsp.revoked.untilNextUpdate = 0
 #ocsp.999.revoked.untilNextUpdate = 50
 ocsp.maxAge = 30
 #ocsp.999.maxAge = 100
 ocsp.revoked.maxAge = 30
 #ocsp.999.revoked.maxAge = 100
 
 #ocsp.extensionoid=
 #ocsp.extensionclass=
 
 #ocsp.uniddatsource=
 #ocsp.unidtrustdir=
 #ocsp.unidcacert=
 #ocsp.signaturerequired=false
 
 #ocsp.rekeying.trigging.password=
 #ocsp.rekeying.wsurl = https://milton:8443/ejbca/ejbcaws/ejbcaws
 #ocsp.rekeying.update.time.in.seconds=
 #ocsp.rekeying.safety.margin.in.seconds=
 #ocsp.rekeying.trigging.hosts=
 
 # Default: false
 ocsp.trx-log = true
 ocsp.log-date = yyyy-MM-dd:HH:mm:ss:z
 #ocsp.log-timezone = GMT
 #ocsp.trx-log-pattern = \\$\\{(.+?)\\}
 # The next line will probably line-wrap in your browser:
 #ocsp.trx-log-order = ${SESSION_ID};${LOG_ID};${STATUS};${REQ_NAME}"${CLIENT_IP}";"${SIGN_ISSUER_NAME_DN}";"${SIGN_SUBJECT_NAME}";${SIGN_SERIAL_NO};"${LOG_TIME}";${REPLY_TIME};${PROCESS_TIME};${NUM_CERT_ID};0;0;0;0;0;0;0;"${ISSUER_NAME_DN}";${ISSUER_NAME_HASH};${ISSUER_KEY};${DIGEST_ALGOR};${SERIAL_NOHEX};${CERT_STATUS}
 
 ocsp.audit-log = true
 #ocsp.audit-log-pattern = \\$\\{(.+?)\\}
 # The next line will probably line-wrap in your browser:
 #ocsp.audit-log-order = SESSION_ID:${SESSION_ID};LOG ID:${LOG_ID};"${LOG_TIME}";REPLY TIME:${REPLY_TIME};\nTIME TO PROCESS:${PROCESS_TIME};\nOCSP REQUEST:\n"${OCSPREQUEST}";\nOCSP RESPONSE:\n"${OCSPRESPONSE}";\nSTATUS:${STATUS}
 #ocsp.log-safer = true
 
 
 ### End ocsp.properties ###

va.properties

### Start va.properties ###
 
 #------------------- Validation Authority (VA) Healthcheck settings -------------
 ocsphealthcheck.signtest=true
 ocsphealthcheck.checkSigningCertificateValidity=true
 
 
 # PrimeKey's instructions here are particularly terrible. Let me see if I can translate:
 
 # In this last setting, we will define an alias 'root' for a particular RFC 4985 Section 2.1 "Search Key ID Hash" or "sKIDHash"
 # Our example sKIDHash is:'O4RdnGNf3WPioslAQsX71aR1/MI'
 # sKIDHashes are unique to each CA instance that you run on your ejbca server.
 
 # This has the effect of making the following URLs equivalent. This simplifies the entries in your certificates that specify
 # CRL/OCSP download locations, and grants the ability to have simultaneous CRL/OCSP download URLs
 # Typically, you will define a unique sKIDHash alias for each of your CA instances.
 
 # Example URL for certificate search: http://myhost.com:8080/certificates/search.cgi?sKIDHash=O4RdnGNf3WPioslAQsX71aR1/MI
 # This will be the same as http://myhost.com:8080/certificates/search.cgi?alias=root
 
 # Example URL for CRL download: http://myhost.com:8080/crls/search.cgi?sKIDHash=O4RdnGNf3WPioslAQsX71aR1/MI
 # is the same as http://myhost.com:8080/crls/search.cgi?alias=root
 
 # Example URL for Delta CRL download: http://myhost.com:8080/crls/search.cgi?sKIDHash=O4RdnGNf3WPioslAQsX71aR1/MI&delta=
 # is the same as http://myhost.com:8080/crls/search.cgi?alias=root&delta=
 
 
 # To determine the hash to use here, navigate to http://yourhost.com:8080/crls/search.cgi or http://yourhost.com:8080/certificates/search.cgi
 # (Omit the :8080 if you are browsing from somewhere other than localhost)
 # This URL will give you a list of the unique validation identifiers (including the sKIDHash) for each of your defined CAs.
 
 # Copy the sKIDHashes for the CA instances. Remember, you will have more than one, and you can omit the Management CA as it is solely internal to ejbca.
 # Add an entry like the one below for each of your CAs, paste the sKIDHash into the entry, then redeploy ejbca.
 
 
 #va.sKIDHash.alias.root=O4RdnGNf3WPioslAQsX71aR1/MI
 
 ### End va.properties ###

va-publisher.properties

Start va-publisher.properties ###
 
 #-------------- Validation Authority(VA) publisher db configuration-------------------------
 # All the "ocsp-database.*" properties are used to configure the VA connection to the database.
 #
 # In "PrimeKeyese": Configure these options if you are configuring EJBCA that will publish 
 # certificates to a VA.
 
 
 ocsp-datasource.jndi-name=OcspDS
 ocsp-database.url=jdbc:mysql://127.0.0.1:3306/ejbcadb?characterEncoding=UTF-8
 ocsp-database.driver=com.mysql.jdbc.Driver
 ocsp-database.username=ejbcadbuser
 
 
 # password Databasenya diatur di sini
 ocsp-database.password=asalaja
 
 ### End va-publisher.properties ###

Untuk membuat VA berjalan, kita perlu mengeksekusi beberapa perintah yang sama sebelum kita melakukan deployment awal:

su - jboss
cd /opt/jboss/bin
ps -ax | grep jboss
kill -9 <proses_jboss>
chown -R jboss:jboss /opt/jboss-as-7.1.1.Final
chown -R jboss:jboss /opt/ejbca_ce_6_2_0
nohup ./standalone.sh -b 0.0.0.0 -bmanagement=0.0.0.0 &
cd /opt/ejbca
ant deploy

ingat bahwa dalam ocsp.properties, kita mendefinisikan “ocsp.defaultresponder“. Ini adalah DN dari CA yang akan menjawab permintaan OCSP untuk CA yang tidak diketahui. Primekey merekomendasikan agar kita menggunakan Management CA (Root CA) untuk ini. Namun, alangkah lebih baiknya bila kuta menggunakan default CA (Sub CA) untuk tujuan ini atau kita menggunakan Sebuah SubCA yang kita buat terlebih dahulu.

sampai SubCA itu berhasil dibuat, kita akan melihat pesan berikut dalam console log (nohup.out):

dan terakhir, kalau terjadi masalah dengan file va-publisher.properties milik kita, mungkin kita akan melihat pesan berikut:

06:31:45,632 WARN  [org.ejbca.core.protocol.certificatestore.CertificateCache] (MSC service thread 1-2) org.bouncycastle.ocsp.OCSPException: problem creating ID: java.security.NoSuchProviderException: no such provider: BC

“BC” adalah Bouncycastle (OCSP Java Module)

Itu tadi cara menambahkan Validation Authority ke dalam EJBCA. Untuk pengujian VA tersebut, nantikan postingan selanjutnya ya.

Adios!!!

Source: EJBCACENTOS

The post Menambahkan Validation Authority pada EJBCA 6.2.0 first appeared on GoBlog.