შეინახეთ თქვენი VPN-ის ძირეული CA ოფლაინში და მაინც გასცეთ სერტიფიკატები

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

რას ამოწმებს კავშირი სინამდვილეში

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

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

ააგეთ ძირი ჰოსტზე, რომელიც არასდროს იღებს მისამართს

ოფლაინ ძირი იშვიათად გამოიყენება: შუამავალი CA-ის სერტიფიკატის ხელმოსაწერად და მოგვიანებით მის განსაახლებლად ან გასაუქმებლად. დანარჩენი ყველაფერი ერთი დონით ქვემოთ ხდება. ძირის სამუშაო შეასრულეთ ქსელიდან მოშორებულ მანქანაზე, თუ შესაძლებელია ცოცხალი სისტემიდან, და ჩაიწერეთ ვინ იყო ოთახში. ბრძანებები ითვალისწინებს OpenSSL 1.1.1 ან უფრო ახალს, რადგან -addext ძველ ნაგებობებში არ არის.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out root.key
openssl req -x509 -new -key root.key -sha256 -days 7300 \
  -subj "/CN=Example VPN Root CA" -out root.crt \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

შექმენით შუამავალი ხელმოწერის ჰოსტზე და მხოლოდ მისი მოთხოვნა წაიღეთ ოფლაინ მანქანაზე. ძირი ხელს აწერს ამ მოთხოვნას ნულოვანი ბილიკის სიგრძით, ამიტომ შუამავალ CA-ს შეუძლია საბოლოო სერტიფიკატების ხელმოწერა, მაგრამ არ შეუძლია თავის ქვეშ სხვა CA-ის შექმნა. ეს ერთი გაფართოება ხელს უშლის კომპრომეტირებულ ხელმოწერის ჰოსტს შექმნას ძირის ეკვივალენტური უფლება. გამოიყენეთ ECDSA მხოლოდ მაშინ, თუ ყველა კლიენტი OpenVPN 2.4 ან უფრო ახალს უშვებს; წინააღმდეგ შემთხვევაში შექმენით RSA გასაღებები და შეინარჩუნეთ იგივე დინება.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out intermediate.key
openssl req -new -key intermediate.key -subj "/CN=Example VPN Intermediate CA" -out intermediate.csr
openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key \
  -CAcreateserial -days 3650 -sha256 -extfile intermediate.ext -out intermediate.crt

intermediate.ext შეიცავს basicConstraints=critical,CA:TRUE,pathlen:0, keyUsage=critical,keyCertSign,cRLSign და authorityKeyIdentifier=keyid:always. დააბრუნეთ ძირეული გასაღები სეიფში, სანამ ხელმოწერის ჰოსტი ხელახლა დაუკავშირდება. თუ ძირმა უნდა შეძლოს შუამავალის გაუქმება, მოაწერეთ მას ხელი openssl ca -config root.cnf -extensions intermediate_ca-ით ძირეული დონის index.txt-ის წინააღმდეგ openssl x509 -req-ის ნაცვლად, რათა სერიული ნომერი ჩაიწეროს; შემდეგ გაგზავნეთ მიღებული ძირეული სია კლიენტის პროფილში, სადაც ფაილზე დაფუძნებული crl-verify კითხულობს მას გაშვებისას. გაუგზავნეთ კლიენტებს პაკეტი ორივე CA სერტიფიკატით; მხოლოდ ფოთოლი ძირის წინააღმდეგ არ დადასტურდება.

გასცეთ ფოთლები შუამავალიდან, მონაცემთა ბაზით

openssl x509 -req-ით ხელმოწერა მუშაობს მანამ, სანამ გაუქმება დაგჭირდებათ, რადგან არაფერი იწერს სერიულ ნომერს. გამოიყენეთ openssl ca პირველი სერტიფიკატიდან, რათა სერიული ნომერი, ვადა და გაუქმების მდგომარეობა ერთ ბაზაში იცხოვროს. შექმენით ბაზის ფაილები ერთხელ, შემდეგ მიმართეთ კონფიგურაცია მათკენ:

mkdir -p /etc/vpn-ca/intermediate/newcerts
touch /etc/vpn-ca/intermediate/index.txt
echo 1000 > /etc/vpn-ca/intermediate/serial
echo 1000 > /etc/vpn-ca/intermediate/crlnumber

