PKCS12, PEM თუ DER: რა სჭირდება VPN კლიენტს სინამდვილეში
შეფუთვა წყვეტს, კლიენტი შემოიტანს იდენტობას თუ არა, და არა იმას, სანდოა თუ არა ის. შეადარეთ PKCS12, PEM და DER, შემდეგ კი გადაამოწმეთ.
სერტიფიკატების განხილვებში ორი მტკიცება ტრიალებს. პირველი — რომ .p12 ძლიერი არჩევანია, ხოლო .pem — მშვიდი; მეორე — რომ ტექსტური ფაილი უსაფრთხოდ უნდა იგზავნებოდეს, რადგან მისი წაკითხვა შეგიძლიათ. არც ერთი არ უძლებს ერთი წუთის შემოწმებას.
PKCS12, PEM და DER აღწერენ, როგორ იფუთება და კოდირდება სერტიფიკატის ობიექტები. ისინი არ წყვეტენ, ვინ არის მეორე მხარე, სანდოა თუ არა გამომცემელი, ან სჭირდება თუ არა ფაილს პაროლი.
რასაც კლიენტი იღებს, თავსებადობის საკითხია. რასაც ფაილი შეიცავს, იდენტობის საკითხია. გაყავით ეს ორი და იმპორტის შეცდომების უმეტესობა შეწყვეტს იდუმალებას.
სამი კონტეინერი, ერთი ობიექტის მოდელი
დაიწყეთ იმით, რაც ნამდვილად გაქვთ. სერტიფიკატი ხელმოწერილი განცხადებაა საჯარო გასაღების შესახებ. პირადი გასაღები ცალკე მასალაა, რომელიც ამტკიცებს, რომ თქვენ აკონტროლებთ ამ გასაღებს. ჯაჭვი გამომცემლების ერთობლიობაა, რომლებიც თქვენს სერტიფიკატს უერთებენ იმ ფესვს, რომელსაც კლიენტი ენდობა. სამივე არსებობს შეფუთვისგან დამოუკიდებლად.
PKCS12 ფაილი, ჩვეულებრივ .p12 ან .pfx, RFC 7292-ში განსაზღვრული კონტეინერია, რომელსაც შეუძლია ატაროს პირადი გასაღები, ერთი ან რამდენიმე სერტიფიკატი და ჯაჭვი ერთ პაროლით დაცულ ბლოკში, იდენტობის სახელის მქონე ფსევდონიმით. PEM ფაილი RFC 7468-ში განსაზღვრული ტექსტური ჩარჩოა: base64 სხეული BEGIN და END ხაზებს შორის, და ერთი ფაილი შეიძლება შეიცავდეს რამდენიმე ბლოკს ზედიზედ. DER იგივე ASN.1 სტრუქტურების ორობითი კოდირებაა, ხოლო PEM სხეული სიტყვასიტყვით base64-ში გახვეული DER-ია.
ბოლო წინადადება დასამახსოვრებელია. PEM-ის DER-ად გარდაქმნა ჩარჩოს გადაწერს და არა შიგთავსს, ხოლო უკუგარდაქმნა საწყის ბაიტებს აბრუნებს.
| Container | Can hold | Does not decide |
|---|---|---|
| PKCS12 (.p12, .pfx) | Key, leaf certificate, chain, alias, password | Which root the client trusts |
| PEM (.pem, .crt, .cer) | Any number of base64 blocks | Whether the private key is present |
| DER (.der, .cer) | One binary structure | The object type, whatever the extension says |
კოდირება დაშიფვრა არ არის
base64 ტრანსპორტის ანბანია. ის არაფერს მალავს და ნებისმიერს შეუძლია PEM ბლოკის გაშიფვრა shell-ში. DER ფაილი ორობითია და თანაბრად საჯარო. არც ერთი თვისება არ არის დაცვა და არც ერთი არ მიანიშნებს პაროლის არსებობაზე.
ნამდვილი დაცვა გასაღების მასალაშია. PKCS12 პაკეტს შეუძლია დაშიფროს თავისი შიგთავსი პაროლიდან მიღებული გასაღებით. PEM პირადი გასაღები შეიძლება დაშიფრული იყოს ძველი სათაურის ბლოკით ან შენახული იყოს PKCS#8 EncryptedPrivateKeyInfo-ში. სერტიფიკატი მარტო არაფერს ინახავს საიდუმლოდ, ამიტომ მხოლოდ სერტიფიკატის გამომცემი ექსპორტი კლიენტს ავთენტიფიკაციის უნარს უკარგავს, რომელ ფორმატშიც არ უნდა გაახვიოთ ის.
გაფართოება მინიშნებაა და არა ხელშეკრულება. .cer და .crt-ით დამთავრებული ფაილები ორივე კოდირებაში გვხვდება, და მოწყობილობები საკმარისად ხშირად ახდენენ DER სერტიფიკატების ექსპორტს .pem სახელებით, რომ დაბოლოებით გამოცნობა ნახევარ დღეს ხარჯავს. ამის ნაცვლად წაიკითხეთ პირველი ბაიტები: PEM ფაილი BEGIN ხაზით იხსნება, ხოლო DER 0x30-ით იწყება, რადგან გარე სტრუქტურა SEQUENCE-ია.
რატომ ვარდება იმპორტი სინამდვილეში
კლიენტის შეცდომის შეტყობინებები რამდენიმე სხვადასხვა პრობლემას აჭერენ ერთ წინადადებაში არასწორი სერტიფიკატის შესახებ, ამიტომ გაყავით ისინი მიზეზის მიხედვით. ყველაზე ხშირია კოდირების შეუთავსებლობა: PEM-ის პარსერი კლიენტი DER ფაილზე პარსინგის შეცდომას აბრუნებს, და გამოსავალი გარდაქმნაა და არა ახალი სერტიფიკატი. მეორე დაკარგული გასაღებია, როცა სერტიფიკატი რიგზეა და იდენტობის დამტკიცება შეუძლებელია. მესამე ჯაჭვია, როცა შუალედური სერტიფიკატის გარეშე პაკეტი იმპორტის დიალოგში სწორად გამოიყურება და ხელის ჩამორთმევისას ვერდება.
დაშიფვრის პარამეტრები მეოთხეს იწვევს და ის ზუსტად არასწორ პაროლს ჰგავს. ძველი მოწყობილობები PKCS12 ფაილებს RC2-40 და 3DES-ით ახდენდნენ ექსპორტს, რომლებსაც OpenSSL 3 უარყოფს, თუ legacy პროვაიდერი არ არის ჩატვირთული. მოწყობილობიდან AES-256-CBC და PBKDF2-ით ხელახალი ექსპორტი მდგრადი გამოსავალია. ერთი ფაილისთვის კლიენტის მანქანაზე ძველი შიფრების სამუდამოდ ჩართვა ცუდი გარიგებაა.
მეხუთე გაურკვევლობაა. ორი გასაღებისა და ორი სერტიფიკატის მქონე კონტეინერი, ან სამი CERTIFICATE ბლოკის მქონე PEM ფაილი, კლიენტს არჩევანს აიძულებს, და მისი არჩევანი ხშირად უბრალოდ პირველი ელემენტია. როცა გვირაბი არასწორი იდენტობით ადის, ჩვეულებრივ ეს არის მიზეზი.
შეამოწმეთ გარდაქმნამდე
წაიკითხეთ სტრუქტურა საიდუმლოებების დაბეჭდვის გარეშე. openssl pkcs12 -in bundle.p12 -info -noout იტყობინება დაშიფვრის ალგორითმებსა და ფსევდონიმებზე და ახშობს გასაღებისა და სერტიფიკატის გამოსავალს, ხოლო openssl-pkcs12 სახელმძღვანელო აღწერს დროშებს. -noout-ის მოშორება და -nodes-ის დამატება განკუთვნილია იმ ფაილების შესაქმნელად, რომელთა შენახვასაც აპირებთ და არა სწრაფი გადახედვისთვის, რადგან ის პირად გასაღებს ღიად წერს.
სერტიფიკატისთვის openssl x509 -in cert.pem -noout -subject -issuer -dates პასუხობს იმას, რასაც იმპორტის დიალოგი არ უპასუხებს, და -ext subjectAltName-ის დამატება აჩვენებს სახელებს, რომელთათვისაც სერტიფიკატი ნამდვილად ძალაშია. თუ ფაილი DER-ია, დაამატეთ -inform DER; ეს ერთი დროშა ხსნის unable-to-load შეცდომების უმეტესობას.
გასაღების სერტიფიკატთან შეხამება მექანიკური საქმეა და ღირს ნებისმიერ იმპორტამდე:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
იდენტური დაიჯესტები ნიშნავს, რომ წყვილი ერთადაა. განსხვავებული დაიჯესტები ნიშნავს, რომ არასწორი გასაღები გაქვთ, და ფორმატის ვერც ერთი გარდაქმნა ვერ შეცვლის ამას.
რასაც ფორმატი არასდროს ცვლის
ნდობის გადაწყვეტილებები კონტეინერის ზემოთ მიიღება. კლიენტი ჯაჭვს გადის თავის საცავში არსებულ ფესვამდე, ამოწმებს ვალიდურობის ფანჯარას, ამოწმებს გაფართოებულ გასაღების გამოყენებას კლიენტის ავთენტიფიკაციისთვის, და სერვერის მხარეს ამოწმებს, რომ დარეკილი სახელი სერტიფიკატშია. ამ ნაბიჯებიდან არც ერთი არ კითხულობს ფაილის გაფართოებას.
ამიტომ ფაილის გადარქმევა შეცდომის გაქრობამდე დროის დაკარგვის ასეთი საიმედო გზაა. იმპორტი წარმატდება, იდენტობა მაინც არასწორია, და მარცხი ისევ ხელის ჩამორთმევისას ჩნდება, სადაც შეტყობინება ნაკლებად სასარგებლოა. ამიტომაც ორი წლის წინ ექსპორტირებული პაკეტი სუფთად იმპორტირდება და მაინც უარყოფილია: ვადის გასვლის თარიღი სერტიფიკატის შიგნით მოგზაურობდა და არა ფაილის სახელში.
თანმიმდევრობა, რომელიც თავიდან იცილებს გადაკეთებას
ჰკითხეთ კლიენტის დოკუმენტაციას, რომელ კოდირებებს იღებს და რა კონტეინერს ელოდება კლიენტის იდენტობისთვის, შემდეგ ნახეთ, რა მოგცეს. თუ კლიენტს ერთი იმპორტირებადი იდენტობა სურს და თქვენ გაქვთ ცალკე PEM ფაილები, ააგეთ პაკეტი ერთხელ თქვენს მიერ კონტროლირებადი პაროლით და შეინახეთ წყაროები. თუ PEM სურს, ამოიღეთ გასაღები და ჯაჭვი, შემდეგ წაშალეთ შუალედური ფაილები იმ სერტიფიკატების დამუშავების პროცესით, რომელსაც თქვენი გუნდი უკვე იყენებს.
იმპორტის შემდეგ შეამოწმეთ იდენტობა და არა დიალოგი: სუბიექტი, გამომცემელი, ვადა და სახელი, რომელსაც კლიენტი წარმოადგენს. სიაში მეგობრული სახელი იარლიყია და არა დადასტურებული იდენტობა. თუ შემდეგ გვირაბი ვარდება, თქვენ ავთენტიფიკაციას ან მარშრუტიზაციას ამუშავებთ და არა შეფუთვას, რაც გაცილებით მოკლე საუბარია.