strongSwan: გასაღების ტიპი, ჩამტვირთავი და არასწორი backend
PEM არის კონტეინერი და არა გასაღების ტიპი. შეადარეთ სერთიფიკატის საჯარო გასაღები პირადს, შემდეგ ჩატვირთეთ იმ backend-ით, რომელიც მას ნამდვილად კითხულობს.
ფაილის გაფართოებები არ განსაზღვრავს გასაღების ალგორითმებს, და .pem გარსი შეიძლება შეიცავდეს RSA ან ECDSA მასალას. PEM აღწერს, როგორ იფარება ბაიტები, ხოლო RSA და ECDSA სხვადასხვა ალგორითმს აღნიშნავს, და PKCS12 ფაილი მესამე რამაა. strongSwan იტვირთავს მონაცემებს დანამატებისა და კონფიგურაციის backend-ის მეშვეობით, ამიტომ სერთიფიკატი შეიძლება სიაში გამოჩნდეს, მაშინ როცა პირადი გასაღები არასდროს გახდება გამოსაყენებელი. გამოყავით ეს ფენები ნებისმიერი საიდუმლოს რედაქტირებამდე.
კოდირება, ალგორითმი და შეფუთვა სამი ფენაა
გასაღების ფაილს აქვს კოდირება, ალგორითმი და ხშირად კონტეინერი. PEM ნაცნობი base64 გარსია; DER მისი ბინარული შესატყვისია; PKCS12 აერთიანებს სერთიფიკატს მის გასაღებსა და ჯაჭვთან. სერთიფიკატების ჯაჭვის ფაილი კიდევ ერთი კონტეინერია და ჩვეულებრივ საერთოდ არ შეიცავს პირად გასაღებს. ამ წარწერებიდან არცერთი არ ამბობს, შიგნით RSA-ია თუ ECDSA.
წაიკითხეთ ალგორითმი თავად ობიექტიდან. მომწოდებლის მარკეტინგული სახელი ან ფაილის გაფართოება მტკიცებულება არ არის, რადგან ერთი და იგივე გამომცემელს შეუძლია სხვადასხვა ტიპის გასაღები გასცეს.
შეადარეთ საჯარო გასაღებები სანამ ჩამტვირთავს დაადანაშაულებთ
ჩატვირთული სერთიფიკატი ამტკიცებს, რომ სერთიფიკატი გაანალიზდა, და არა ის, რომ მისი პირადი გასაღები არსებობს ან გამოსადეგია. გამოიყვანეთ საჯარო გასაღები სერთიფიკატიდან და შემოთავაზებული პირადი გასაღებიდან, შემდეგ შეადარეთ ორი დაიჯესტი. თუ რომელიმე ამოღება ვერ მოხდა, იქ გაჩერდით, რადგან ცარიელი გამონატანის დაიჯესტი არაფერს ამტკიცებს. დამთხვევა დაიჯესტები ამტკიცებს, რომ წყვილი ერთადაა, და მეტს არაფერს იმაზე, ვარგისია თუ არა სერთიფიკატი საქმისთვის.
openssl x509 -in server.crt -pubkey -noout |
openssl pkey -pubin -outform DER |
openssl dgst -sha256
openssl pkey -in server-key.pem -pubout -outform DER |
openssl dgst -sha256
მეორე ბრძანება ეხება თქვენს მანქანაში არსებულ პირად მასალას, მაგრამ გამოსცემს მხოლოდ საჯარო ნახევარს. ასე დატოვეთ და არასდროს ჩასვათ პირადი გასაღები ბილეთში. თუ გასაღები დაშიფრულია, ნება მიეცით მხარდაჭერილ ხელსაწყოს ჰკითხოს პაროლი, ნაცვლად ბრძანების სტრიქონზე დადებისა, სადაც პროცესების სია მას გამოავლენს.
ძველი ipsec.secrets ან swanctl მონაცემები
strongSwan-ს აქვს მონაცემების ორი ხშირად გამოყენებული გზა. ძველი starter სტეკი კითხულობს ტიპის მიხედვით სპეციფიკურ ჩანაწერებს ipsec.secrets-დან, და თითოეულმა ჩანაწერმა უნდა მიუთითოს მასალისთვის სწორი ტიპი. swanctl და vici სტეკი გასაღებებს თავისი მონაცემების საქაღალდიდან თავისი კონფიგურაციით ტვირთავს. იმ ფაილის რედაქტირება, რომელსაც გაშვებული backend არ კითხულობს, არაფერს ცვლის.
: ECDSA "/etc/ipsec.d/private/server-key.pem"
გაარკვიეთ რომელი backend მუშაობს სინამდვილეში, შემდეგ გასაღები იქ მოათავსეთ, სადაც ის backend იხედება. strongSwan 5.9 ძველი სახელმძღვანელო განსაზღვრავს ტიპის მიხედვით სპეციფიკურ საიდუმლო ჩანაწერებს და ეს swanctl დოკუმენტაცია არ არის. ორივეს შერევა ქმნის daemon-ს, რომელიც უგულებელყოფს ფაილს, რომელსაც ადმინისტრატორი ავტორიტეტულად მიიჩნევს. გადატვირთვა, რომელიც შეცდომას არ იუწყება, მხოლოდ იმას ნიშნავს, რომ კონფიგურაცია გაანალიზდა.
წაიკითხეთ ჩატვირთვის მოვლენა და ავთენტიფიკაციის შედეგი
კონტროლირებული გადატვირთვის შემდეგ წაიკითხეთ daemon-ის საკუთარი ჩატვირთვის გამონატანი კონკრეტული გასაღებისთვის. სტატუსის დამპში ჩამოთვლილი სერთიფიკატი არ აჩვენებს, რომ პირადი გასაღები მას შეესაბამა.
თუ კლიენტი კვლავ ვერ ახერხებს, გამოყავით სერვერის მოვლენა და კლიენტის შეცდომა. ჯაჭვის ვალიდაცია, იდენტობის შედარება და მეთოდების თავსებადობა შემდგომი კითხვებია საკუთარი მტკიცებულებებით. ჩაწერეთ შედეგი გასაღების ზუსტი ბილიკით და იმ დაიჯესტით, რომელიც შეადარეთ, თორემ შემდეგი ცვლა იმავე გადატვირთვას გაიმეორებს. CA-ს შეცვლა ჩამტვირთავის შეუსაბამობაზე პირველი რეაქცია არ არის.