Sekarang CA dan Profile sudah jadi, Kita bisa membuat entitas pertama kita. Setelah memasuki halaman ‘Add Entity”, Plih nama End Entity yang sudah kita buat sebelumnya. Maka field akan berisi informasi dari profil tersebut:

Misalkan kita menggunakan profile “Sertifikat untuk TLS” yang sudah kita buat sebelumnya, hanya informasi ini yang akan dibutuhkan sebelum membuat entitas ini:

• End Entity Profile: Sertifikat untuk TLS
• Username: perangkat.perusahaanlo.com
• Email Address: Perangkat@perusahaanlo.com
• CN: perangkat.perusahaanlo.com
  FQDN dari perangkat
• Certificate Profile: Sertifikat untuk TLS
• CA: rootca.perusahaanlo.com
  Nama CA yang kita buat di langkah sebelumnya.
• Token: User Generated
  User bisa memilih apakah ingin memilih token berupa .JKS atau .p12

Pilih “Add” untuk menambahkan Entitas.

ketika entitas sudah ditambahkan, kita akan melihat entitas baru terdaftar di bagian bawah dari halaman tersebut.

Review OpenSSL – Perkenalan

EJBCA mengharuskan kita untuk mengajukan sebuah CSR (Certificate Signing Request) sebelum mengeluarkan sebauh sertifikat. tetapi itu tidak ada interface untuk melakukannya. Cara paling mudah untuk menghasilkan sebuah CSR adalah dengan menggunakan OpenSSL, yang memiliki kemampuan untuk menghasilkan CSR dengan menggunakan algoritma RSA atau EC. Saya pikir ada baiknya jika kita juga mereview kegunaan dari OpenSSL ini.

Meskipun sempat didera oleh bug “HeartBleed” (namun sudah berhasil ditangani), OpenSSL tetap dan akan terus menjadi rajanya enkripsi open source. Fokus perintah OpenSSL yang akan dibahas kali ini adalah hanya yang terkait dengan fungsi CSR.

Tahap pertama yang perlu kita lakukan adalah melakukan pengecekkan pada versi openssl pada server kita. caranya:

openssl version

dan keluarannya seperti ini:

Catatan, kalau versi openssl anda masih versi 1.0.1 sampai 1.0.1f, segera update karena versi tersebut vulnerable.

Review OpenSSL – Membuat sebuah RSA CSR

kita asumsikan bahwa enkripsi EC kemungkinan tidak diimplementasikan oleh beberapa perangkat atau semua di jaringan kita, jadi CSR pertama adalah untuk sebuah sertifikat yang menggunakan enkripsi RSA 2048-bit dan sebuah algoritma penandatanganan SHA-256. Perintah berikut akan membuat sebuah Kunci Privat yang baru, dan termasuk sebuah CSR baru:

openssl req -newkey rsa:2048 -nodes -sha256 -keyout server.key -out server.csr

Berikut penjelasan untuk syntax di atas:

• Req → merupakan sebuah permintaan (Request).
• -newkey rsa:2048 → sebuah kunci privat yang akan dibuat dengan menggunakan algortima RSA 2048-bit, beserta CSR baru.
• -nodes → Kunci privat yang dibuat oleh perintah ini akan tidak terenkripsi.
• -sha256 → Sertifikat yang yang diminta dalam CSR akan menggunakan algoritma penandatanganan SHA-256.
• -keyout server.key → Kunci Privat yang baru akan disimpan kedalam file yang bernama server.key
• -out server.csr → CSR baru akan disimpan dengan nama server.csr

Sekarang mari kita lihat isi dari server.key tersebut:

Kemudian sekarang kita lihat isi dari server.csr:

Dalam pembuatan CSR sebenarnya akan ada sebuah prompt yang meminta beberap field data untuk diisi. Namun field-field tersebut akan diabaikan oleh EJBCA delama proses pembuatan sertifikat karena kita telah menonaktifkan fungsi “Overrides” dalam Certificate Profile.

Review OpenSSL – Membuat EC CSR

OpenSSL sekarang mendukung Algoritma Elliptic Curve (EC). Untuk mengetahui apa saja yang disupport oleh versi OpenSSL kalian, jalanka perintah berikut:

openssl ecparam -list_curves

