Barg sertifikati amal qiladi, zanjir muddati tugagan: chuqurlikni o‘qing

Server sertifikatini tekshirasiz, soatda hali oylar qolganini ko‘rasiz, ammo mijoz baribir muddat tugagan xabari bilan ulanishni rad etadi. Siz o‘qigan sana bargga tegishli, shikoyat esa yo‘lning chuqurroq qismidagi narsa haqida bo‘lishi mumkin. Tekshiruv zanjir bo‘ylab boradi va bu yurish tanlagan har qanday sertifikat o‘zining amallik oynasida muvaffaqiyatsiz bo‘lishi mumkin. Biror narsani yangilashdan oldin qaysi biri muvaffaqiyatsiz bo‘lganini o‘qing.

Chuqurlik muvaffaqiyatsiz bo‘lgan sertifikatni nomlaydi

OpenSSL diagnostikasida chuqurlik 0 maqsadli sertifikat, chuqurlik 1 esa uni imzolagan chiqaruvchi bo‘lib, katta raqamlar ishonch langariga qarab davom etadi. 1-chuqurlikda xabar qilingan muddat tugashi bargdagi joriy notAfter bilan ziddiyatga tushmaydi, shuning uchun ko‘rinadigan sertifikatni qayta tekshirish xatoni hech qachon tushuntirmaydi.

Muvaffaqiyatsiz sertifikatning barmoq izini uning subject bilan birga yozib qo‘ying, chunki turli sertifikatlar bir xil CA nomini olib yurishi mumkin. Kross-imzolash aynan shu holatni yaratadi: o‘sha organ bir necha marta, turli amallik sanalari bilan ko‘rinadi va tekshiruvchi siz kutmagan variantni tanladi. Tanish yorliq identifikator emas, barmoq izi esa bir xil nomni bo‘lishadigan ikki obyektni ajratadigan narsadir.

Bir nechta sertifikat rolidagi mahsulotlarga ham e’tibor bering. OpenVPN Access Server’da veb-interfeyslarni himoya qiluvchi sertifikatlar VPN ulanishlarida ishlatiladiganlardan ajratilgan, shuning uchun admin sahifasini ochuvchi brauzer tunnel yo‘li haqida hech narsani isbotlamaydi.

Ishonch kiritmalari zanjir nomzodlari bilan bir xil emas

Tekshiruvchiga ikki kiritmani alohida va aniq bering. Ishonch fayli siz qabul qiladigan langarlarni saqlaydi; ishonchsiz paket yo‘lni qurish uchun taklif etilgan oraliq sertifikatlarni saqlaydi. Ularni aralashtirish odamlarning tasodifan oraliq sertifikatni ildizga ko‘tarib, keyin nega o‘sha xato mashinalar orasida ularni ta’qib qilishiga hayron bo‘lish usulidir.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Standart yo‘l va omborni -no-CApath -no-CAstore bilan o‘chirish testni halol saqlaydi: natija siz nomlagan fayllarga bog‘liq, ish stansiyasi tasodifan ishonadigan narsaga emas. OpenSSL tekshiruv ma’lumotnomasi bu variantlar va ular ishlab chiqaradigan diagnostikani hujjatlashtiradi.

-show_chain tekshiruv muvaffaqiyatli bo‘lganda qurilgan zanjirni chop etadi, bu yo‘l siz mo‘ljallagan yo‘l ekanini tasdiqlash uchun foydali. U muvaffaqiyatsiz bo‘lsa, xabar qilingan chuqurlik va subjectni saqlang; o‘sha ikki maydon keyingi o‘quvchiga qaysi sertifikatni tekshirishni aytadi.

Bu qilmaydigan narsa har bir mijoz siyosatini qayta ishlab chiqarishdir. Pin, maqsad cheklovi yoki mijozga xos identifikatsiya tekshiruvi mijozda yashaydi, bu buyruqda emas. Serverda tekshiruv o‘tib, ulanish baribir muvaffaqiyatsiz bo‘lganda tekshiriladigan sozlamalar — o‘shalar. Ikki diagnostikani alohida saqlang, aks holda pinning xatosini quvib, sog‘lom sertifikatni yangilaysiz.

Tekshiruv nimani isbotlaydi va nimani chetda qoldiradi

Bu siz taqdim etgan ishonch fayliga qarshi yo‘l va maqsad tekshiruvi. HTTPS nomini tekshirish uchun tegishli variant orqali kutilgan xost nomini qo‘shing; VPN ulanishi uchun mijozning sozlangan identifikatsiya tekshiruvlarini saqlang va o‘sha mijoz haqiqatan o‘qiydigan ishonch materialidan foydalaning.

Server yuboradigan narsa nomzodlar to‘plami, mijozingiz oxir-oqibat quradigan yo‘l emas. Mahalliy ishonch va kutubxonaning qurish qoidalari ikkalasi ham natijani shakllantiradi, shuning uchun bir xil javob bir mashinada tekshirilib, boshqasida muvaffaqiyatsiz bo‘lishi mumkin. Bir xil baholashni taxmin qilishdan oldin muvaffaqiyatsiz mijozning boshqariladigan ishonch ombori va TLS amalga oshirilishini ishlaydigan mijoz bilan solishtiring. U yerdagi farq „faqat shu noutbukda muvaffaqiyatsiz bo‘ladi“ kabi ko‘plab hisobotlarni tushuntiradi.

Har bir sertifikatning oynasini birma-bir emas, to‘plam sifatida ko‘rish uchun ularni shunday chop eting:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

O‘sha ikkinchi buyruq har bir faylni qo‘lda dekodlamasdan subject va chiqaruvchilarni sanaydi, shu bilan barg hali yaxshi ko‘rinayotganda sanasi o‘tgan oraliq sertifikatni sezasiz.

Tekshiruvni zaiflashtirmasdan yo‘lni tuzating

Muddati o‘tgan oraliq yoki eskirgan kross-imzolangan sertifikat taqdim etilganda, chiqaruvchining hozirda qo‘llab-quvvatlanadigan zanjirini oling va xizmatning hujjatlashtirilgan sertifikat ish oqimi orqali joylashtiring. Mijozda mo‘ljallangan boshqariladigan langar bo‘lmasa, uning boshqariladigan ishonch konfiguratsiyasini yoki mijoz dasturini yangilang. Xabarni jim qilish uchun paketdagi har bir sertifikatni ildiz deb belgilashning qisqa yo‘liga qarshi turing.

Ildiz bilan ishlash izohga loyiq, chunki xulosalar uni ko‘pincha bo‘rttiradi. RFC 5280 langarni kutilayotgan yo‘ldan tashqarida turgan kiritma deb qaraydi, OpenSSL esa o‘zining ildiz CA sertifikatini o‘z ichiga olgan amallik tekshiruvlarini hujjatlashtiradi. Ikkala bayonot ham o‘z tizimlari uchun to‘g‘ri; bir kutubxonaning ildiz muddati tugashi xulqini har bir mijozga umumlashtirish ishonchli noto‘g‘ri javoblar beradi.

O‘zgarishdan keyin zararlangan mijozda yangi autentifikatsiyani majburan ishga tushiring va aniq muddat tugashi xabari yo‘qolganini tasdiqlang. Bargni faqat bargning o‘zi yaroqsiz bo‘lsa yangilang. Vaqt tekshiruvlarini o‘chirish yoki tarixiy kross-sertifikatni tiklash amaldagi joriy yo‘lni yaratmaydi; u faqat keyingi muvaffaqiyatsizlikni kechiktiradi.