Вопыт прымянення тэхналогіі Рутокен для рэгістрацыі і аўтарызацыі карыстальнікаў у сістэме (частка 3)

Добры дзень!

У папярэдняй частцы мы паспяхова стварылі свой які сведчыць цэнтр. Чым наогул для нашых мэт ён можа быць карысны?

З дапамогай лакальнага цэнтра пацверджання мы можам рабіць выдачу сертыфікатаў, а таксама ажыццяўляць праверку подпісу па гэтых сертыфікатах.

Пры выдачы сертыфіката карыстальніку які сведчыць цэнтр выкарыстоўвае спецыяльны запыт на выдачу сертыфіката Pkcs#10, які мае фармат файла '.csr'. Гэты запыт змяшчае закадаваную паслядоўнасць, якую які сведчыць цэнтр ведае, як правільна распарсіць. Запыт змяшчае як публічны ключ карыстальніка, так і дадзеныя для стварэння сертыфіката (асацыятыўны масіў з дадзенымі аб карыстачу).

Якім чынам атрымаць запыт на выдачу сертыфіката, мы разгледзім у наступным артыкуле, а ў гэтым хачу прывесці асноўныя каманды які сведчыць цэнтра, якія дапамогуць нам выканаць нашу задачу на боку бэкенда.

Дык вось, спачатку мы павінны стварыць сертыфікат. Для гэтага выкарыстоўваем каманду:

openssl ca -batch -in user.csr -out user.crt

ca — каманда openSSL, якая адносіцца да сведчання,
-batch - адмяняе запыты пацверджання пры фарміраванні сертыфіката.
user.csr - запыт на стварэнне сертыфіката (файл фармату .csr).
user.crt - сертыфікат (атрыманы вынік каманды).

Для таго, каб гэтая каманда адпрацавала, які сведчыць цэнтр павінен быць наладжаны ў дакладнасці так, як апісана у папярэдняй частцы артыкула. У адваротным выпадку давядзецца дадаткова ўказваць месца размяшчэння каранёвага сертыфіката які сведчыць цэнтра.

Каманда праверкі сертыфіката:

openssl cms -verify -in authenticate.cms -inform PEM -CAfile /Users/……/demoCA/ca.crt -out data.file

cms - каманда openSSL, якая выкарыстоўваецца для подпісу, праверкі, шыфравання дадзеных і іншых крыптаграфічных аперацый з дапамогай openSSL.

-verify - у дадзеным выпадку ажыццяўляем праверку сертыфіката.

authenticate.cms - файл, які змяшчае падпісаныя дадзеныя сертыфікатам, які быў выдадзены папярэдняй камандай.

-inform PEM - выкарыстоўваецца фармат PEM.

-CAfile /Users/……/demoCA/ca.crt – шлях да каранёвага сертыфіката. (без гэтага ў мяне каманда не спрацавала, хоць і прапісаны шляхі да ca.crt у файле openssl.cfg)

-out data.file - расшыфраваныя дадзеныя адпраўляю ў файл data.file.

Алгарытм прымянення які сведчыць цэнтра на баку бэкенда наступны:

• Рэгістрацыя карыстальніка:
  1. Атрымліваем запыт на стварэнне сертыфіката і захоўваем яго ў файл user.csr.
  2. Захоўваем першую каманду дадзенага артыкула ў файл пашырэннем .bat ці .cmd. Запускаем гэты файл з кода, папярэдне захаваўшы запыт на стварэнне сертыфіката ў файл user.csr. Атрымліваем файл з сертыфікатам user.crt.
  3. Чытаем файл user.crt і адпраўляем яго на кліент.

• Аўтарызацыя карыстальніка:
  1. Атрымліваем падпісаныя дадзеныя з кліента і захоўваем іх у файл authenticate.cms.
  2. Захоўваем другую каманду дадзенага артыкула ў файл пашырэннем .bat ці .cmd. Запускаем гэты файл з кода, папярэдне захаваўшы падпісаныя дадзеныя з сервера ў authenticate.cms. Атрымліваем файл з расшыфраванымі дадзенымі data.file.
  3. Чытэльны data.file і правяраем гэтыя дадзеныя на валіднасць. Што менавіта праверыць апісана у першым артыкуле. Калі дадзеныя валідныя, то аўтарызацыя карыстальніка лічыцца паспяховай.

Для рэалізацыі гэтых алгарытмаў можна выкарыстоўваць любую мову праграмавання, якую выкарыстоўваюць для напісання бэкенда.

У наступным артыкуле мы будзем разбірацца з тым, як працаваць з Рэтакен убудовай.

Дзякуй за ўвагу!

Крыніца: habr.com