Rutoken ტექნოლოგიის გამოყენების გამოცდილება სისტემაში მომხმარებლების რეგისტრაციისა და ავტორიზაციისთვის (ნაწილი 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 - გზა root სერტიფიკატისკენ. (ამის გარეშე ბრძანება არ მუშაობდა, თუმცა 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 და ვამოწმებთ ამ მონაცემებს ვალიდობისთვის. ზუსტად რა უნდა შემოწმდეს აღწერილია პირველ სტატიაში. თუ მონაცემები სწორია, მაშინ მომხმარებლის ავტორიზაცია წარმატებულად ითვლება.

ამ ალგორითმების განსახორციელებლად, შეგიძლიათ გამოიყენოთ ნებისმიერი პროგრამირების ენა, რომელიც გამოიყენება backend-ის დასაწერად.

შემდეგ სტატიაში განვიხილავთ როგორ ვიმუშაოთ Retoken მოდულით.

დიდი მადლობა!

წყარო: www.habr.com