Kung paano ang lahat ng ito ay nagsimula
Sa simula pa lamang ng panahon ng pag-iisa sa sarili, nakatanggap ako ng liham sa koreo:
Ang unang reaksyon ay natural: kailangan mong kumuha ng mga token, o kailangan mong dalhin ang mga ito, ngunit mula noong Lunes ay nakaupo na kaming lahat sa bahay, may mga paghihigpit sa paggalaw, at sino ang impiyerno na iyon? Samakatuwid, ang sagot ay medyo natural:
At tulad ng alam nating lahat, mula Lunes, Abril 1, nagsimula ang isang panahon ng medyo mahigpit na pag-iisa sa sarili. Lumipat din kaming lahat sa malayong trabaho at kailangan din namin ng VPN. Ang aming VPN ay batay sa OpenVPN, ngunit binago upang suportahan ang Russian cryptography at ang kakayahang magtrabaho sa mga PKCS#11 token at PKCS#12 container. Naturally, lumabas na kami mismo ay hindi pa handa na magtrabaho sa pamamagitan ng VPN: marami ang walang mga sertipiko, at ang ilan ay nag-expire na.
Paano napunta ang proseso?
At ito ay kung saan ang utility ay dumating upang iligtas at aplikasyon (Sentro ng pagpapatunay).
Pinahintulutan ng cryptoarmpkcs utility ang mga empleyado na nakahiwalay sa sarili at may mga token sa kanilang mga computer sa bahay na bumuo ng mga kahilingan sa sertipiko:
Ang mga empleyado ay nagpadala ng mga naka-save na kahilingan sa pamamagitan ng email sa akin. Maaaring may magtanong: - Paano ang tungkol sa personal na data, ngunit kung titingnan mong mabuti, wala ito sa kahilingan. At ang kahilingan mismo ay protektado ng lagda nito.
Sa pagtanggap, ang kahilingan sa sertipiko ay na-import sa CAFL63 CA database:
Pagkatapos nito, ang kahilingan ay dapat tanggihan o maaprubahan. Upang isaalang-alang ang isang kahilingan, kailangan mong piliin ito, i-right-click at piliin ang "Magpasya" mula sa drop-down na menu:
Ang mismong pamamaraan ng paggawa ng desisyon ay ganap na transparent:
Ang isang sertipiko ay ibinibigay sa parehong paraan, tanging ang item sa menu ay tinatawag na "Issue certificate":
Upang tingnan ang ibinigay na sertipiko, maaari mong gamitin ang menu ng konteksto o i-double click lamang sa kaukulang linya:
Ngayon ang nilalaman ay maaaring matingnan pareho sa pamamagitan ng openssl (OpenSSL Text tab) at ang built-in na viewer ng CAFL63 application (Certificate Text tab). Sa huling kaso, maaari mong gamitin ang menu ng konteksto upang kopyahin ang certificate sa text form, una sa clipboard, at pagkatapos ay sa isang file.
Dito dapat tandaan kung ano ang nagbago sa CAFL63 kumpara sa unang bersyon? Tulad ng para sa pagtingin sa mga sertipiko, nabanggit na namin ito. Naging posible rin na pumili ng isang pangkat ng mga bagay (mga sertipiko, kahilingan, CRL) at tingnan ang mga ito sa paging mode (ang "Tingnan ang napiling ..." na buton).
Marahil ang pinakamahalagang bagay ay ang proyekto ay malayang magagamit sa . Bilang karagdagan sa mga pamamahagi para sa Linux, ang mga pamamahagi para sa Windows at OS X ay inihanda. Ang pamamahagi para sa Android ay ilalabas sa ibang pagkakataon.
Kung ikukumpara sa nakaraang bersyon ng application ng CAFL63, hindi lamang ang interface mismo ang nagbago, kundi pati na rin, tulad ng nabanggit na, ang mga bagong tampok ay naidagdag. Halimbawa, ang page na may paglalarawan ng application ay muling idinisenyo at ang mga direktang link sa pag-download ng mga distribusyon ay naidagdag:
Marami ang nagtanong at nagtatanong pa kung saan kukuha ng GOST openssl. Tradisyonal na nagbibigay ako , mabait na ibinigay . Kung paano gamitin ang openssl na ito ay nakasulat .
Ngunit ngayon ang mga distribution kit ay may kasamang pansubok na bersyon ng openssl na may Russian cryptography.
Samakatuwid, kapag nagse-set up ng CA, maaari mong tukuyin ang alinman sa /tmp/lirssl_static para sa Linux o $::env(TEMP)/lirssl_static.exe para sa Windows bilang openssl na ginamit:
Sa kasong ito, kakailanganin mong lumikha ng walang laman na lirssl.cnf file at tukuyin ang path sa file na ito sa environment variable na LIRSSL_CONF:
Ang tab na "Mga Extension" sa mga setting ng certificate ay dinagdagan ng field na "Authority Info Access", kung saan maaari kang magtakda ng mga access point sa CA root certificate at sa OCSP server:
Madalas nating marinig na ang mga CA ay hindi tumatanggap ng mga kahilingang ginawa nila (PKCS#10) mula sa mga aplikante o, mas masahol pa, pinipilit ang pagbuo ng mga kahilingan sa pagbuo ng key pair sa carrier sa pamamagitan ng ilang CSP. At tumanggi silang bumuo ng mga kahilingan sa mga token na may hindi makukuhang key (sa parehong RuToken EDS-2.0) sa pamamagitan ng interface ng PKCS#11. Samakatuwid, napagpasyahan na magdagdag ng pagbuo ng kahilingan sa functionality ng CAFL63 application gamit ang mga cryptographic na mekanismo ng PKCS#11 token. Upang paganahin ang mga mekanismo ng token, ginamit ang package . Kapag gumagawa ng kahilingan sa isang CA (pahinang "Mga kahilingan para sa mga sertipiko", function na "Gumawa ng kahilingan/CSR") maaari mo na ngayong piliin kung paano bubuo ang key pair (gamit ang openssl o sa isang token) at ang kahilingan mismo ay lalagdaan:
Ang library na kinakailangan upang gumana sa token ay tinukoy sa mga setting para sa sertipiko:
Ngunit lumihis kami mula sa pangunahing gawain ng pagbibigay sa mga empleyado ng mga sertipiko upang magtrabaho sa isang corporate VPN network sa self-isolation mode. May mga empleyado pala na walang token. Napagpasyahan na bigyan sila ng PKCS#12 protected container, dahil pinapayagan ito ng CAFL63 application. Una, para sa mga naturang empleyado gumawa kami ng mga kahilingan sa PKCS#10 na nagsasaad ng uri ng CIPF na "OpenSSL", pagkatapos ay nag-iisyu kami ng certificate at naka-package ito sa PKCS12. Upang gawin ito, sa pahina ng βMga Sertipiko,β piliin ang gustong certificate, i-right-click at piliin ang βI-export sa PKCS#12β:
Upang matiyak na ang lahat ay maayos sa lalagyan, gamitin natin ang cryptoarmpkcs utility:
Maaari ka na ngayong magpadala ng mga ibinigay na sertipiko sa mga empleyado. Ang ilang mga tao ay pinadalhan lang ng mga file na may mga certificate (ito ang mga may-ari ng token, ang mga nagpadala ng mga kahilingan), o mga container ng PKCS#12. Sa pangalawang kaso, ang bawat empleyado ay binibigyan ng password sa lalagyan sa pamamagitan ng telepono. Kailangan lang itama ng mga empleyadong ito ang configuration file ng VPN sa pamamagitan ng wastong pagtukoy sa path patungo sa container.
Para naman sa mga may-ari ng token, kailangan din nilang mag-import ng certificate para sa kanilang token. Upang gawin ito, ginamit nila ang parehong cryptoarmpkcs utility:
Ngayon ay may kaunting mga pagbabago sa VPN config (ang label ng sertipiko sa token ay maaaring nagbago) at iyon lang, ang corporate VPN network ay gumagana.
Maligayang pagtatapos
At pagkatapos ay naisip ko, bakit ang mga tao ay magdadala ng mga token sa akin o dapat akong magpadala ng isang mensahero para sa kanila. At nagpapadala ako ng liham na may sumusunod na nilalaman:
Ang sagot ay darating sa susunod na araw:
Agad akong nagpadala ng link sa cryptoarmpkcs utility:
Bago gumawa ng mga kahilingan sa certificate, inirerekomenda ko na i-clear nila ang mga token:
Pagkatapos ay ipinadala sa pamamagitan ng email ang mga kahilingan para sa mga sertipiko sa format na PKCS#10 at nagbigay ako ng mga sertipiko, na ipinadala ko sa:
At pagkatapos ay dumating ang isang masayang sandali:
At mayroon ding sulat na ito:
At pagkatapos nito ay ipinanganak ang artikulong ito.
Ang mga distribusyon ng CAFL63 application para sa Linux at MS Windows platform ay matatagpuan
dito
Ang mga distribusyon ng cryptoarmpkcs utility, kabilang ang Android platform, ay matatagpuan
dito
Pinagmulan: www.habr.com