სერტიფიკატების ექსპორტი P12-იდან პირადი გასაღების გარეშე

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

დაიწყეთ კონტეინერის წაკითხვით და არა მისი დაცარიელებით.

რას შეიცავს სინამდვილეში PKCS12 ფაილი

PKCS12 კონტეინერი შეიცავს ერთ ან მეტ სერტიფიკატს, შესაძლოა პირად გასაღებს და message authentication code-ს შიგთავსზე. სერტიფიკატებში შეიძლება იყოს თქვენი კლიენტური იდენტობის ფოთლის სერტიფიკატი და შუამავალი სერტიფიკატები, რომლებიც მას CA-სთან აკავშირებენ. გასაღები, როცა არსებობს, არის ის, რაც ფაილს საიდუმლოდ აქცევს და არა დოკუმენტად.

ეს განსხვავებაა მიზეზი, რატომ არსებობს -nokeys და რატომ არის ეს ის დროშა, რომელიც ამ ამოცანას სჭირდება.

წაიკითხეთ პაკეტი გასაღების გამოწერის გარეშე

შემოწმების ფორმა ბეჭდავს სტრუქტურასა და ალგორითმების დეტალებს და არაფერს წერს: openssl pkcs12 -in client.p12 -info -noout. ის ითხოვს იმპორტის პაროლს, რაც ამ მნიშვნელობისთვის სწორი ადგილია, და გეუბნებათ, შეიცავს თუ არა ფაილი საერთოდ გასაღებს. გამოიყენეთ -passin env:PKCS12_PASS, როცა პაროლის აკრეფა შეუძლებელია, რადგან shell ბრძანებაში მყოფი პაროლი პაროლია პროცესების სიაში. ეს ნაბიჯი არაფერს ექსპორტავს და ეს არის მთელი აზრი.

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

გამოიყენეთ -nokeys და არ აურიოთ ის -nocerts-ში

-nokeys გამორიცხავს პირად გასაღებებს და ტოვებს სერტიფიკატებს. -clcerts ამას კლიენტურ სერტიფიკატებამდე ავიწროებს, -cacerts CA სერტიფიკატებამდე ავიწროებს, და ეს ორი ფილტრია და არა ალტერნატივა. -nocerts იკითხება როგორც იმავე იდეის უსაფრთხო ჩანაწერი და ნიშნავს საპირისპიროს: სერტიფიკატები არ არის, რაც მხოლოდ გასაღებებს ტოვებს. მისი სერტიფიკატების ექსპორტში შერევა ის გზაა, რომლითაც პირადი გასაღები დისკზე ხვდება.

ორხაზიანი ფორმა, რომელიც ქმნის სერტიფიკატების ფაილსა და CA ფაილს და მეტ არაფერს, არის:

openssl pkcs12 -in client.p12 -nokeys -clcerts -out client-certificates.pem
openssl pkcs12 -in client.p12 -nokeys -cacerts -out ca-certificates.pem

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

შეამოწმეთ გამოსავალი და არა გასვლის კოდი

ნულოვანი გასვლის სტატუსი ამბობს, რომ ბრძანება შესრულდა და არა რომ ფაილი შეიცავს იმას, რასაც ელოდებით. დათვალეთ სერტიფიკატები გამოსავალში და წაიკითხეთ subject და თარიღები: openssl x509 -in client-certificates.pem -noout -subject -dates -fingerprint. შეადარეთ ანაბეჭდი იმას, რასაც მხარდაჭერის გუნდი ელოდება, რადგან ორი კლიენტური სერტიფიკატის მქონე პაკეტი ქმნის ორბლოკიან ფაილს და ხელსაწყოების უმეტესობა მხოლოდ პირველს კითხულობს. დანიშნულება, ნდობა და გასაღების შესაბამისობა კვლავ ცალკე ტესტებია.

სერტიფიკატი, რომელიც პარსდება, არის სერტიფიკატი, რომელიც პარსდება. ეს არ არის სერტიფიკატი, რომელსაც VPN მიიღებს.

გადაწყვიტეთ, საერთოდ გჭირდებათ თუ არა ფაილები

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

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