კომპრომეტირებული სასერტიფიკატო ცენტრი: რას ვამოწმებ ჩემი სერვერების სერტიფიკატებში

eMudhra-ს სასერტიფიკატო ცენტრის რვა შუალედური სერტიფიკატის პირადი გასაღებები გაჟონა. ამ სერტიფიკატებს ენდობოდა ბრაუზერები, ოპერაციული სისტემები და თითქმის ყველაფერი, რაც HTTPS-ით მუშაობს. ვისაც გასაღებები აქვს, მას შეუძლია ყალბი სერტიფიკატი გამოუშვას ნებისმიერ დომენზე და თავისი სერვერი სხვისად გაასაღოს: ბანკად ან თქვენი საგადახდო სერვისის API-დ. ბრაუზერებმა ეს ერთ დღეში დახურეს. სერვერები და თანამშრომლების ლეპტოპები თავისით არ დაიხურება, და ამას ის უნდა მიხედოს, ვინც მათზე პასუხისმგებელია.

ვინ რა დაწერა

Cloudflare-მა 20 ოქტომბერს ინციდენტი ბლოგში აღწერა: კომპრომეტაციის შესახებ 19 ოქტომბერს, დაახლოებით 17:00 UTC-ზე გაიგეს, დაახლოებით ერთ დღე-ღამეში განაახლეს WARP და cloudflared კლიენტები და დახურეს CDN და Zero Trust. ექსპლუატაციის კვალი თავისთან ვერ იპოვეს. იქიდან ორი რჩევა დასამახსოვრებელია. პირველი: SDK-ზე ქვემოთ ჩახედეთ. API კლიენტმა სერტიფიკატი შეიძლება შეამოწმოს HTTP ბიბლიოთეკით, ენის რანთაიმით, ოპერაციული სისტემით ან თავისი ნდობის სიით, და ერთი SDK-ს განახლება აქედან არაფერს ცვლის. მეორე: როცა განახლების შემდეგ ლოგებში სერტიფიკატის შეცდომები გამოჩნდება, შემოწმების გამორთვით არ გაასწოროთ.

Ubuntu-მ 20 ოქტომბერს გამოუშვა განახლებები ca-certificates პაკეტისა და libnss3 ბიბლიოთეკისთვის ყველა რელიზზე 14.04-დან 26.10-მდე. თავად eMudhra მათ root საცავში არ იყო, მაგრამ ის ორ სხვა root-ს ჰქონდა ხელმოწერილი, emSign Root TLS CA G3 და Comodo AAA Certificate Services, და ორივე წაშალეს. თუ ავტომატური განახლებები ჩართულია, ხოლო 16.04-დან ისინი ნაგულისხმევად ჩართულია, პატჩი ერთ დღე-ღამეში მოვა. Java ცალკე ამბავია: მისი საცავი სისტემურს სინქრონიზდება პაკეტით, რომელსაც გადაუჭრელი შეცდომა აქვს, და იქ ხელით მოქმედება სჭირდება. 21 ოქტომბერს Oracle-მა თავისი Java-სთვის CVE-2026-91403 გამოუშვა.

Simon Willison-მა 20 ოქტომბერს მოკლე შეჯამება შეკრიბა: სერტიფიკატები იმ root-ებამდე მიდის, რომლებსაც Mozilla, Microsoft, Apple და Chrome ენდობა, და ნებისმიერი პროგრამა, რომელსაც თავისი ნდობის სია აქვს, უნდა განახლდეს. Python-ისთვის უკვე გამოვიდა uv 0.13.4, pip 26.2.2 და certifi 2026.10.19.

Weaviate-მა 22 ოქტომბერს მოყვა, როგორ განახლდა თვითონ: კლიენტების მთელი პარკი და პლატფორმა Go 1.27.3-ზე 17 საათზე ნაკლებ დროში გადაიყვანეს, კორპორატიული კლიენტები ექვს საათში. ტექსტით თუ ვიმსჯელებთ, განახლება ენის ვერსია იყო: ზუსტად ის „SDK-ზე ქვემოთ“ შემთხვევა Cloudflare-ის ტექსტიდან.

რატომ ეხება ეს გაქირავებას და არა მხოლოდ Cloudflare-ს

