როგორ შევქმნათ VPN კლიენტის გასაღები და როგორ ჩავაბაროთ CSR ხელმოწერისთვის

ადრე თუ გვიან VPN-ის მომხმარებელი შესთავაზებს პირადი გასაღების ელფოსტით გაგზავნას, რათა ადმინისტრატორმა სერტიფიკატი შექმნას, და სწორედ ეს შეთავაზება უნდა უარვყოთ. მუშა პროცესი გასაღებს კლიენტთან ინახავს პირველივე ბრძანებიდან: კლიენტი ქმნის მას, აგზავნის სერტიფიკატის ხელმოწერის მოთხოვნას, გამომცემელი ამოწმებს და აძლევს უფლებას, ხოლო ხელმოწერილი სერტიფიკატი ბრუნდება, რომ იმ გასაღების გვერდით დადგეს, რომელმაც ის შექმნა. ქვემოთ მოცემული ჩამონათვალი ყოველ ნაბიჯზე დახურულად ვარდება და ესაა აზრი, რადგან ხუთი ნაბიჯიდან ორი სწორედ ის ნაბიჯებია, რომლებსაც ადამიანები გამოტოვებენ, როცა ჩქარობენ.

ნაბიჯი 1: შექმენით გასაღები იქ, სადაც ის იცხოვრებს

შექმენით იმ მანქანაზე, რომელიც გასაღებს შეინახავს და იქვე დატოვეთ. პროგრამული გასაღები მკაცრი უფლებების მქონე ფაილში იწერება; ტექნიკით მხარდაჭერილი ან მართულ საცავში მყოფი გასაღები არასდროს ხდება ფაილი, და მისი რეგისტრაციის გზა ჩვეულებრივ ცალკე ინსტრუმენტია და არა OpenSSL-ის ბრძანება. ყოველ შემთხვევაში, არავის სჭირდება პირადი ნახევრის ნახვა.

პროგრამული პროცესი ასე გამოიყურება, გასაღები და მოთხოვნა ერთ სესიაში იქმნება:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

umask სტრიქონი უფრო მნიშვნელოვანია, ვიდრე ჩანს. მის გარეშე გასაღები იწერება ყველასთვის წაკითხვად სისტემაზე, რომელიც ნაგულისხმევად ნებადართულია, და ფაილის მოგვიანებით კოპირება ამას ავრცელებს. არსებული გასაღების ხელახლა გამოყენება ლეგიტიმურია, როცა ის უკვე დაცულია და თქვენს პოლიტიკას შეესაბამება; თითოეული მოწყობილობისთვის ახლის შექმნა უფრო ადვილი დასაბუთებელია.

ნაბიჯი 2: ჩადეთ იდენტობა მოთხოვნაში და არა ელფოსტაში

გადაწყვიტეთ, რას ამოწმებს VPN სინამდვილეში, სანამ მოთხოვნა შეიქმნება, რადგან ეს პასუხი CSR-ის შიგნით ეკუთვნის. OpenVPN ტრადიციულად კლიენტის იდენტობას სერტიფიკატის საერთო სახელს უკავშირებს, და ისეთი ინსტრუმენტები, როგორიც strongSwan-ია, იდენტობის სტრიქონს სუბიექტს ან სუბიექტის ალტერნატიულ სახელს უდარებენ. ელფოსტა, რომელიც ამბობს, რომ ჩემი სახელი alice-ია, მტკიცებულება არ არის, და მოთხოვნა, რომლის სუბიექტიც იგივეს ამბობს, მხოლოდ ოდნავ უკეთესია.

დაამატეთ სუბიექტის ალტერნატიული სახელი, როცა თქვენი შემმოწმებელი მას ამოწმებს, რადგან თანამედროვე შედარება ხშირად უგულებელყოფს ძველ CN-ს:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

შეინახეთ CN მოკლე, სტაბილური და ანგარიშზე მიბმული და არა ლეპტოპის მოდელზე. სახელი, რომელიც მომხმარებლის მოწყობილობის სერიულ ნომერს შეიცავს, მხარდაჭერის პრობლემაა, რომელიც პირველ ტექნიკის შეცვლას ელოდება.

ნაბიჯი 3: გადაამოწმეთ მოთხოვნა ხელმოწერამდე

