Jika salah satu objek utama infrastruktur kunci publik (PKI) adalah sertifikat X509, maka subjek utama PKI adalah Otoritas Sertifikasi (CA). CAlah yang mengeluarkan sertifikat, menghentikan validitasnya (pencabutan sertifikat), mengonfirmasi validitasnya. Di halaman
Habrahabr, Anda dapat menemukan berbagai publikasi tentang masalah sertifikat digital menggunakan
OpenSSL .
Pada dasarnya, artikel-artikel ini membahas penggunaan
utilitas openssl , menjelaskan antarmuka baris perintahnya dan bekerja dengan file yang menyimpan semuanya: kunci, permintaan, sertifikat, termasuk root, dll. Tetapi jika Anda mengembangkan pusat sertifikasi skala penuh (CA) yang berbasis pada OpenSSL, maka wajar jika Anda ingin menyingkirkan berbagai file ini dan beralih ke bekerja dengan basis data, serta memiliki antarmuka grafis untuk menerbitkan dan mengelola sertifikat. Dan jika Anda mengingat Hukum Federal 6 April 2011. No. 63- Tentang Tanda Tangan Elektronik, CA harus mematuhi persyaratan hukum ini, serta Persyaratan untuk Bentuk Sertifikat Kualifikasi untuk Kunci Verifikasi Tanda Tangan Elektronik, yang disetujui oleh Pesanan Layanan Keamanan Federal Rusia tertanggal 27 Desember 2011 No. 795.
Warga biasa memiliki kesan bahwa UT adalah sesuatu yang luar biasa (well, Center, hampir seperti Mission Control Center).
Dari sudut pandang tanggung jawab CA - ini memang benar. Bagaimanapun, sertifikat yang dikeluarkan oleh CA sebenarnya sama dengan paspor hari ini.
Dari sudut pandang seorang programmer, semuanya tidak begitu menakutkan. Jadi proyek pusat sertifikasi CAFL63 lahir. Implementasi proyek CAFL63 didasarkan pada tiga "pilar", yaitu OpenSSL,
SQLite3 dan
Tcl / Tk .
Jadi, apa Otoritas Sertifikasi saat ini? Pertama-tama, itu adalah Pusat Registrasi, di mana perwakilan dari badan hukum, individu, pengusaha individu datang untuk sertifikat dengan paket dokumen yang diperlukan, khususnya, mengidentifikasi identitas dan otoritas pemohon. Mereka dapat datang dengan aplikasi yang sudah jadi secara elektronik. CR memeriksa dokumen, permintaan (data yang lengkap, kebenaran tanda tangan elektronik, dll.), Dan jika semuanya berjalan dengan baik, mereka menerima permintaan, menyetujui dan mengirimkannya ke Pusat Sertifikasi (CA). Tapi ini ideal. Dalam praktiknya, semuanya terlihat berbeda.
Warga negara, organisasi memerlukan sertifikat (untuk akses ke portal Layanan Negara, untuk pelaporan pajak, untuk penawaran), tetapi mereka tidak tahu apa itu dan apa yang harus dilakukan dengan itu. Mereka sangat yakin bahwa CA menerima tanda tangan elektronik seperti faksimili. Tapi ini adalah masalah pencerahan. Oleh karena itu, pelamar datang ke Administrasi Pusat Administrasi Pusat dan menyerahkan dokumen. Bersama dengan karyawan Kantor Pusat, mereka pergi ke tempat kerja terpisah dan
menyiapkan permintaan sertifikat:
Permintaan yang disiapkan pada media elektronik, sebagaimana telah disebutkan, diterima oleh CR. Apa yang perlu diingat oleh pelamar? Pertama dan terutama, ambil media dengan kunci pribadi yang dibuat!
Permintaan yang disetujui pada media elektronik dikirimkan ke CA, di mana sertifikat akan dikeluarkan berdasarkannya.
Ini adalah diagram skematis dari pekerjaan CA. Detail akan menjadi jelas di bawah ini. Satu komentar, untuk kenyamanan demonstrasi, utilitas untuk mempersiapkan permintaan, CR dan CA digabungkan menjadi satu kompleks demonstrasi. Tetapi tidak ada masalah dengan keanekaragaman fungsional. Yang paling sederhana adalah memiliki instance CAFL63 di setiap tempat kerja dan hanya menggunakan fungsionalitas yang diperlukan.
Ketika proyek itu berjalan lancar, proyek
SimpleCA menarik perhatian saya. Mempelajari proyek ini banyak membantu dengan implementasi akhir CAFL63 CA.
Kode sumber utilitas dan distribusinya untuk platform Linux dan MS Windows dapat ditemukan
Jadi, jalankan utilitas CAFL63 dan halaman mulai muncul di layar:
Kami memulai pekerjaan dengan menekan tombol "Buat Basis Data". Basis data CA dibuat menggunakan
DBite lintas-platform
SQLite3 . Basis data CA berisi beberapa tabel. Tabel utama mainDB hanya berisi satu catatan, yang menyimpan sertifikat root, kunci pribadi yang dienkripsi dengan kata sandi, dan pengaturan CA. Ada dua tabel yang terkait dengan permintaan sertifikat: permintaan reqDB saat ini dan arsip permintaan reqDBArc. Tiga tabel dibuat untuk sertifikat: tabel sertifikat baru certDBNew, tabel arsip sertifikat CertDB dan tabel sertifikat dicabut certDBRev:
. . . certdb eval {create table certDB( ckaID text primary key , nick text, sernum text, certPEM text, subject text, notAfter text, notBefore text, dateRevoke text, state text )} certdb eval {create table certDBRev( ckaID text primary key )} certdb eval {create table certDBNew( ckaID text primary key )} certdb eval {create table reqDB (ckaID text primary key, nick text, sernum text, subject text, type text, datereq text, status text, reqpem text, pkcs7 text)} certdb eval {create table reqDBAr (ckaID text primary key, nick text, sernum text, subject text, type text, datereq text, status text, reqpem text, pkcs7 text)} certdb eval {create table crlDB(ID integer primary key autoincrement, signtype text, issuer text, publishdate text, nextdate text, crlpem text)} . . .
Semua tabel permintaan dan sertifikat menggunakan
nilai hash (sha1) dari kunci publik sebagai kunci (kunci utama). Untuk kenyamanan, di masa depan, nilai hash dari nilai kunci publik akan disebut CKAID (terminologi PKCS # 11). Ini ternyata sangat nyaman, misalnya, ketika mencari sertifikat berdasarkan permintaan atau sebaliknya. Ada tabel crlDB lain di database yang menyimpan daftar sertifikat yang dicabut.
Nilai kunci publik disimpan dalam permintaan dan dalam sertifikat. Oleh karena itu, sebelum memasukkannya ke dalam basis data, perlu untuk mengekstrak kunci publik dari mereka dan menghitung CKAID. Untuk mengekstrak nilai kunci publik, akan lebih mudah untuk menggunakan paket pki (paket memerlukan pki), yang berisi alat untuk bekerja dengan sertifikat dan permintaan. Namun, paket ini tidak dirancang untuk bekerja dengan kriptografi Rusia. Dalam hal ini, berdasarkan prosedur parse_cert dan parse_csr termasuk dalam paket pki, tulis prosedur parce_cert_gost dan parse_csr_gost:
... ## Convert Pubkey type to string set pubkey_type [::pki::_oid_number_to_name $pubkey_type] # Parse public key, based on type switch -- $pubkey_type { "rsaEncryption" { set pubkey [binary format B* $pubkey] binary scan $pubkey H* ret(pubkey) ::asn::asnGetSequence pubkey pubkey_parts ::asn::asnGetBigInteger pubkey_parts ret(n) ::asn::asnGetBigInteger pubkey_parts ret(e) set ret(n) [::math::bignum::tostr $ret(n)] set ret(e) [::math::bignum::tostr $ret(e)] set ret(l) [expr {int([::pki::_bits $ret(n)] / 8.0000 + 0.5) * 8}] set ret(type) rsa } "1.2.643.2.2.19" - "1.2.643.7.1.1.1.1" - "1.2.643.7.1.1.1.2" { # gost2001, gost2012-256,gost2012-512 set pubkey [binary format B* $pubkey] binary scan $pubkey H* ret(pubkey) set ret(type) $pubkey_type ::asn::asnGetSequence pubkey_algoid pubalgost #OID - ::asn::asnGetObjectIdentifier pubalgost oid1 #OID - ::asn::asnGetObjectIdentifier pubalgost oid2 } default { error "Unknown algorithm" } } ...
Tidak seperti prosedur "asli", prosedur ini memungkinkan Anda untuk bekerja dengan objek tidak hanya dalam format PEM, tetapi juga dalam format DER. Untuk bekerja dengan daftar pencabutan sertifikat CRL, prosedur parse_crl ditulis. Semua prosedur ini dapat ditemukan dalam kode sumber, yang disimpan bersama distribusi.
Juga dalam paket pki tidak ada oid-s Rusia, misalnya, TIN, SNILS, dll. Masalah ini mudah diselesaikan dengan menambahkan oid-s Rusia ke array :: pki :: oids:
. . . set ::pki::oids(1.2.643.100.1) "OGRN" set ::pki::oids(1.2.643.100.5) "OGRNIP" set ::pki::oids(1.2.643.3.131.1.1) "INN" set ::pki::oids(1.2.643.100.3) "SNILS" # set ::pki::oids(1.2.643.2.2.3) " 34.10-2001" set ::pki::oids(1.2.643.7.1.1.3.2) " 34.10-2012-256" set ::pki::oids(1.2.643.7.1.1.3.3) " 34.10-2012-512" . . .
Memiliki fungsi parse_cert_gost dan parse_csr_gost, nilai-nilai CKAID (kunci utama untuk basis data) dihitung sebagai berikut:
. . . array set b [parse_csr_gost $req] set pem $b(pem) set subject $b(subject) set pubkey $b(pubkey) set key1 [binary format H* $pubkey] set ckaID [::sha1::sha1 $key1] . . .
Jadi, klik tombol "Buat database":
Pembuatan CA dimulai dengan pilihan direktori di mana kita akan menyimpan pengaturan basis data dan kata sandi untuk akses ke kunci pribadi CA. Utilitas CAFL63 dengan cermat memonitor panjang kata sandi:
Kata sandi disimpan dalam database CA sebagai hash:
. . . set hash256 [::sha2::sha256 $wizData(capassword)] . . .
Setelah menekan tombol "Lacak", proses pembentukan sertifikat akar yang ditandatangani sendiri dari CA yang dikerahkan dimulai. Pada langkah pertama proses ini, jenis dan parameter pasangan kunci dipilih:
Setelah memutuskan pasangan kunci untuk sertifikat root dari pusat sertifikasi yang dibuat, kami melanjutkan untuk mengisi formulir dengan informasi tentang pemilik (tangkapan layar pertama tidak ada).
Perhatikan bahwa utilitas CAFL63 memiliki "kecerdasan" tertentu dan karenanya tidak hanya mengontrol ketersediaan data di bidang, tetapi juga kebenaran (penyorotan merah - salah) dalam mengisi bidang seperti TIN, PSRN, SNILS, PSRNIP, alamat email, dll .:
Setelah mengisi kolom dengan informasi tentang pemilik CA, akan ditawarkan untuk menentukan pengaturan sistem CA:
Jika Anda tidak akan bekerja dengan kriptografi Rusia, maka Anda dapat menggunakan OpenSSL biasa. Untuk bekerja dengan kriptografi Rusia, Anda harus memilih versi yang sesuai, modifikasi OpenSSL. Untuk detail lebih lanjut, baca README.txt dalam distribusi yang diunduh. Karena rencananya akan menerbitkan sertifikat yang memenuhi syarat, maka juga perlu untuk memberikan informasi tentang sertifikasi CA itu sendiri dan sistem perlindungan informasi kriptografis yang digunakan olehnya (lihat “Persyaratan untuk Formulir Sertifikat Kualifikasi dari Kunci Verifikasi Tanda Tangan Elektronik”, yang disetujui oleh urutan Layanan Keamanan Federal Rusia tertanggal 27 Desember 2011 No. 795).
Setelah mengisi semua bidang dengan benar, sekali lagi akan ditawarkan untuk memeriksa akurasinya dan klik tombol "Selesai":
Setelah mengklik tombol "Selesai", database CA akan dibuat di mana sertifikat root CA, kunci pribadi, pengaturan sistem akan disimpan, dan halaman mulai utilitas CAFL63 akan muncul di layar lagi. Sekarang kita telah membuat database CA yang baru dibuat, kita klik tombol "Open DB", pilih direktori dengan database, pergi ke jendela kerja utama dari CA dan klik tombol "Lihat CA CA", pastikan bahwa sertifikat root yang kami buat :
Langkah selanjutnya adalah menyiapkan templat / profil aplikasi untuk badan hukum, perorangan, pengusaha perorangan (
Alat-> Pengaturan-> Jenis Sertifikat-> Baru ):
Setelah menentukan nama profil baru, akan diusulkan untuk menentukan komposisinya:
Komposisi profil ditentukan oleh nama dibedakan. Setiap profil memiliki komposisi sendiri dengan wajib (wajib) atau tidak bidang / oids. Komposisi profil untuk badan hukum, individu, pengusaha individu ditentukan oleh persyaratan Undang-Undang Federal-63 dan "Persyaratan untuk Formulir Sertifikat Kualifikasi dari Verifikasi Tanda Tangan Elektronik Kunci Sertifikat" FSB Rusia.
Setelah menyiapkan profil, CA siap menerima pelamar dan aplikasi dari mereka. Seperti disebutkan di atas, pemohon dapat datang dengan atau tanpa aplikasi yang siap untuk sertifikat.
Jika pemohon datang dengan aplikasi yang siap, maka setelah memeriksa dokumennya, aplikasi tersebut diimpor ke dalam database CA. Untuk melakukan ini, pilih tab "Permintaan Sertifikat" pada jendela kerja utama, klik tombol "Impor Permintaan / CSR", dan pilih file dengan permintaan. Setelah itu, sebuah jendela dengan informasi tentang permintaan akan muncul:
Setelah meninjau permintaan dan memastikan bahwa itu diisi dengan benar, Anda dapat mengklik tombol "Impor" untuk memasukkannya ke dalam database. Segera, kami mencatat bahwa ketika Anda mencoba membuat kembali permintaan dalam database CA, sebuah pesan akan ditampilkan:
Permintaan ke basis data CA ditandai ("Tipe" kolom) baik sebagai "Lokal" yang dibuat di pusat pendaftaran CA, atau sebagai "Impor" yang dibuat oleh pemohon sendiri, dan waktu penerimaan aplikasi di CA juga dicatat. Ini dapat berguna dalam menyelesaikan situasi konflik. Karena itu, ketika mengimpor permintaan sertifikat, Anda harus menunjukkan siapa yang membuat permintaan (lihat tangkapan layar).
Aplikasi yang diimpor terletak di database CA dan ditampilkan di jendela utama pada tab "Permintaan Sertifikat". Permintaan yang diterima berada pada tahap "pertimbangan" (kolom "Status" pada tab "Permintaan Sertifikat" dan "Arsip Permintaan"). Untuk setiap permintaan yang baru diterima, keputusan harus dibuat (menu drop-down ketika Anda mengklik kanan pada permintaan yang dipilih):
Setiap permintaan harus ditolak atau disetujui:
Jika permintaan ditolak, maka itu dipindahkan dari tabel permintaan reqDB saat ini ke tabel arsip permintaan reqDBArc dan, karenanya, menghilang pada tab "Permintaan Sertifikat" dan muncul di tab "Arsip Permintaan".
Aplikasi yang disetujui tetap berada di tabel reqDB dan pada tab "Permintaan Sertifikat" sampai sertifikat dikeluarkan, dan kemudian itu juga berakhir di arsip.
Sebelum mengeluarkan sertifikat, perlu untuk mengklarifikasi dengan pemohon untuk tujuan apa (misalnya, untuk akses ke portal Layanan Negara) sertifikat akan digunakan (
Alat-> Pengaturan-> Jenis Sertifikat -> Individu -> Edit -> Penggunaan Kunci ):
Untuk menerbitkan sertifikat, Anda harus memilih aplikasi yang disetujui pada tab "Permintaan Sertifikat", klik kanan dan pilih "Sertifikat Penerbit" di menu tarik-turun. Dalam widget yang muncul, Anda harus memilih profil yang sesuai dengan profil permintaan / sertifikat:
Perhatikan bahwa dalam proses penerbitan sertifikat, Anda dapat mengklarifikasi nilai-nilai bidang tertentu:
Prosedur untuk menerbitkan sertifikat itu sendiri (item menu "Terbitkan sertifikat") sedikit berbeda dari prosedur untuk membuat sertifikat root atau menerbitkan aplikasi:
Sertifikat yang dikeluarkan akan segera muncul di tab Sertifikat. Dalam hal ini, sertifikat itu sendiri jatuh ke dalam tabel certDBNew dari database CA dan tetap di sana sampai diterbitkan. Sertifikat dianggap diterbitkan setelah diekspor ke SQL dump sertifikat baru, yang ditransfer ke layanan publik. Menerbitkan sertifikat memindahkannya dari tabel certDBNew ke tabel certDB.
Jika Anda mengklik kanan pada baris yang dipilih di tab "Sertifikat", menu dengan fungsi berikut akan muncul:
Fungsi-fungsi ini memungkinkan Anda untuk melihat sertifikat itu sendiri dan permintaan atas dasar yang dikeluarkannya. Anda juga dapat mengekspor sertifikat ke file atau ke flash drive pelamar. Fungsi terpenting di sini adalah fungsi pencabutan sertifikat! Ada fitur eksotis seperti mengekspor sertifikat ke wadah aman # 12 PKCS. Ini digunakan ketika pelamar ingin menerima wadah seperti itu. Untuk pelamar seperti itu, fungsi pembuatan permintaan dengan menyimpan kunci pribadi dalam file disediakan secara khusus (tombol "Buat Permintaan / CSR" pada tab "Permintaan Sertifikat").
Jadi, CA memulai hidupnya, mengeluarkan sertifikat pertama. Salah satu tujuan CA adalah organisasi akses gratis ke sertifikat yang dikeluarkan. Publikasi sertifikat biasanya melalui layanan Web. CAFL63 juga memiliki layanan ini:
Untuk menerbitkan sertifikat dan daftar sertifikat yang dicabut pada layanan publik, CA pra-unggah sertifikat baik ke file (
Sertifikat-> Ekspor Sertifikat ), atau membuat SQL dump seluruh tabel sertifikat dari mana Anda dapat membuat database sertifikat dan mengunggahnya ke, dan kemudian melakukannya SQL dump sertifikat baru dari mana mereka akan ditambahkan ke database layanan publik:
Fungsi dasar CA adalah untuk menerbitkan daftar sertifikat yang dicabut, mirip dengan cara Kementerian Dalam Negeri berkenaan dengan paspor yang kedaluwarsa. Sertifikat dapat dicabut atas permintaan pemilik. Alasan utama pencabutan itu adalah hilangnya kunci pribadi atau hilangnya kepercayaan di dalamnya.
Untuk mencabut sertifikat, cukup pilih pada tab "Sertifikat", klik kanan dan pilih item menu "Pencabutan Sertifikat":
Prosedur pencabutan tidak berbeda dari prosedur persetujuan untuk permintaan atau penerbitan sertifikat. Sertifikat yang dicabut jatuh ke tabel cerDBRev dari database CA dan muncul di tab "Sertifikat dicabut".
Masih mempertimbangkan fungsi terakhir CA - pelepasan CRL - daftar sertifikat yang dicabut. Daftar CRL terbentuk pada tab "Sertifikat Dicabut" ketika Anda mengklik tombol "Buat SOS / CRL". Yang diperlukan administrator hanyalah memasukkan kata sandi CA dan mengonfirmasi niat Anda untuk mengeluarkan CRL:
CRL yang dikeluarkan jatuh ke tabel crlDB dari database dan ditampilkan pada tab CRL / SOS.
Untuk mem-parsing CRL sebelum menempatkannya dalam database, prosedur parse_crl ditulis:
proc parse_crl {crl} { array set ret [list] if { [string range $crl 0 9 ] == "-----BEGIN" } { array set parsed_crl [::pki::_parse_pem $crl "-----BEGIN X509 CRL-----" "-----END X509 CRL-----"] set crl $parsed_crl(data) } ::asn::asnGetSequence crl crl_seq ::asn::asnGetSequence crl_seq crl_base ::asn::asnGetSequence crl_base crl_full ::asn::asnGetObjectIdentifier crl_full ret(signtype) #puts "KEY_TYPE=$ret(signtype)" ::::asn::asnGetSequence crl_base crl_issue set ret(issue) [::pki::x509::_dn_to_string $crl_issue] #puts "ISSUE=$ret(issue)" ::asn::asnGetUTCTime crl_base ret(publishDate) ::asn::asnGetUTCTime crl_base ret(nextDate) #puts "publishDate=$ret(publishDate)" return [array get ret] }
Untuk melihat CRL atau mengekspornya untuk publikasi pada layanan publik, Anda harus, seperti biasa, memilih baris yang diinginkan, klik tombol mouse kanan dan pilih item menu yang sesuai:
Itu saja, Otoritas Sertifikasi siap.
Cari tahu cara merakit dan menghubungkan OpenSSL dengan kriptografi Rusia di
sini .