[ ca ]
default_ca = CA_default
[ CA_default ]
dir = /etc/vpn-ca/intermediate
database = $dir/index.txt
new_certs_dir = $dir/newcerts
serial = $dir/serial
crlnumber = $dir/crlnumber
certificate = $dir/intermediate.crt
private_key = $dir/intermediate.key
default_md = sha256
default_days = 365
default_crl_days = 30
unique_subject = no
policy = policy_any
[ policy_any ]
commonName = supplied
[ server_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @server_names
[ client_cert ]
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
[ server_names ]
DNS.1 = vpn.example.com

გასაღების გამოყენების ხაზი ECDSA გასაღებს გულისხმობს; RSA-სთვის დაამატეთ keyEncipherment. მიეცით თითოეულ კლიენტს საკუთარი საერთო სახელი, რადგან OpenVPN ამ ველით ამოიცნობს კავშირს, და CN=vpn-client-ის მქონე ორი ლეპტოპი ვერ გაირჩევა ლოგებში, client-config-dir-ის წესებში ან რომელიმე მომხმარებლობრივ push-ში, და კარგავთ იმ მიკუთვნებას, რომელიც გაუქმების გადაწყვეტილებას დასაცავს ხდის. გასცეთ და შეამოწმეთ ფოთოლი ასე:

openssl req -new -key alice.key -subj "/CN=alice-laptop" -out alice.csr
openssl ca -config intermediate.cnf -extensions client_cert -in alice.csr -out alice.crt -batch
openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt alice.crt

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

გამოაქვეყნეთ გაუქმება ძირის გაღვიძების გარეშე

კლიენტის სერტიფიკატებს აუქმებს შუამავალი, არასდროს ძირი. ძირეული სია მნიშვნელოვანია მხოლოდ მაშინ, როცა შუამავალი დაიწვა. მიმართეთ სერვერი შუამავალ სიაზე crl-verify-ით. ფაილზე დაფუძნებული CRL იტვირთება სერვისის გაშვებისას, ამიტომ თითოეული რეგენერაციის შემდეგ ხელახლა ჩატვირთეთ; დირექტორიის ფორმა კითხულობს მდგომარეობას დაკავშირებისას და ხარჯავს ერთ ფაილს სერიულ ნომერზე.

გააუქმეთ და ხელახლა შექმენით ორი ბრძანებით იმავე ბაზიდან:

openssl ca -config intermediate.cnf -revoke /etc/vpn-ca/intermediate/newcerts/1001.pem
openssl ca -config intermediate.cnf -gencrl -out /etc/openvpn/crl.pem

შემდეგ დააკვირდით საათს. CRL ატარებს შემდეგი განახლების ველს, და როცა ეს თარიღი გავა, შემმოწმებელი მხარე უარყოფს სიას, ნაცვლად იმისა, რომ უგულებელყოს იგი. default_crl_days = 30-ით ყოველთვიური რეგენერაცია ტოვებს ზღვარს; წლიური არა. ფოთლების უფრო მოკლე სიცოცხლე უფრო საიმედო კონტროლია, რადგან გაუქმება მოქმედებს მხოლოდ იქ, სადაც სიას ამოწმებენ.

შეამოწმეთ ჯაჭვი, შემდეგ ჩაწერეთ ცერემონია

სანამ დიზაინს ენდობით, გაამრავლეთ ოთხი მარცხი. შეამოწმეთ ჯაჭვი openssl verify -CAfile ca-bundle.crt -untrusted intermediate.crt server.crt-ით. დაუკავშირდით ვადაგასული კლიენტის სერტიფიკატით და დაადასტურეთ, რომ სერვერი უარყოფს მას. გააუქმეთ სატესტო კლიენტი, ხელახლა ჩატვირთეთ და დაადასტურეთ, რომ სია ძალაში შედის. წაიწიეთ ჰოსტის საათი ერთი დღით წინ, რადგან არასწორი საათი შეიძლება გასცეს და უარყოს სერტიფიკატები, რომლებიც სხვაგან ვალიდურად გამოიყურება.

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

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