გამომცემელი ორ სხვადასხვა რამეს ამოწმებს და მათი არევა კლასიკური შეცდომაა. პირველი, რომ მოთხოვნა შიდად თანმიმდევრულია: ხელმოწერა მოწმდება იმ საჯარო გასაღების მიმართ, რომელსაც ის ატარებს. მეორე, რომ მომთხოვნს უფლება აქვს იმაზე, რასაც მოთხოვნა ითხოვს, და ამაზე ვერც ერთი კრიპტოგრაფიული შემოწმება ვერ უპასუხებს.

მექანიკური ნაწილი ერთი ბრძანებაა და მან სუბიექტთან ერთად უნდა დაბეჭდოს შემოწმების შედეგი:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

ყურადღება მიაქციეთ, რას ამტკიცებს ეს. შემოწმებული მოთხოვნა მხოლოდ იმას აჩვენებს, რომ გამომგზავნს წარდგენის მომენტში შესაბამისი პირადი გასაღები ჰქონდა; ის არ ამტკიცებს, რომ გამომგზავნი სუბიექტში დასახელებული პირია, და არ ანიჭებს უფლებას მოთხოვნილ ჯგუფზე ან მარშრუტზე წვდომაზე. რეგისტრაციის განხილვა ცალკე კარიბჭეა, და ჯგუფის მოთხოვნა, რომელიც არავის დაუმტკიცებია, უნდა უარყოფილ იქნას და არა ჩუმად შესწორებულ იქნას.

ნაბიჯი 4: უფლება მიეცით, შემდეგ მოაწერეთ ხელი გამოკვეთილი გაფართოებებით

ხელმოწერა ის ადგილია, სადაც CA პოლიტიკას წყვეტს და არა მოთხოვნას სიტყვასიტყვით იღებს. ვალიდობა, გასაღების გამოყენება და როლის გაფართოება გაფართოებების ფაილში ეკუთვნის და არა ნაგულისხმევ მნიშვნელობებში, რომლებსაც ექვსი თვის შემდეგ ვერ გაიხსენებთ. VPN-ის ავთენტიფიკაციის კლიენტის სერტიფიკატს მიზნად კლიენტის ავთენტიფიკაცია სჭირდება.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

გამოიყენეთ -CAserial არსებულ სერიულ ფაილთან ერთად, თუ ერთი უკვე გამოიყენება, და შეინახეთ CA-ს გასაღები ოფლაინ ან იმ დაცულ საცავში, რომელსაც თქვენი პოლიტიკა ასახელებს. სერტიფიკატების სერიული ნომრები უნიკალური უნდა იყოს თითოეული გამომცემლისთვის; სერიული ფაილის ნულიდან ხელახლა შექმნა რისკავს შეჯახებებს, რომლებიც გაუქმებას ორაზროვანს ხდის.

ჩაწერეთ, რა გაიცა: სერიული ნომერი, სუბიექტი, მოთხოვნილი იდენტობა, დამამტკიცებელი პირი და ვადა. სწორედ ამ ჩანაწერს ეყრდნობა მოგვიანებით გაუქმების გადაწყვეტილება, და მისი აღდგენა მხოლოდ სერტიფიკატიდან შეუძლებელია, თუ რეგისტრაციის კვალი მხოლოდ საფოსტო ყუთში ცხოვრობს.

ნაბიჯი 5: დააყენეთ ის შესაბამისი გასაღების გვერდით და დაამტკიცეთ წყვილი

კლიენტი იღებს სერტიფიკატს და გამომცემლის ჯაჭვს, არასდროს გასაღებს. დაკავშირებამდე დაადასტურეთ, რომ სერტიფიკატი ნამდვილად წყვილდება დისკზე უკვე არსებულ გასაღებთან, რადგან შეუსაბამო წყვილი გაცილებით გვიან წარმოქმნის დამაბნეველ ხელის ჩამორთმევის წარუმატებლობას:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

ორი დაიჯესტი უნდა დაემთხვეს. შემდეგ დაუკავშირდით და დაადასტურეთ, რომ სერვერის მიერ ჩაწერილი იდენტობა თქვენს მიერ უფლებამოსილია და არა უბრალოდ ის, რომ გვირაბი ამოვიდა. თუ გასაღები დაიკარგება ან მოწყობილობა შეიცვლება, პასუხია გაუქმება პლუს ახალი მოთხოვნა ახალი მოწყობილობიდან; ადმინისტრატორს სთხოვოთ გასაღების სხვა ადგილიდან უკან გამოგზავნა არ აღადგენს ორიგინალს და ჩუმად ტეხავს მოდელს, რომელიც მოთხოვნას უსაფრთხოს ხდიდა.