secp112r1 : SECG/WTLS curve over a 112 bit prime field
  secp112r2 : SECG curve over a 112 bit prime field
  secp128r1 : SECG curve over a 128 bit prime field
  secp128r2 : SECG curve over a 128 bit prime field
  secp160k1 : SECG curve over a 160 bit prime field
  secp160r1 : SECG curve over a 160 bit prime field
  secp160r2 : SECG/WTLS curve over a 160 bit prime field
  secp192k1 : SECG curve over a 192 bit prime field
  secp224k1 : SECG curve over a 224 bit prime field
  secp224r1 : NIST/SECG curve over a 224 bit prime field
  secp256k1 : SECG curve over a 256 bit prime field
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
  prime192v2: X9.62 curve over a 192 bit prime field
  prime192v3: X9.62 curve over a 192 bit prime field
  prime239v1: X9.62 curve over a 239 bit prime field
  prime239v2: X9.62 curve over a 239 bit prime field
  prime239v3: X9.62 curve over a 239 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field
  sect113r1 : SECG curve over a 113 bit binary field
  sect113r2 : SECG curve over a 113 bit binary field
  sect131r1 : SECG/WTLS curve over a 131 bit binary field
  sect131r2 : SECG curve over a 131 bit binary field
  sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
  sect163r1 : SECG curve over a 163 bit binary field
  sect163r2 : NIST/SECG curve over a 163 bit binary field
  sect193r1 : SECG curve over a 193 bit binary field
  sect193r2 : SECG curve over a 193 bit binary field
  sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
  sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
  sect239k1 : SECG curve over a 239 bit binary field
  sect283k1 : NIST/SECG curve over a 283 bit binary field
  sect283r1 : NIST/SECG curve over a 283 bit binary field
  sect409k1 : NIST/SECG curve over a 409 bit binary field
  sect409r1 : NIST/SECG curve over a 409 bit binary field
  sect571k1 : NIST/SECG curve over a 571 bit binary field
  sect571r1 : NIST/SECG curve over a 571 bit binary field
  c2pnb163v1: X9.62 curve over a 163 bit binary field
  c2pnb163v2: X9.62 curve over a 163 bit binary field
  c2pnb163v3: X9.62 curve over a 163 bit binary field
  c2pnb176v1: X9.62 curve over a 176 bit binary field
  c2tnb191v1: X9.62 curve over a 191 bit binary field
  c2tnb191v2: X9.62 curve over a 191 bit binary field
  c2tnb191v3: X9.62 curve over a 191 bit binary field
  c2pnb208w1: X9.62 curve over a 208 bit binary field
  c2tnb239v1: X9.62 curve over a 239 bit binary field
  c2tnb239v2: X9.62 curve over a 239 bit binary field
  c2tnb239v3: X9.62 curve over a 239 bit binary field
  c2pnb272w1: X9.62 curve over a 272 bit binary field
  c2pnb304w1: X9.62 curve over a 304 bit binary field
  c2tnb359v1: X9.62 curve over a 359 bit binary field
  c2pnb368w1: X9.62 curve over a 368 bit binary field
  c2tnb431r1: X9.62 curve over a 431 bit binary field
  wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
  wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
  wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
  wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
  wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
  wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
  wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
  wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
  wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
  wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
  wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field
  Oakley-EC2N-3: 
    IPSec/IKE/Oakley curve #3 over a 155 bit binary field.
    Not suitable for ECDSA.
    Questionable extension field!
  Oakley-EC2N-4: 
    IPSec/IKE/Oakley curve #4 over a 185 bit binary field.
    Not suitable for ECDSA.
    Questionable extension field!
  brainpoolP160r1: RFC 5639 curve over a 160 bit prime field
  brainpoolP160t1: RFC 5639 curve over a 160 bit prime field
  brainpoolP192r1: RFC 5639 curve over a 192 bit prime field
  brainpoolP192t1: RFC 5639 curve over a 192 bit prime field
  brainpoolP224r1: RFC 5639 curve over a 224 bit prime field
  brainpoolP224t1: RFC 5639 curve over a 224 bit prime field
  brainpoolP256r1: RFC 5639 curve over a 256 bit prime field
  brainpoolP256t1: RFC 5639 curve over a 256 bit prime field
  brainpoolP320r1: RFC 5639 curve over a 320 bit prime field
  brainpoolP320t1: RFC 5639 curve over a 320 bit prime field
  brainpoolP384r1: RFC 5639 curve over a 384 bit prime field
  brainpoolP384t1: RFC 5639 curve over a 384 bit prime field
  brainpoolP512r1: RFC 5639 curve over a 512 bit prime field
  brainpoolP512t1: RFC 5639 curve over a 512 bit prime field

Tidak seperti CSR RSA, proses untuk membuat CSR EC membutuhkan 2 perintah OpenSSL terpisah. Kita akan membuat CSR dengan menggunakan curve prime256v1, yang merupakn curve yang paling umum diimplementasikan dalam Kriptografi EC.

