ძველი P12 OpenSSL 3-ზე ვერ მუშაობს: არასწორი პაროლი თუ მოძველებული შიფრი?
განასხვავეთ არასწორად აკრეფილი პაროლის ფრაზა ძველი RC2 პაკეტისგან, რომლის გახსნაზეც OpenSSL 3 უარს ამბობს, და შემდეგ ხელახლა დალუქეთ ფაილი გასაღების დაცვის მოხსნის გარეშე.
იმპორტის დიალოგი იღებს თქვენს პაროლს, ტრიალებს წამით და შემდეგ ამბობს, რომ პაკეტს ვერ კითხულობს. ამ შეტყობინებაში არაფერი გეუბნებათ, არასწორად აკრიფეთ პაროლის ფრაზა თუ ფაილი იმ შიფრით არის დალუქული, რომელსაც კლიენტი აღარ აწვდის. ეს სხვადასხვა ხარვეზია სხვადასხვა გამოსწორებით და არასწორი არჩევანი იწვევს კლიენტის ვერსიის დაწევას, რაც მხოლოდ გადადებს გადაწყვეტილებას. იმ ეტაპზე დაკვირვება, სადაც კლიენტი ჩერდება, გამოყოფს მათ დაახლოებით ერთ წუთში.
რა ხდება დიალოგსა და სერტიფიკატების სიას შორის
.p12 ფაილი კონტეინერია და არა სერტიფიკატი. შიგნით არის ერთი ან რამდენიმე სერტიფიკატის ტომარა და პირადი გასაღების ტომარა, რომელიც დაშიფრულია თქვენი პაროლიდან მიღებული გასაღებით, ასევე მთელი ფაილის მთლიანობის შემოწმება სახელად MAC. მისი გახსნა ნიშნავს ამ MAC-ის გადამოწმებას, გასაღების ტომრის გაშიფვრას და სერტიფიკატის შედარებას იმ გასაღებთან, რომელიც იქიდან გამოდის.
პაროლის პრობლემა MAC-ის ეტაპზე ჩნდება. შიფრის პრობლემა უფრო გვიან ჩნდება, როცა გასაღების ტომარა უნდა გაიხსნას და ამის შემსრულებელ კონსტრუქციას ფაილში დასახელებული ალგორითმის იმპლემენტაცია არ აქვს.
მეორე შემთხვევა თანამედროვე სისტემებზე ხშირია, რადგან OpenSSL 3-მა ძველი ალგორითმების ჯგუფი არასავალდებულო legacy მომწოდებელში გადაიტანა. OpenSSL 1.x-ის მიერ ექსპორტირებული პაკეტები ჩვეულებრივ სერტიფიკატებს 40-ბიტიანი RC2-ით ლუქავდნენ, ხოლო პირად გასაღებს სამგასაღებიანი Triple DES-ით. OpenSSL 3-ის ნაგულისხმევი კონსტრუქცია კვლავ ამოწმებს MAC-ს თქვენი სწორი პაროლით და შემდეგ ტომარაზე ფარდება, ასე რომ პაროლი არასოდეს ყოფილა არასწორი და მისი ხელახლა აკრეფა არაფერს ცვლის.
წაიკითხეთ კონტეინერი გასაღების გარეთ გატანის გარეშე
სთხოვეთ თქვენი მანქანის OpenSSL კონსტრუქციას ფაილის ანალიზი და წაიკითხეთ ის წერტილი, სადაც ის თმობს. გამომავალი ფაილის გარეშე შემოწმება გასაღებს დისკზე დაშიფრულს ტოვებს და ეს არის ერთადერთი მიზეზი, რის გამოც ეს ნაბიჯი გაზიარებულ ჰოსტზე უსაფრთხოა.
openssl pkcs12 -in vpn-identity.p12 -info -nooutსწორი პაროლის მქონე ძველ პაკეტზე ეს ბეჭდავს ტომრის ატრიბუტებს და შემდეგ ჩერდება digital envelope routines::unsupported-ით. არასწორი პაროლით თქვენ იღებთ Mac verify error: invalid password?-ს ნებისმიერი ტომრის წაკითხვამდე. ორი შეტყობინება საპირისპირო მიმართულებებზე მიუთითებს და ეს ზუსტად ის ინფორმაციაა, რომელიც კლიენტმა დამალა.
თუ ხარვეზი არამხარდაჭერილი ალგორითმის არის, გაუშვით იგივე ბრძანება ხელახლა -legacy-ის დამატებით და სხვა არაფრის შეცვლით. ეს დროშა legacy მომწოდებელს მხოლოდ იმ პროცესისთვის ტვირთავს. ის VPN კლიენტს არ აიძულებს ძველი პაკეტების ანალიზს, არ ეხება სისტემურ კრიპტო პოლიტიკას და არის გაზომვა და არა შეკეთება, რადგან ფაილი მაინც უნდა შეიცვალოს.
რომელი შეცდომა რომელ ეტაპს ნიშნავს
მოკლე ცხრილი სამ შედეგს ცალ-ცალკე ინახავს და ფორმულირება უფრო მნიშვნელოვანია, ვიდრე ის, სად გამოჩნდა დიალოგი.
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
not enough data-ის ან header too long-ის მსგავსი ტექსტი არც ერთ პირველ ორ ჯგუფს არ ეკუთვნის. ეს ფორმატის პრობლემაა: .pem-ად გადარქმეული DER ფაილი, რედაქტორის მიერ გაფუჭებული ასლი, რომელმაც ხაზების ბოლოები გადაწერა, ან არასრული ჩამოტვირთვა. შეადარეთ საკონტროლო ჯამი გამომცემლის მიერ გამოგზავნილს, სანამ შიფრებს დააკვირდებით.
Mac verify error მხოლოდ პაროლის შესახებ მტკიცებულებად მიიღეთ. ეს ნიშნავს, რომ თქვენი აკრეფილიდან გამოთვლილი MAC არ ემთხვევა შენახულ მნიშვნელობას, რაც ხდება ბეჭდვითი შეცდომის, წინა იმპორტიდან ქეშირებული პაროლის ან სხვა პაროლის ფრაზით ხელახლა ექსპორტირებული ფაილის გამო. ის არაფერს ამბობს იმაზე, ძველია თუ არა შიგნითა ალგორითმები.
ააგეთ პაკეტი, რომლის გახსნაც კლიენტს ნამდვილად შეუძლია
როცა legacy ანალიზატორი დაადასტურებს, რომ ფაილი რიგზეა, გრძელვადიანი გადაწყვეტა ჩანაცვლებაა, რომლის ალგორითმებსაც სამიზნე კლიენტი მხარს უჭერს: AES-256-CBC გასაღებისა და სერტიფიკატის ტომრებისთვის, PBKDF2 SHA-256-ით წარმოებისთვის და SHA-256 MAC-ისთვის. თქვენს PKI ადმინისტრატორს შეუძლია ამის ექსპორტი იმავე გასაღების მასალიდან, და შიგნითა სერტიფიკატი რჩება ის, რისიც თქვენი სერვერები უკვე ენდობიან.
როცა ლოკალურად გარდაქმნა გიწევთ, სთხოვეთ pkcs12 ხელსაწყოს ტომრების ხელახლა დალუქვა, ვიდრე ჯერ მათი გამოტანა. ორივე პაროლის ფრაზა shell-ის ისტორიის გარეთ შეინახეთ, ფაილიდან წაკითხვით.
openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
-keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
-passin file:old.pass -passout file:new.passწარმატებული გარდაქმნა არაფერს ამბობს ვადის გასვლაზე, გასაღების გამოყენებაზე, პირადი გასაღების დამთხვევაზე ან იმაზე, ენდობა თუ არა სერვერი გამომცემ ჯაჭვს. ხელახლა შეფუთვა ტრანსპორტის ცვლილებაა და არა განახლება, და თითოეულ მათგანს კვლავ თავისი შემოწმება სჭირდება.
გამოტოვეთ ნებისმიერი რეცეპტი, რომელიც წერს დაუცველ შუალედურ გასაღებს ან ცარიელ გამომავალ პაროლს, მხოლოდ იმიტომ, რომ კლიენტმა შემდეგ ფაილი მიიღო. დაცვის მოხსნილი წაკითხვადი პაკეტი უარესი შედეგია, ვიდრე ის იმპორტის ხარვეზი, რომლითაც დაიწყეთ.
დაადასტურეთ, რომ კლიენტმა თქვენ მიერ აგებული ფაილი იმპორტში შეიტანა
ტერმინალში სუფთა ანალიზი ამტკიცებს, რომ კონტეინერი ვალიდურია. ის არ ამტკიცებს, რომ კლიენტმა ის აირჩია, რადგან დარჩენილ პროფილს შეუძლია კვლავ ძველ ფაილზე მიუთითოს, და ზოგი კლიენტი იმპორტირებულ იდენტობას თქვენ მიერ არჩეული სახელის გარეშე ინახავს ქეშში.
დაბეჭდეთ ის იდენტობა, რომლის იმპორტსაც აპირებთ, და შეადარეთ იმას, რასაც კლიენტი თავის სერტიფიკატების ხედში აჩვენებს.
openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
| openssl x509 -noout -subject -dates -fingerprint -sha256ჯერ წაშალეთ მოძველებული პროფილის ჩანაწერი, შემდეგ იმპორტი გააკეთეთ. თუ კლიენტი ინახავს ჩატვირთული სუბიექტის ან თითის ანაბეჭდის ჟურნალს, შეადარეთ ის ზემოთ მოცემულ ხაზს; თუ მხოლოდ მეგობრულ სახელს აჩვენებს, ნაცვლად ამისა შეამოწმეთ ვადის გასვლის თარიღი, რადგან იმავე გამომცემლის სხვა სერტიფიკატთან მისი არევა უფრო რთულია.
PKCS12-ის ცნობარი ჩამოთვლის აქ გამოყენებულ მომწოდებლის, პაროლის ფრაზისა და გამომავალი პარამეტრებს. არსი იმაშია, რომ legacy მომწოდებელი კლიენტის გარემოს გარეთ დარჩეს: გაზომეთ მასთან, გაგზავნეთ მის გარეშე და პირადი გასაღები დისკზე დაცული დატოვეთ.