ვებ სერტიფიკატის შეცდომა Access Server-ში: ცარიელი CA პაკეტი

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

რაზე მიუთითებს სამი გასაღები

მორგებული ვებ სერტიფიკატების ნაკრები აღწერილია cs.cert, cs.priv_key და cs.ca_bundle-ით. თითოეული ინახავს ფაილის გზას და ვებ სერვისი სამივეს ერთად იყენებს. არასწორი გასაღების სერტიფიკატი ან ჯაჭვის ფაილი, რომელიც სინამდვილეში ფოთლის სერტიფიკატია, ისე ვარდება, როგორც ცარიელი მნიშვნელობა.

ეს გასაღებები Admin და Client ვებ ინტერფეისს ეკუთვნის. ისინი განცალკევებულია PKI-სგან, რომელიც VPN კლიენტებს სერტიფიკატებს გასცემს, ამიტომ ჩანაცვლება პროფილების ან სერვერის გასაღების შეხებას არ მოითხოვს. მთელი PKI-ს ხელახლა აშენება აქ ყველაზე ძვირი შეცდომაა.

ერთი განსხვავება დროს ზოგავს: ცხადად ცარიელი მორგებული მნიშვნელობა არ არის იგივე მდგომარეობა, რაც გადაფარვის არარსებობა. პირველი ანალიზატორს ცარიელ გზას აძლევს, ამას ამბობს ჟურნალის ხაზი. მეორე Access Server-ს საკუთარ მასალაზე ტოვებს.

რატომ არ ირღვევა არსებული ფაილი

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

შეამოწმეთ ობიექტები და არა გაფართოებები. Linux-ზე openssl x509 -noout -subject -issuer -in server.pem და openssl pkey -noout -check -in key.pem ორ მნიშვნელოვან კითხვას პასუხობს, ხოლო მოდულუსის ან საჯარო გასაღების შედარება ადასტურებს, რომ ისინი ერთად არიან. კერძო გასაღების გამონატანი ბილეთებსა და ჩატის ჟურნალებს მოარიდეთ.

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

შეგნებულად დაბრუნდით სარეზერვოზე

Access Server-ის CLI-ს აქვს შემოწმება, რომელიც სამ გზას არგუმენტად იღებს და აცნობს, გამოსადეგია თუ არა ნაკრები. ქვემოთ მოცემული გზები მაგალითია; შეცვალეთ ისინი ჰოსტის დაცული ადგილებით.

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

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

შეამოწმეთ სახელი, რომელსაც მომხმარებლები წერენ

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

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

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

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

აღდგენა მთავრდება მხოლოდ წარმატებული შესვლით

აღდგენა არ მთავრდება TCP მსმენელის გამოჩენით. შეამოწმეთ DNS სახელი, სერტიფიკატის იდენტობა და ჯაჭვი, შემდეგ ჩატვირთეთ Admin და Client ინტერფეისები და დაასრულეთ შესვლა. პორტის შემოწმება ამას არ ამტკიცებს.

Access Server 3.1 და უფრო ახლები შესაძლოა სხვადასხვა ვებ სერტიფიკატს ემსახურებოდეს თითოეული SNI სახელისთვის. თუ ეს კონფიგურირებულია, ნაგულისხმევი გასაღებები და სახელის ჩანაწერები ცალკე ნაკრებია და IP-ით შემოწმება სხვა სერტიფიკატს აჩვენებს. გაასწორეთ და შეამოწმეთ ჩავარდნილი სახელის ნაკრები და გაიმეორეთ შესვლის ტესტი.