perintah pertama adalah untuk membuat Kunci Privat:

openssl ecparam -out eckey.key -name prime256v1 -genkey

Perintah yang kedua membaca Kunci Privat dan membuat CSR. Ingat bahwa syntaxnya berbeda dari versi RSA “newkey” karena disini dibagi ke dalam dua bagian:

openssl req -new -key eckey.key -nodes -sha256 -outform pem -out ecreq.csr

Perintah yang baru adalah:

• -new → Sebuah CSR baru akan dibuat.
• -key eckey.key → CSR baru akan berasal dari Kunci Privat eckey.key
• -outform pem → CSR yang baru akan ditulis dalam format PEM.

Sekarang mari kita lihat outputnya, Baik EC Key dan CSR nya jauh lebih kecil ukurannya bial dibanding dengan RSA yang ekuivalen dengannya (contoh di atas):

cat eckey.key

cat ecreq.csr

Segitu dulu postingan di bagian ke 5 kali ini. Di postingan berikutnya akan membahas tentang issuing Certificate alias mengeluarkan sertifikat.

Pantau terus yaaa!!!

source: EJBCACENTOS

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

Sekarang kita memasuki tahapan dimana kita akan membuat CA (SubCA) pertama kita. Ini dilakukan melalui interface web admin (Superadmin):

Sebelum kita memulai konfigurasi, berikut ini adalah penjelasan singkat mengenai tampilan halaman Admin EJBCA:

• CA Functions
  Bagian ini berfungsi untuk mengkonfigurasi fungsi Certification Authority dari EJBCA.
• RA Functions
  Bagian ini berfungsi untuk mengkonfigurasi fungsi Registration Authority dari EJBCA (Pendaftaran end user).
• Supervisor Functions
  Bagian ini berfungsi untuk melihat log EJBCA dan menyetujui permintaan.
• System Functions
  Bagian ini memiliki beberapa fungsi validasi, beberapa fungsi administrasi dan konfigurasi umum.

Dalam EJBCA, fungsi dari RA (Registration Authority) adalah mengatur permintaan untuk pembuatan sertifikat baru. RA mengatur akun pengguna yang terkait dengan setiap CA dan tipe sertifikat yang boleh diminta oleh user. RA juga menjawab pertanyaan tentang sertifikat yang sudah dikeluarkan (issued), meskipun fungsi ini berbeda dari VA.

Dalam pembuatan CA ini, RA diinstal menjadi satu dengan fungsi utama CA, jadi tidak dikonfigurasi secara terpisah.

Alur Kerja Pembuatan CA

Kita asumsikan bahwa kebanyakan sertifikat yang akan dikeluarkan oleh CA kita akan menjadi standar untuk koneksi HTTPS dengan menggunakan TLS. Jadi konfigurasi berikut akan diarahkan untuk tujuan tersebut. Pada saat selesai, kita seharusnya sudah mempunyai sebuah sertifikat yang dapat diinstal pada server manapun yang menggunakan apache.

Sangat penting untuk menuliskan atau menggambarkan akur kerja pembuatan CA di EJBCA, karena kita bisa memiliki banyak CA yang berbeda untuk tujuan yang berbeda-beda. Berikut ini adalah alur yang akan kita kerjakan:

1. Membuat sebuah Sertifikat Profile  (Certificate Profile) – Mendefinisikan beberapa nilai yang akan digunakan sebagai template.
2. Membuat sebuah Profil dari Entitas Akhir (End Entity Profile) – Template juga tetapi untuk user.
3. Membuat sebuah CA (Certification Authority) – Membuat CA.

Ketika langkah-langkah tersebut selesai, kita akan membuat sebuah entitas akhir (End Entity) dan mengeluarkan sebuah sertifikat untuknya.

Kita akan membuat sebuah CA terlebih dahulu, tetapi secara khusus saya menggunakan langkah-langkah ini untuk menggambarkan beberapa konsep:

• Kita harus tahu dulu algoritma dan panjang kunci (key lengths) yang akan kita gunakan sebelum membuat CA. Kebanyakan aplikasi PKI hanya mendukung beberapa algoritma alias terbatas, itulah mengapa kita harus tahu terlebih dahulu.
• Kita juga harus tahu detail dari sertifikat (extensi) yang akan kita gunakan.

Mendefinisikan sebuah Certificate Profile dan End Entity Profile terlebih dahulu memaksa kita untuk memiliki detail ini sebelum melakukan pembuatan CA (SubCA).

