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

განახლებული ფაილი არ ცვლის სერვერის იდენტობას

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

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

აირჩიეთ მსმენელზე მორგებული გამოწვევა

სერტიფიკატმა უნდა დაასახელოს ის ჰოსტი, რომელსაც კლიენტები ამოწმებენ, ამიტომ გამოიყენეთ საჯარო DNS სახელი და არა შიდა იარლიყი ან მისამართი. HTTP-01 მოითხოვს, რომ გამოწვევას წამით უპასუხონ 80 პორტზე, რაც დროებითი მსმენელია და არასოდეს არის SoftEther-ის საკუთარი პორტის გადატანის მიზეზი. DNS-01 ამტკიცებს კონტროლს ჩანაწერის საშუალებით და საერთოდ არ სჭირდება შემომავალი HTTP.

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

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

შემოიტანეთ ჯაჭვი სერვერის დონეზე

გააკეთეთ სერვერის კონფიგურაციის სარეზერვო ასლი და დაადასტურეთ, რომ კვლავ აღწევთ მართვის ინტერფეისს, სანამ სერტიფიკატს შეეხებით. დაუკავშირდით როგორც სერვერის ადმინისტრატორი და არა Virtual Hub-ის ადმინისტრატორი, რადგან სერტიფიკატი სერვერის ობიექტს ეკუთვნის. შემდეგ ჩატვირთეთ ჯაჭვი და გასაღები აბსოლუტური ბილიკით, ფაილებიდან, რომლებსაც ბრძანების გამშვები ანგარიში შეიძლება კითხულობდეს. გაითვალისწინეთ, რომ ბილიკები აბსოლუტურია, რადგან ბრძანება მათ vpncmd-ის გამშვები პროცესის სამუშაო დირექტორიიდან წყვეტს:

ServerCertSet /LOADCERT:/etc/letsencrypt/live/vpn.example.com/fullchain.pem /LOADKEY:/etc/letsencrypt/live/vpn.example.com/privkey.pem

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

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

ჩამოკიდეთ განთავსება და არა განახლება

როცა ხელით იმპორტი იმუშავებს, ზუსტად ეს ნაბიჯები მოათავსეთ პატარა შემკვრელში და წარმატებული განახლების შემდეგ გამოიძახეთ ის ACME კლიენტიდან. Certbot კაუჭისთვის აყენებს RENEWED_LINEAGE და RENEWED_DOMAINS ცვლადებს, ამიტომ შემკვრელს შეუძლია ერთ სერტიფიკატზე იმოქმედოს მანქანაზე, რომელიც რამდენიმეს მართავს. გაფილტრეთ ხაზის მიხედვით და არა ჰოსტზე ყოველ განახლებაზე რეაგირებით. შემკვრელი განთავსების კოდია, რომელიც სერვერის უფლებებით მუშაობს, ამიტომ გადახედეთ მას ისე, როგორც ამ პოზიციაზე მდგარ ნებისმიერ სხვა სკრიპტს.

certbot renew --deploy-hook /usr/local/sbin/softether-deploy.sh

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

შეადარეთ წარმოდგენილი ჯაჭვი ფაილს

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

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -fingerprint -sha256

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

დაკავშირებული სტატიები