TLS შეცდომები მხოლოდ კორპორატიულ VPN-ში: გაასწორეთ სწორი ნდობის საცავი

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

სამი შეტყობინება, სამი მექანიზმი

შეცდომა x509 certificate signed by unknown authority ნიშნავს, რომ ჯაჭვი აშენდა და მისი ფესვი აკლია იმ ნდობის საცავს, რომელსაც ეს პროცესი იყენებს. შეცდომა self-signed certificate in certificate chain ჩვეულებრივ ნიშნავს, რომ შემოწმების პროქსიმ უპასუხა საკუთარი სერტიფიკატით, რაც არის ჯაჭვი, რომელსაც თქვენი გაშვების გარემო არ ცნობს. SSL EOF ხელის ჩამორთმევის დროს ნიშნავს, რომ კავშირი დაიხურა სანამ რაიმე გამოსადეგი სერტიფიკატი გაიგზავნებოდა, და ეს შუამავალი მოწყობილობაა, რომელიც უარყოფს ClientHello-ს, და საერთოდ არ არის ნდობის პრობლემა.

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

იპოვეთ პაკეტი, რომელსაც პროცესი რეალურად კითხულობს

Windows-ის საცავში დაყენებული კორპორატიული ფესვი ასწორებს ბრაუზერებს და .NET აპლიკაციებს, რომლებიც სისტემურ საცავს მიმართავს. ის არაფერს აკეთებს კონტეინერში მომუშავე აწყობისთვის, რომელსაც საკუთარი CA პაკეტი მოაქვს, და არაფერს certifi-ს იყენებელი Python პროცესისთვის ან საკუთარ ჩაშენებულ სიას იყენებელი Node პროცესისთვის. Go კითხულობს იმ გარემოს სისტემურ აუზს, რომელშიც ბინარი მუშაობს, ანუ კონტეინერს და არა ლეპტოპს. ამიტომ ერთი მანქანა ერთდროულად იძლევა მომუშავე ბრაუზერს და ჩავარდნილ აწყობის ხელსაწყოს.

იკითხეთ ხელსაწყოსგან და ნუ ივარაუდებთ. python3 -c "import ssl; print(ssl.get_default_verify_paths())" ბეჭდავს იმ ფაილებს, რომლებსაც Python მიმართავს, და node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" აჩვენებს, დაყენებულია თუ არა უკვე გადაფარვა. კონტეინერისთვის იგივე შემოწმება გაუშვით გამოსახულების შიგნით, რადგან სწორედ ის გარემო გამოიყენება აწყობის დროს.

დააყენეთ ერთი ფესვი იქ, სადაც აწყობა მუშაობს

მიიღეთ შემოწმების ფესვი IT-დან PEM ფაილის სახით და სანამ ენდობით, გადაამოწმეთ მისი თითის ანაბეჭდი ცალკე არხით. Debian-ზე დაფუძნებულ გამოსახულებებზე დააკოპირეთ ის /usr/local/share/ca-certificates/ საქაღალდეში და გაუშვით update-ca-certificates; RHEL ოჯახის გამოსახულებები ფაილის /etc/pki/ca-trust/source/anchors/ საქაღალდეში მოთავსების შემდეგ იყენებენ update-ca-trust-ს. კონტეინერის აწყობაში დაამატეთ ეს ნაბიჯები ჩავარდნილ ბრძანებამდე, რომ შრე ქეშირდეს დამოკიდებულებების ინსტალაციის ზემოთ.

ლოკალური devcontainer-ისთვის ჩამოკიდეთ PEM და გაშვებისას შეასრულეთ იგივე განახლების ბრძანება, ნაცვლად იმისა რომ გამოაცხოთ ის პირად გამოსახულებაში, რომლის რეპროდუცირებასაც ვერავინ შეძლებს. ხელსაწყოებს, რომლებსაც საკუთარი პაკეტი მოაქვთ, სჭირდებათ საკუთარი დოკუმენტირებული გადაფარვა: pip-ს აქვს სერტიფიკატის პარამეტრი, npm-ს აქვს cafile პარამეტრი, და დანარჩენების უმეტესობა იღებს სტანდარტულ გარემოს ცვლადებს.

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

როცა ხელის ჩამორთმევა კვდება სერტიფიკატამდე

თუ არაფერი არ არის წარდგენილი, ნდობის საცავის ვერც ერთი ცვლილება ვერ დაეხმარება. შეადარეთ იგივე მოთხოვნა გვირაბის ჩართული და გამორთული მდგომარეობით, შემდეგ შეამოწმეთ ჯაჭვი პირდაპირ openssl s_client -connect host:443 -servername host -showcerts-ით. კავშირი, რომელიც VPN-ის გარეთ სრულდება და შიგნით გადააყენება, შუამავალი მოწყობილობის პოლიტიკის გადაწყვეტილებაა, და წამალი ამ ჰოსტისთვის გამონაკლისია და არა კიდევ ერთი სერტიფიკატი. მოითხოვეთ, რომ პაკეტების რეესტრმა ან API-ის ბოლო წერტილმა უცვლელად გაიაროს.

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

ჩაწერეთ შედეგი თითოეული ხელსაწყოსთვის

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

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