Penentuan Algoritma

Memilih algoritma enkripsi sebuah kunci publik adalah sebuah “topik sensitif” untuk beberapa orang akhir-akhir ini, dengan pendapat yang biasanya mengarah kepada:

• The NSA (National Security Agency) adalah sebuah badan yang dibentuk untuk melindungi masyarakat dari aksi-aksi orang jahat.

atau

• The NSA (National Security Agency) adalah sebuah badan yang jahat yang dibentuk untuk mencuri rahasia dan menghancurkan privasi dari orang-orang baik yang ada di dunia ini.

Terlepas dimana pilihan anda akan jatuh, apakah menganggap NSA itu baik atau buruk, pilihan kita untuk algoritma enkripsi kunci publik terbatas antara RSA dan Eliptic Curve DSA. Dengan RSA, Variabelnya hanyalah panjang dari modulus kunci kita, dengan opsi saat ini yaitu 2048, 4096 dan 8192 bits.

Dengan ECDSA, kita memiliki banyak varian yang membingungkan untuk dipilih. Dari banyaknya varian tersebut, berikut ini adalah ringkasannya (Terima kasih untuk SECG dan Fabio Pietrosanti):

Fokus pertama kita adalah pada konvensi SECG untuk penamaan ECDSA:

• “sec” hanya menunjukkan nama spsefikasi: “Standards for Efficient Cryptography“.
• “p” atau “t” merujuk pada 2 varian dari algoritma Elliptic Curve. “p” adalah “prime“.
• Tiga nomor berikutnya merujuk pada panjang (dalam bits) dari modulus.
• “r” atau “k” merujuk pada bagian dari Curve yang digunakan oleh persamaan Elliptic – “Random” atau “Koblitz“.
• nomor terakhir adalah nomor sequence, mengacu pada varian matematika.

Dan sekarang bagian dari judul kolom pada tabel:

• SECG NAME – Nama panggilan SECG dari varian Elliptic Curve.
• SIZE – panjang field dalam bits.
• RSA EQ – Ukuran perkiraan dari sebuah modulus RSA pada kekuatan setara.
• Curve – menunjukkan apakah curve ini Koblitz atau Random.
• NIST – Nama dari standar ekuivalen NIST untuk Curve.

SECG NAME	SIZE	RSA EQ	CURVE	NIST
sect163k1	163		Koblitz	K-163
sect163r1	163		Random
sect163r2	163		Random	B-163
sect193r1	193		Random
sect193r2	193		Random
sect233k1	233		Koblitz	K-233
sect233r1	233		Random	B-233
sect239k1	239		Koblitz
sect283k1	283		Koblitz	K-283
sect283r1	283		Random	B-283
sect409k1	409		Koblitz	K-409
sect409r1	409		Random	B-409
sect571k1	571		Koblitz	K-571
sect571r1	571		Random	B-571
secp160k1	160	1024	Koblitz
secp160r1	160	1024	Random
secp160r2	160	1024	Random
secp192k1	192	1536	Koblitz
secp192r1	192	1536	Random	P-192
secp224k1	224	2048	Koblitz
secp224r1	224	2048	Random	P-224
secp256k1	256	3072	Koblitz
secp256r1	256	3072	Random	P-256
secp384r1	384	7680	Random	P-384
secp521r1	521	15360	Random	P-521

Tabel ECDSA

Mari kita bandingkan dengan lebih ketat kali ini antara Koblitz dan Random (ECC) yang setara dengan RSA (dalam bits):

Koblitz	ECC	DH/DSA/RSA
163	192	1024
283	256	3072
409	384	7680
571	521	15360

Perbandingan Koblitz, ECC dan RSA

Yang bisa diangkat dari informasi pada tabel-tabel ini adalah:

• Persamaan Elliptic Curve jauh lebih efisien dibanding persamaan RSA.
• Persamaan Elliptic Curve menggunakan Koblitz sedikit kurang efisien (sekitar 10%) dibandingkan menggunakan Random.
• Ketika memilih persamaan Elliptic Curve, adalah ide yang bagus untuk memilih sebuah varian yang didukung oleh banyak organisasi (SECG, NIST, dll) untuk tujuan kompatibilitas.

Secara singkat, kekhawatiran tertinggi didapat dari pembawaan Random Curves, dan apakah benar atau tidak mereka benar-benar “random”. Jika kalian khawatir mengenai NSA yang memiliki “backdoor” dalam Elliptic Curves, sarannya adalah menggunakan varian Koblitz seperti yang digunakan oleh Bitcoin. Namun, Curve ini akan memakan 10%  dari efisiensimu, dan algoritma yang berbasis Koblitz belum diterima secara luas oleh banyak orang seperti layaknya Random Curve.