ავიღოთ ავტომობილების გაქირავება. დაჯავშნის საიტი სერვერზე დგას, მენეჯერები ლეპტოპებიდან მუშაობენ, გადახდას საგადახდო სერვისით ადასტურებენ, ხელშეკრულებები ფოსტით მიდის. თავად საიტის სერტიფიკატს ამ ამბავთან კავშირი არ აქვს. საფრთხე იქ არის, სადაც გაქირავების სერვერი თვითონ მიმართავს საგადახდო სერვისის API-ს და CRM-ს, ხოლო მენეჯერი ლეპტოპიდან ბანკში კაფედან, სხვისი Wi-Fi-ით შედის. თუ გზაზე ის დგას, ვისაც გაჟონილი გასაღებები აქვს, ის სერვერს ან ლეპტოპს ყალბ „საგადახდო სერვისს“ აჩვენებს, და სერტიფიკატის შემოწმება ამას გაატარებს, სანამ ნდობის სია არ განახლდება.

დასკვნა: უნდა შეამოწმოთ იმათი სიები, ვისაც თქვენი მანქანები ენდობა, როცა თვითონ ვინმეს უკავშირდება. ერთ სერვერზე ასეთი სია რამდენიმეა.

რას ვამოწმებ ჩემთან

ჩემზეა რამდენიმე კომპანიის სერვერი: აშშ-ში PDR კომპანიის სერვერი Debian-ზე Google Cloud-ში, 2022 წლიდან, ჰიდროპონური ფერმის სერვერი იქვე, და სტუდიის საერთო სერვერი 2 GB მეხსიერებით, სადაც Docker-ში Nginx-ის უკან ჩემი საიტი და შიდა სერვისი „ყავა ერთად“ მუშაობს Let's Encrypt სერტიფიკატით. PDR კომპანიაში უსაფრთხოების კითხვები ჩემთან მოდის, და მსოფლიოში მსხვილი გატეხვების დროს ვამოწმებ, გვეხება თუ არა ეს ჩვენ. ეს ამბავი სწორედ ასეთია.

პირველი: სისტემური პაკეტი ca-certificates ყველა სერვერზე. Debian-ზე მას იგივე სახელი აქვს, რაც Ubuntu-ზე.

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

მესამე: რანთაიმები. Node.js-ს root სერტიფიკატების საკუთარი სია აქვს, Python-ს თავისი certifi. მათ ამ კვირის განახლებებზე ცალკე ვწერ, Node.js-ის, Python-ისა და Next.js-ის პატჩების მიმოხილვაში.

მეოთხე: ვინ სად დადის. „ყავა ერთადში“ სერვერი თვითონ მიმართავს Tasty Coffee-ს საბითუმო API-ს და Google ცხრილს შიდა პროქსიების გავლით. PDR კომპანიაში Python-ზე დაწერილი პარსერები Anthropic-ის, OpenAI-სა და Gemini-ს სერვისებთან დადის, ტელეფონია Twilio-სთან, ხოლო PDF-ს Puppeteer აწყობს თავისი Chrome-ით. თითოეულ ამ გზას სერტიფიკატის თავისი შემოწმება აქვს, და ბრაუზერში წარმატებული ტესტი მათზე არაფერს ამბობს.

მეხუთე: სტუდიის სერვერზე Let's Encrypt სერტიფიკატს არ ვეხები. ის სხვა ცენტრმა გასცა, და ჩემი გაგებით, ეს ამბავი მას არ ეხება.

რას გავაკეთებდი პატარა კომპანიაში

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

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

ხელახლა ავაწყობდი Docker იმიჯებს განახლებული საბაზო იმიჯებით და გადავტვირთავდი კონტეინერებს. მხოლოდ ჰოსტის განახლება საკმარისი არ არის.

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

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

იმაზე, რატომ სჭირდება სისტემას საკუთარი სერვერი და ვინ აგებს პასუხს წვდომაზე, არის სტატია სერვერი: მონაცემები, წვდომა და პროცესის შესრულება; როგორ ვინახოთ ინფრასტრუქტურა, რომლის გამოშვება და აღდგენა შესაძლებელია, აღწერილია გვერდზე DevOps და ინფრასტრუქტურა. ამ ტექსტის სერვერები არის ქეისებში „ყავა ერთად“ და ტექნიკური პარტნიორობა PDR კომპანიასთან. ახლო მიმოხილვებიდან: PHP2Shell და საკუთარი სერვერების შემოწმება, Node.js-ის, Python-ისა და Next.js-ის პატჩების კვირა და გასაღებები ერთი გაშვებისთვის მუდმივების ნაცვლად; ადრე ვწერდი API გასაღებებზე და იმაზე, როგორ გადავიტანოთ გაჟონვა. თუ დარწმუნებული არ ხართ, ვის ენდობა თქვენი სერვერები, აღწერეთ, რა სად გიდგათ, და გეტყვით, საიდან დავიწყოთ. ამოცანის განხილვა.