• Pada akhirnya, tidak ada jaminan bahwa NSA bisa memecahkan enkripsi kalian terlepas dari algoritma yang kalian pilih.

Sekarang ini, dunia bergerak menuju Kriptografi Elliptic Curves. Saat EJBCA mengimplementasikan ini, ini akan menjadi algoritma terbaik untuk digunakan oleh CA dan sertifikat.

• Untuk alasan interoperabilitas, sebaiknya kita menggunakan standard de facto untuk TLS pada internet yaitu 2048-bit RSA tetapi dengan sebuah SHA-256 Key.
• Ketika kita membuat CA di EJBCA, 4096-bit RSA bisa menjadi pilihan yang baik.

Penjelasan Field-Field pada Sertifikat

Spesifikasi X.509 mengizinkan banyaknya field yang bisa disertakan dalam sertifikat. Untungnya, kebanyakan field tersebut ditolak oleh implementasi PKI

Untuk mengilustrasikan ini, berikut ada sebuah sertifikat yang digunakan oleh google untuk mengamankan Gmail dan kita akan membukanya dengan menggunakan Firefox Certificate Viewer:

Pada Firefox Viewer, informasi lengkapnya dapat dilihat pada tab “Details”:

Pada Sertifikat di atas, Google menggunakan field-field berikut:

• Version: 3
• Serial Number: 07:29:38:9A:3E:F9:9C:B1
• Certificate Signature Algorithm: SHA-1 with RSA
• Issuer: CN=Google Internet Authority G2,O=Google Inc, C=US
• Validity: Not After 7-21-2014
• Subject: (the DN) CN=mail.google.com, O=Google Inc, L=Mountain View, ST=California,C=US
• Algorithm Identifier: Elliptic Curve Public Key
• Algorithm Parameters: ANSI X9.62 elliptic curve prime256v1 (aka secp256r1, NIST P-256)
• Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication
• Certificate Subject Alt Name: DNS Name=mail.google.com
• Certificate Key Usage: Signing
• Authority Information Access:
  • CA Issuers: URI: http://pki.google.com/GIAG2.crt
  • OCSP: URI http://clients1.google.com/ocsp
• Certificate Subject Key ID: (160 bit number)
• Certificate Basic Constraints: Is not a Certificate Authority
• Certificate Authority Identifier: (160 bit number)
• Certificate Policies: 1.3.6.1.4.1.11129.2.5.1
• CRL Distribution Points: URI: http://pki.google.com/GIAG2.crl
• Certificate Signature Value: (2048-bit number)

Field-field tersebut adalah titik awal yang bagus untuk kita dapat menentukan isi dari sertifikat kita nanti.

Sangat penting untuk dicatat bahwa banyak parameter di atas dapat di-set dengan menggunakan sesuatu yang disebut “Critical Flag”.  Secara umum, pada sertifikat yang digunakan untuk TLS Web, Critical Flag hanya di-set untuk field “Basic Certificate Constraints“.

• Jangan menggunakan “Critical Flag” pada semua paremeter dalam sertifikat kita, atau sertifikat tersebut tidak akan bekerja.

Sebagia perbandingan, berikut ini adalah sertifikat untuk RootCA yang memvalidasi sertifikat GMAIL:

Root CA menggunakan field yang lebih sedikit dari sertifikat Gmail, dan menggunakan enkripsi 2048-bit RSA:

• Version: 3
• Serial Number: 02:34:56 (this is not a typo)
• Certificate Signature Algorithm: SHA-1 with RSA
• Issuer: CN=GeoTrust Global CA, O=GeoTrust, Inc.,C=US
• Validity: Not After 5/20/2022
• Subject: CN=GeoTrust Global CA,O=GeoTrust, Inc.,C=US
• Subject Public Key Algorithm: RSA Encryption
• Subject’s Public Key: (2048-bit number)
• Certificate Basic Constraints: Is a Certificate Authority, Unlimited Intermediate CAs
• Certificate Subject Key ID: (160-bit number)
• Certificate Authority Key ID: (the same 160-bit number)
• Certificate Signature Value: (2048-bit number)

Sertifikat ini akan digunakan sebagai Template untuk menjelaskan field pada Profil Awal, CA dan sertifikat.

Okay sampai di situ dulu bagian pertama, untuk bagian kedua akan dilanjut pada postingan berikutnya.

Pantau terus ya

Source: EJBCACENTOS

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