Sertifikatlash organini qanday yaratish kerak. PKI ierarxiyasini joylashtirishning odatiy sxemalari

Ildiz SSL sertifikati – ildiz sertifikatlash organini identifikatsiya qiluvchi PKI (ochiq kalitlar infratuzilmasi) sxemasining qismlaridan biri. SSL sertifikatining ahamiyati va uning afzalliklari ko'plab foydalanuvchilar tomonidan yuqori baholangan. SSL kafolatlaridan foydalanish:

• server va mijoz o'rtasida shifrlangan ma'lumotlarni uzatish;
• ma'lumot almashiladigan saytning haqiqiyligi (fishingdan himoya).

Ammo savol tug'iladi: raqamli xavfsizlik sertifikatlari qaerdan keladi va ularning ishonchliligi uchun kim javobgar?

SSL va kodni imzolash sertifikatlarini chiqaradigan bir nechta yirik ishonchli sertifikat idoralari mavjud. Ular SSL-ni so'ragan mijoz haqiqatda domenga kirish huquqiga egami yoki so'ragan tashkilot vakilimi yoki yo'qligini tekshiradi. Bundan tashqari, uzatilgan ma'lumotlarning maxfiyligi uchun javobgarlik sertifikatlashtirish organlaridir. SSL sertifikatlarining keng qo'llanilishi ko'plab sertifikatlash organlariga olib keldi, ularning har biri o'z nomi bilan taqdim etilgan echimlarga imzo chekadi. Foydalanuvchi brauzeriga SSL provayderlarini bir-biridan ajratish va ularning ishonchliligini aniqlash imkonini berish uchun u ishonchli sertifikat organlari ro'yxatidan foydalanadi.

SSL sertifikatlarining tuzilishi

Sertifikat organlari daraxt tuzilmasi bilan bog'langan bir nechta SSL sertifikatlarini berishi mumkin. Shunday qilib, ildiz sertifikati daraxtning ildizi bo'lib, uning maxfiy kaliti boshqa sertifikatlarni imzolash uchun ishlatiladi. Ildiz sertifikatining darhol ostida joylashgan barcha oraliq sertifikatlar unga ishonch darajasini oladi, chunki ildiz sertifikatining imzosi shunga o'xshash narsadir. notarial tasdiqlash shaxsiyat. Strukturadan pastroqda joylashgan SSL sertifikatlari xuddi shunday oraliq sertifikatlarga bo'lgan ishonch darajasiga bog'liq.

Misoldan foydalanish sertifikatlashtirish markazi Comodo, SSL sertifikatlarining tuzilishini quyidagicha tasvirlash mumkin:

• Comodo CA ildiz sertifikati:AddTrustExternalCARoot
• O'rta darajadagi sertifikatlar: PositiveSSL CA 2, ComodoUTNSGCCA, UTNAddTrustSGCCA, EssentialSSLCA, Comodo yuqori kafolatli xavfsiz server CA
• Eng pastki qismida ko'rsatilgan Shaxsiy domenlar uchun SSL sertifikatlari.

Ildiz SSL sertifikati nima uchun?

Ildiz SSL sertifikati mijozning brauzeriga asosiy SSL sertifikatining egasi va emitenti haqidagi ma'lumotlarni uzatadi. Agar tashrifchi saytga kirsa, https ulanish ishonchsiz provayder tomonidan taqdim etilgan va uning ildiz sertifikati yo'q yoki foydalanuvchi brauzeri tomonidan tan olinmagan bo'lsa, natijada shunga o'xshash ogohlantirish beriladi:

Comodo, Symantec, Thawte, GeoTrust va GlobalSign kabi ishonchli sertifikat organlariga kelsak, ularning ildiz sertifikatlari haqidagi ma'lumotlar barcha zamonaviy brauzerlarga qo'shilishi kerak. Brauzer sozlamalarida ularning ro'yxati quyidagicha:

Ammo shaxsiy domen nomingiz uchun to'g'ri SSL tan olinishi uchun siz domen, oraliq va ildiz SSL sertifikatlarining ishonchli zanjirini yaratishingiz kerak. Buning uchun serveringizda ildiz va oraliq sertifikatlarni o'rnatishingiz kerak. O'rnatish jarayoni dasturiy ta'minotingizga qarab farq qiladi. Eng mashhur dasturiy ta'minotni bizning veb-saytimizda topishingiz mumkin

• Oʻquv qoʻllanma

Salom, Xabr! Biz boshlaymiz yangi seriya maqolalar. U asosida korxonada sertifikat xizmatini joylashtirishga e'tibor qaratiladi Windows Server 2016 yildan beri amaliy misollar. Bugun biz kirish nuqtalarini bayon qilamiz va PKI ierarxiyasi uchun odatiy joylashtirish sxemalari haqida gaplashamiz: ikki darajali va ko'p darajali. Bularning barchasi haqida kesma ostida o'qing.

Kirish

Maqsadli auditoriya

Raqamli sertifikatlar haqida asosiy tushunchaga ega AT ma'murlari, IT muhandislari va xavfsizlik bo'yicha mutaxassislar.

Atamalar lug'ati

Seriyaning ushbu qismida quyidagi qisqartmalar va qisqartmalar qo'llaniladi:

• PKI (Ochiq kalitlar infratuzilmasi) - ochiq kalitlar infratuzilmasi (PKI), shaxsiy va ochiq kalitlarga asoslangan kriptografik vazifalarni qo'llab-quvvatlash uchun birgalikda foydalaniladigan vositalar to'plami (texnik, moddiy, insoniy va boshqalar), taqsimlangan xizmatlar va komponentlar. IOK qisqartmasi keng tarqalgan emasligi sababli, bundan keyin ko'proq tanish bo'lgan PKI qisqartmasi qo'llaniladi.
• X.509- Ochiq kalitlar infratuzilmasi va imtiyozlarni boshqarish infratuzilmasi uchun ITU-T standarti.
• CA (Sertifikatlash markazi) raqamli sertifikatlarni chiqaradigan xizmatdir. Sertifikat ochiq kalit egasiga tegishli ekanligini tasdiqlovchi elektron hujjatdir.
• CRL (Sertifikatni bekor qilish ro'yxati) - sertifikatni bekor qilish ro'yxati. Tashqi sabablarga ko'ra tugatilgan bekor qilingan sertifikatlar ro'yxatini o'z ichiga olgan CA tomonidan nashr etilgan imzolangan elektron hujjat. Har bir bekor qilingan sertifikat uchun seriya raqami, bekor qilingan sana va vaqt, bekor qilish sababi (ixtiyoriy) ko'rsatiladi. Ilovalar taqdim etilgan sertifikat haqiqiyligini va emitent tomonidan bekor qilinmaganligini tekshirish uchun CRL dan foydalanishi mumkin.
• SSL (Xavfsiz rozetkalar qatlami) yoki TLS (Transport qatlami xavfsizligi) - mijoz va server o'rtasida ochiq tarmoqlar orqali ma'lumotlarni uzatish xavfsizligini ta'minlaydigan texnologiya.
• HTTPS (HTTP/Xavfsiz) - xavfsiz HTTP, bu SSL-dan foydalanishning alohida holati.
• Internet PKI- ochiq ma'lumotlarni uzatish kanallari orqali X.509 standarti asosida ma'lumotlarni uzatishni himoya qilishning yagona (yagona) mexanizmini ta'minlovchi standartlar, kelishuvlar, protseduralar va amaliyotlar to'plami.

Nima uchun sizga shaxsiy PKI kerak?

Shifrlash, raqamli imzo va sertifikatlar bizning kundalik Internet hayotimizning bir qismiga aylanib bormoqda. Agar bu atamalar haqida 10 yil oldin aytilgan bo'lsa va barcha IT mutaxassislari bu so'zlarning ma'nosini bilmagan bo'lsa, hozir ularni ko'pchilik biladi. Va bu jarayon bir yoki ikki yil emas, balki yaxshi o'n yil davom etadi. Hozir biz mijoz-server veb-xizmatlarini rivojlantirishning faol bosqichidamiz (salom meynfreymlar!) va odamlar va qurilmalar o'rtasidagi aloqaning katta qismi boshqa tarmoqlarga o'tkazilmoqda. kompyuter tarmoqlari va Internet. Natijada, yangi shartlar ma'lumotlarni himoya qilish uchun yangi talablarni talab qiladi. Yirik dasturiy ta'minot ishlab chiqaruvchilari maxfiy ma'lumotlarga ega serverlar, bulutli xizmatlar, oshxona choynak yoki kir yuvish dazmoli (IoT)gacha bo'lgan raqamli sertifikatlarni qo'llab-quvvatlashni talab qiluvchi "xavfsiz Internet" mafkurasini faol ravishda targ'ib qilmoqda.

Ba'zi kompaniyalar buni juda agressiv qilishadi. Shunday qilib, 2017 yildan boshlab, Google HTTPS qo'llab-quvvatlamaydigan barcha saytlarni xavfli deb hisoblaydi: xavfsizroq vebga o'tish. Va bu Internet sanoatiga juda katta ta'sir ko'rsatadi. Birinchidan, brauzerdagi ogohlantirish (Google Chrome) sizning potentsial mijozlaringiz va tashrif buyuruvchilarni yoqtirmasligi aniq. Ikkinchidan, HTTPS-ni qo'llab-quvvatlamaydigan saytlar toifaga kiradi qidiruv natijalari. Mozilla va boshqa yirik sotuvchilar ham Google bilan hamqadam: Non-Secure HTTP-ni bekor qilish. Bir tomondan, kompaniyalar Internet sanoatiga bosim o'tkazmoqda, tashkilotlarni undamoqda qo'shimcha xarajatlar raqamli sertifikatlar bilan bog'liq. Boshqa tomondan, bu majburiy qadam bo'lib, har kim zamon bilan hamnafas bo'lishi kerak.

Biroq, Internet PKI ning hozirgi holati ushbu muammolarni etarli darajada moslashuvchanlik va qulaylik bilan hal qilishga imkon bermaydi, bu katta xarajatlarni talab qiladi. Masalan, umumiy veb-server uchun bitta SSL sertifikati sizga taxminan 100 dollar turadi va agar siz sertifikatga ega bo'lishni istasangiz yashil chiziq, bu sizga yanada qimmatga tushadi. Va bu faqat bitta sertifikat uchun! Shu bilan birga, jarayonni avtomatlashtirish juda yangi bosqichda.

Ushbu muammolarni hal qilish uchun eng yirik dasturiy ta'minot sotuvchilari birlashdilar va birgalikdagi sa'y-harakatlar Internet PKI-da raqamli sertifikatlar bilan narsalarni tartibga soling. Birinchidan, yagona standartlar organi yaratildi - CAB Forum (CA/Browser Forum), u tijorat CAlar, veb-dastur ishlab chiqaruvchilari va sertifikat iste'molchilari uchun standart amaliyotlarni belgilaydi. Ikkinchidan, notijorat CA (lekin global miqyosda ishonchli) faol ravishda targ'ib qilish, ta'minlash uchun Let's Encrypt bepul sertifikatlar avtomatik yangilash imkoniyati bilan.

Bu xavfsiz aloqaning barcha muammolarini hal qilganga o'xshaydi va xususiy PKI (tashkilot ichida joylashtirilgan) darhol keraksiz bo'lib qoldi. Ba'zi hollarda, ha, agar xususiy PKI tashqi serverlarga (veb, VPN va boshqalar) xizmat ko'rsatgan bo'lsa. Ammo Let's Encrypt kabi xizmatlar hozirda faqat tor doiradagi korporativ sertifikat ehtiyojlarini qamrab oladi. Masalan, hujjatlar, pochta va raqamli imzolarni shifrlash uchun sertifikatlar qamrab olinmaydi. Mijoz autentifikatsiyasi kabi ba'zi vazifalar umuman qamrab olinmaydi. Yana bir cheklov shundan iboratki, tijorat CAlar tomonidan chiqarilgan umumiy sertifikatlardan foydalanish uchun sizda umumiy foydalanish huquqi bo'lishi kerak. Let’s Encrypt’dan domain.local nomli veb-server uchun sertifikat olish texnik jihatdan imkonsiz. Shuning uchun xususiy PKI ning dolzarbligi saqlanib qolmoqda yuqori daraja. Shaxsiy PKI dan foydalanishga misol korporativ muhit quyidagi rasmda ko'rsatilgan:

Agar kompaniya tashkilot ichida xususiy PKIdan foydalanishga qaror qilsa, yana bir dolzarb savol tug'iladi: uni hech bo'lmaganda tashkilot ichida zamonaviy amaliyot va standartlarga javob beradigan tarzda qanday qilib to'g'ri tashkil qilish kerak. Siz Active Directory sertifikat xizmatlariga (ADCS) asoslangan kompaniyada PKI-ni qanday joylashtirish haqida Internetda ko'plab maqolalarni topishingiz mumkin. Ammo ko'pincha ular xatolarga to'la, noto'g'ri binolardan kelib chiqadi va ko'pincha ba'zi original (har doim ham muvaffaqiyatli bo'lmagan) materiallarning nusxalari bo'lib, mavjud asosiy xatolarga o'zlarini qo'shadi. Natijada, PKI-ni joylashtirishda ko'plab nosozliklar. Buni forumlardagi tegishli mavzular soniga qarab baholash mumkin (xususan, TechNet Server Security). Yuqori sifatli hujjatlar Ingliz yetarli emas, lekin rus tilida... Ushbu maqolalar turkumi ana shu bo‘shliqni to‘ldirish va zamonaviy ishlanmalarni tizimlashtirishga qaratilgan.
 

Umumiy qoidalar

PKI standartga asoslangan xavfsizlik texnologiyasidir X.509 va raqamli sertifikatlardan foydalanadi. PKIning maqsadi ma'lumotlarni ruxsatsiz kirishdan va ma'lumotlarni himoya qilish mexanizmlarini taqdim etish orqali korxona IT infratuzilmasi xavfsizligini yaxshilashdan iborat. noqonuniy o'zgartirish ma'lumotlar (ma'lumotlarni soxtalashtirish). Bunga ikkita asosiy kriptografik mexanizm orqali erishiladi:

• Shifrlash- kriptografik kalitlar yordamida ma'lumotlarni shifrlash orqali ma'lumotlarni uchinchi shaxslar tomonidan ruxsatsiz kirishdan himoya qiladi. Faqat kerakli kalitlarga ega foydalanuvchilar ma'lumotlarga kirishlari mumkin. Shifrlash ma'lumotlar maxfiyligini ta'minlaydi, ammo buzg'unchilikdan himoya qilmaydi.
• Raqamli imzo– raqamli imzoni tashkil etuvchi ma’lumotlarga maxsus algoritmlarni qo‘llash orqali ma’lumotlarni ruxsatsiz o‘zgartirish yoki soxtalashtirishdan himoya qiladi. Ma'lumotlarni o'zgartirish bo'yicha har qanday manipulyatsiyalar tekshirish vaqtida darhol aniqlanadi raqamli imzo. Raqamli imzo ma'lumotlarning maxfiyligini emas, balki uning yaxlitligini ta'minlaydi. Shifrlash va raqamli imzolarni birlashtirib, siz maxfiylikni ta'minlashingiz va ma'lumotlarni ruxsatsiz o'zgarishlardan himoya qilishingiz mumkin.

Oddiy PKI infratuzilmasi quyidagi tarkibiy qismlardan iborat:

• Sertifikatlash markazi(CA) - iste'molchilarga raqamli sertifikatlar taqdim etadigan va PKI ishlashini ta'minlaydigan xizmat.
• Bekor qilish serveri- ma'lum bir CA tomonidan berilgan bekor qilingan (buzilgan yoki yaroqsiz) sertifikatlar ro'yxati haqida ma'lumot beruvchi xizmat.
• Mijoz– sertifikatlashtirish organidan sertifikatlangan raqamli sertifikat oluvchi. Mijozlar odamlar, qurilmalar, dasturiy ta'minot va boshqa CA bo'lishi mumkin.

CA va sertifikatlarning tuzilishi daraxt ierarxiyasida joylashtirilgan. Har bir CA bir yoki bir nechta (birlashtirgan) rollarni bajarishi mumkin:

• Ildiz CA – maxsus turi O'z-o'zidan imzolangan sertifikatga ega bo'lgan va daraxtning ildizi bo'lgan CA (shuning uchun nomi). Ushbu turdagi CA ma'lum bir ierarxiyadagi (daraxt) barcha sertifikatlar uchun ishonchning boshlang'ich nuqtasidir. Boshqacha qilib aytganda, mijoz daraxtning qolgan qismida joylashgan sertifikatlarga ishonish uchun ma'lum bir ildiz sertifikatiga (ya'ni emitent va ochiq kalit kombinatsiyasiga) aniq ishonishi kerak. Shuni ta'kidlash kerakki, ishonch o'tish davridir. Yakuniy sertifikatni tekshirishda mijoz yakuniy sertifikatdan ierarxiyaning yuqori qismiga zanjir (yo'l) quradi ( ildiz sertifikati). Va agar mijoz vertexga ishonsa, u holda tranzitivlik asosida yakuniy sertifikatga ishonish uchun sabablar bo'ladi.
• CA siyosatchisi- texnik jihatdan, bu boshqalar bilan bir xil CA (ierarxiya bo'yicha), farqi bilan to'ldiriladi xorijiy siyosatchilar va raqamli sertifikatlarni berish va ulardan foydalanish cheklovlari.
• CA nashriyoti- bu CA umumiy maqsad, u iste'molchilarga raqamli sertifikatlarni imzolaydi va beradi.

Sertifikat zanjirlarini yaratish jarayonini tushunish uchun men quyidagi maqolani o'qishni maslahat beraman: Sertifikat zanjiri mexanizmi - bu qanday ishlaydi. Ushbu maqola Microsoft CryptoAPI platformasiga qaratilgan bo'lib, u kriptografik platformalarning boshqa ilovalari uchun ham amal qiladi (ba'zi istisnolardan tashqari).

CAlar daraxt ierarxiyasida joylashtirilganligi sababli, ko'p darajali ierarxiyani tashkil qilish mumkin, bunda har bir darajada CA ham CA chiqarish rolini o'ynaydi, ham qo'shimcha funktsiyalar. Eng ichida oddiy holat bitta CA barcha rollarni birlashtira oladi, ya'ni. root bo'ling, qandaydir chiqarish siyosatini taqdim eting va oxirgi foydalanuvchilarga sertifikatlar bering. Yirik kompaniyalar va/yoki IT jarayonlarini yanada etukroq tashkil etgan kompaniyalar allaqachon CA ni rollar bo'yicha ajratishdan foydalanadilar. Masalan, bosh ofisda ular sertifikatlarni faqat o'zlariga emissiya siyosatini yuklaydigan boshqa CAlarga beradigan ildiz CA saqlaydi. Ular to'g'ridan-to'g'ri yakuniy iste'molchilarga xizmat ko'rsatishi mumkin emas, balki boshqa bo'ysunuvchi CAlarga sertifikatlar beradi, bu esa o'z navbatida yakuniy iste'molchilarga xizmat qiladi. Har bir yondashuv o'zining ijobiy va salbiy tomonlariga ega, ular quyida muhokama qilinadi.

Sertifikatlarni bekor qilish

Sertifikatlarni berish vazifalariga qo'shimcha ravishda, har bir CA vaqti-vaqti bilan Sertifikatlarni bekor qilish ro'yxatlarini (CRLs) chiqaradi. Sertifikatlar singari, bekor qilish ro'yxatlarining yaxlitligi elektron raqamli imzo bilan ta'minlanadi. CRL o'z ichiga oladi seriya raqamlari sertifikatning amal qilish muddati rasmiy tugashidan oldin biron-bir sababga ko'ra tugatilgan sertifikatlar. Shunday qilib, CA o'z vaqtida qaytarib olishni ta'minlaydi yaroqsiz sertifikat muomaladan tashqarida.

Har bir mijoz, zanjir orqali sertifikat ishonchini o'rnatgandan so'ng, zanjirdagi hech qanday sertifikat uning emitenti tomonidan bekor qilinmaganligiga ishonch hosil qilishi kerak. Buning uchun mijoz zanjirdagi har bir sertifikatni takrorlaydi, emitent tomonidan taqdim etilgan CRL ni tanlaydi va CRL ro'yxatida joriy sertifikat mavjudligini/yo'qligini tekshiradi. Agar joriy sertifikat CRLda bo'lsa, sertifikatga ishonch (va uning ostidagi daraxtning barcha shoxlari) avtomatik ravishda buziladi.

Haqiqatan ham, agar CA ildizi o'zining barcha to'g'ridan-to'g'ri berilgan sertifikatlarini bekor qilgan bo'lsa, ierarxiya balandligidan qat'i nazar, ushbu ildiz ostidagi hech qanday sertifikat ishonchli bo'lmaydi. Bu erda bir muhim va asosiy jihatni ta'kidlash kerak: ildiz (o'z-o'zidan imzolangan) sertifikatni bekor qilish mumkin emas. Bular. agar biron sababga ko'ra u buzilgan bo'lsa, uni faqat har bir mijozning sertifikatlar do'konidan sertifikatni majburan o'chirish orqali bekor qilish mumkin. Gap shundaki, CA ko'rib chiqish ro'yxatlarini o'zi uchun belgilamaydi, nashriyotchi belgilaydi. O'z-o'zidan imzolangan sertifikat bo'lsa, CA o'zining emitentidir. Va o'zingizni bekor qilish ro'yxatiga kiritishga harakat qilganingizda, siz noaniqlikka ega bo'lasiz: CA sertifikati xuddi shu CA kaliti bilan imzolangan CRL-ga kiritilgan. Agar CA sertifikati haqiqiy emas deb hisoblasak, CRL-dagi raqamli imzo haqiqiy emas. Natijada, ildiz CA sertifikati bekor qilinganligini ishonchli tasdiqlash mumkin emas. Bundan tashqari, ildiz sertifikatlarini bekor qilish RFC 5280 asosiy me'yoriy standartida ko'zda tutilmagan, uning §6.1-bandida:

Ishonch langari o'z-o'zidan imzolangan sertifikat shaklida taqdim etilganda, bu o'z-o'zidan imzolangan sertifikat istiqbolli sertifikatlash yo'lining bir qismi sifatida kiritilmaydi.

Va faqat istiqbolli zanjir bekor qilish uchun tekshiriladi. Agar biz Microsoft ADCS kontekstida gapiradigan bo'lsak, vaziyat yanada yomonlashadi. Xususan, certutil.exe yoki CryptoAPI yordamida ildiz sertifikatini texnik jihatdan bekor qilishingiz mumkin. Lekin buni qilganingizdan so'ng, CA hech qanday CRL imzolay olmaydi va natijada CA sertifikati hech qachon CRLga kiritilmaydi. Bundan tashqari, agar siz turli xil yordamchi dasturlardan foydalansangiz ham (bir xil certutil.exe), siz CA sertifikatini CRL-ga majburan kiritishingiz mumkin, ammo bu ko'p yordam bermaydi. Gap shundaki, CryptoAPI-ning standart konfiguratsiyasi ildiz sertifikatini bekor qilish uchun tekshirishga ham urinmaydi.

Ildiz sertifikatlarini bekor qilish muammosi ko'p hollarda kompaniya uchun to'g'ri CA ierarxiyasini tanlashda hal qiluvchi omillardan biri bo'ladi. Shuningdek, u ildiz CA ni buzish xavfini minimallashtirish maqsadida asosiy CA uchun qo'shimcha xavfsizlik choralarini ko'radi.

PKI ierarxiyasini joylashtirishning odatiy sxemalari

Ushbu bo'limda biz PKI ierarxiyasini korxona sharoitida o'rnatish uchun odatiy (yoki klassik) sxemalarni ko'rib chiqamiz va har bir sxemani baholaymiz va tavsiyalar beramiz. Shuni ta'kidlash kerakki, ularning hech biri universal emas va har biri o'z chegaralarida mantiqiy bo'lishi mumkin.

Bir darajali ierarxiya

Bir darajali ierarxiyani amalga oshirish eng oddiy va quyidagi shaklga ega:

Ushbu ierarxiya resurslar (litsenziyalar) va texnik xizmat ko'rsatish va boshqarish xarajatlari nuqtai nazaridan ham eng sodda va eng tejamkor hisoblanadi. Active Directory o'rmonida bitta CAni joylashtirish kifoya va u barcha iste'molchilarga sertifikatlar beradi. Aniq bo'lmagan, ammo muhim afzalliklar orasida biz sertifikatlarning juda qisqa zanjirini qayd etishimiz mumkin. Bular. ishonchnomani tekshirish va sertifikatni bekor qilish uchun sarflangan vaqt boshqa ierarxiyalarga qaraganda ancha kam bo'ladi.

Biroq, bir darajali ierarxiya bir qator etarli darajaga ega muhim kamchiliklar. Ulardan eng kattasi past daraja xavfsizlik. Mijozlar sertifikat so'rashi uchun ushbu dizayndagi CA har doim onlayn bo'lishi kerakligi sababli, uning buzilishi xavfi sezilarli darajada oshadi. Murosaning oqibatlari dahshatli bo'lishi mumkin, jumladan Active Directory ustidan nazoratni to'liq yo'qotish va IT tizimlarining qulashi. Bunga xavfsizlik choralarining etarli emasligi, yamalmagan OS zaifliklari yoki masofaviy kodni bajarishga imkon beruvchi tizim komponentlarining mavjudligi va boshqalar sabab bo'lishi mumkin. Yuqorida ta'kidlab o'tilganidek, bunday sertifikat endi an'anaviy tarzda bekor qilinishi mumkin emas va oqibatlari haqiqatan ham og'ir bo'ladi.

Yana bir nuqta CA ni bo'lishning moslashuvchanligi bilan bog'liq funktsional darajalari(delegatsiya). Masalan, bir nechta turli xil emissiya siyosatlarini tashkil qilish, ularni sinflarga bo'lish mumkin emas (masalan, bitta CA faqat mashinalar va qurilmalar uchun sertifikatlar chiqaradi, boshqasi faqat foydalanuvchilar uchun) va hokazo, chunki faqat bitta.

Bir darajali ierarxiyaning kamchiliklari engillik va ixchamlikdagi afzalliklaridan sezilarli darajada ustundir. Shuning uchun bunday konfiguratsiya faqat xavfsizlik talablari past bo'lgan ba'zi kichik va izolyatsiya qilingan tarmoqlarda mantiqiy bo'ladi. Misol uchun, bu qandaydir sinov muhiti bo'lishi mumkin. Ushbu yechim biznes muhitida foydalanish uchun tavsiya etilmaydi.

Ikki darajali ierarxiya

Ikki darajali ierarxiya allaqachon daraxtda kamida ikkita CAni nazarda tutadi, ulardan biri qat'iy ildiz, qolganlari esa bo'ysunuvchilardir. Bunday ierarxiya diagrammasi quyida keltirilgan:

Eslatma: Bu yerdagi nuqtali chiziqlar sertifikat olishning qo'lda (avtomatlashtirilmagan) jarayonini ko'rsatadi. Qattiq chiziqlar bilan belgilangan avtomatlashtirilgan jarayon sertifikatlar olish.

Ikki darajali ierarxiyada bir darajali ierarxiyaning kamchiliklarini hal qilish allaqachon mumkin. Bu erda ildiz CA faqat bo'ysunuvchi CAlar uchun sertifikatlar chiqaradi va bo'ysunuvchi CA oxirgi foydalanuvchilarga sertifikatlar beradi. CA nashr qilish kamroq tarqalganligi va ancha uzoq umrga ega bo'lganligi sababli, bu ildiz CA ni tarmoqdan ajratish imkonini beradi. Bu avtomatik ravishda bunday CAni buzish ehtimolini nolga kamaytiradi, chunki tarmoqsiz unga etib bo'lmaydi. Bundan tashqari, u hayotining ko'p qismini yopiq holatda o'tkazishi mumkin (va kerak). Yangilash uchun faqat uni yoqishingiz kerak. o'z sertifikati, bo'ysunuvchi CA yoki yangi CRL nashr qilish uchun. Qolgan vaqtda unga hech kim kerak emas.

Ikki darajali ierarxiyaning yana bir afzalligi - bo'ysunuvchi CA larni sinflarga bo'lishda yaxshilangan moslashuvchanlikdir. Ikki CA boshqarilsa, xuddi shunday odatiy stsenariy turli bo'limlar IT va har bir CA o'z iste'molchilar guruhlari uchun sertifikatlar chiqaradi. Masalan, mashinalar uchun alohida, foydalanuvchilar uchun alohida. Korporativ ishlab chiquvchilar (odatda o'z muhitlarida yashaydilar) o'zlariga bo'ysunuvchi CAni ajratishlari mumkin.

Bu erda siz siyosatlarni (yoki sinflarni) chiqarish orqali CAlarni bo'lish haqida o'ylashni boshlashingiz mumkin. Masalan, siz bitta CAni kengaytirilgan sertifikat talablari (masalan, autentifikatsiya va raqamli imzo uchun sertifikatlar) va umumiy maqsadli CA bilan sertifikatlar berishga bag'ishlashingiz mumkin. Ular IT ma'murlarining turli guruhlari tomonidan boshqarilishi mumkin. Bunday holda, har bir bo'ysunuvchi CA siyosat CA va chiqargan CA vazifalarini birlashtiradi. Agar sinfdagi CA soni bittadan ko'p emas deb hisoblasak, bu juda maqbuldir.

Yagona kamchiliklar ma'muriy va moliyaviy xarajatlarning biroz oshishini o'z ichiga oladi (qo'shimcha litsenziya talab qilinadi). Ma'muriy xarajatlar har bir CAning amal qilish muddatini va ildiz CAni bekor qilish ro'yxatini kuzatishni, shuningdek ularni o'z vaqtida yangilashni o'z ichiga oladi. Bundan tashqari, sertifikat zanjirlarini yaratish va tekshirish vaqti biroz oshadi, chunki yana bir daraja qo'shiladi. Amalda, bu vaqt amalda sezilmaydi.

Kichik va o'rta korxonalar uchun ushbu sxema eng maqbuldir, chunki u sizga tegishli darajadagi xavfsizlik va xavfsizlikni ta'minlashga imkon beradi. qabul qilinadigan daraja CAni muayyan funktsiyalarga bo'lishning moslashuvchanligi.

Uch yoki undan ortiq darajali ierarxiyalar

Murakkab tarmoqlarga ega yirik kompaniyalarda ikki darajali ierarxiya ta'minlay olmasligi mumkin talab darajasi CA boshqaruvining moslashuvchanligi. Misol uchun, kompaniya har bir mintaqada IT bo'limlarining nisbiy avtonomiyasi bilan geografik ajratish printsipidan foydalanganda. Mintaqaviy ofislari bo'lgan xalqaro kompaniyani tasavvur qiling turli mamlakatlar. Ular xavfsizlik masalalari bo'yicha, masalan, shaxsiy ma'lumotlarni qayta ishlashda o'z qonunlariga ega bo'lishi mumkin. Bunday huquqiy rasmiyatchiliklarga rioya qilish uchun har bir bunday mintaqaga o'z siyosati CA ajratiladi (shu bilan birga, u, qoida tariqasida, kompaniyaning bosh ofisida joylashgan). Sertifikatida u ma'lum me'yoriy hujjatlarni qo'llab-quvvatlashni (va tegishli hujjatga havolani) ko'rsatadi va sertifikatda (taxminan aytganda, ma'lum bir mintaqada) ko'rsatilgan siyosatlar doirasida ishlaydigan CAlarni chiqarish uchun sertifikatlar beradi.

Bunday ierarxiyalarda ildiz CA va CA siyosati tarmoqdan ajratilgan va tarmoqqa faqat emitent CA ulangan:

CA uchun sertifikat olishning qo'lda jarayoni va qattiq chiziqlar mijozlar uchun sertifikat olishning avtomatlashtirilgan jarayoni.

Ushbu sxemaning afzalliklari deyarli har qanday sharoitga moslashish qobiliyatiga ega bo'lgan PKI ning moslashuvchanligini o'z ichiga oladi. To'g'ri, buning uchun siz to'lashingiz kerak bo'ladi. Birinchidan, ko'p darajali ierarxiyalar PKIni joylashtirish va saqlash xarajatlarini oshiradi. Ikkinchidan, mijozlar to'liq sertifikat zanjirlarini qurish va bekor qilish uchun ko'proq vaqt talab etadilar, bu esa protokolning yuqori qismidagi kutish vaqtlari oshib ketishi tufayli muvaffaqiyatsizlikka olib kelishi mumkin. Va amalda bunday sxemalar ko'pincha ortiqcha bo'ladi. Shuning uchun, mos CA ierarxiyasini tanlayotganda, siz PKIni saqlash uchun kapital va operatsion xarajatlarni hisobga olgan holda moslashuvchanlik va amaliylik o'rtasidagi muvozanatni izlashingiz kerak.

Ushbu maqolalar turkumida eng mashhur (ko'p hollarda) ikki darajali ierarxiya muhokama qilinadi.

Muallif haqida

Vadim Podans- PowerShell va ochiq kalitlar infratuzilmasini avtomatlashtirish bo'yicha mutaxassis, Microsoft MVP: 2009 yildan beri bulut va ma'lumotlar markazini boshqarish va PowerShell PKI moduli muallifi. 9 yildan beri u o'z blogida yoritib kelmoqda turli savollar korxonada PKI ning ishlashi va avtomatlashtirilishi. Vadimning PKI va PowerShell haqidagi maqolalarini uning “Tasavvur qilaylik, bizda ikkita server bor, ular o‘zlari uchun ishlaydi” va vaqti-vaqti bilan HTTP/HTTPS protokoli orqali bir-birlaridan nimanidir so‘ramoqchi bo‘ladi.

HTTP protokoli xavfsiz emas va serverlar o'rtasidagi aloqa uchun HTTPS protokolidan foydalanish mantiqan to'g'ri keladi.

Bunday aloqani tashkil qilish uchun bizga 2 ta SSL sertifikati kerak.

Agar serverlar bir tashkilotga tegishli bo'lsa, sertifikatlarni sotib olishdan ko'ra o'zingiz imzolash osonroq va xavfsizroq bo'lishi mumkin.

Bizning CA yaratish

Birinchi buyruq ildiz kalitini yaratadi

Openssl genrsa -out rootCA.key 2048
Men uchun 2048 bitli kalit yetarli, agar xohlasangiz 4096 bitli kalitdan foydalanishingiz mumkin.

Ikkinchi buyruq ildiz sertifikatini yaratadi.

Openssl req -x509 -yangi -kalit rootCA.key -kun 10000 -out rootCA.crt
Siz bu yerda savollarga o'zingizning xohishingiz bilan javob berishingiz mumkin.

Mamlakat nomi (2 harfli kod) : Shtat yoki viloyat nomi (toʻliq nomi) : Mahalliy nomi (masalan, shahar) : Tashkilot nomi (masalan, kompaniya) : Tashkilot birligi nomi (masalan, boʻlim) : Umumiy ism (masalan, server FQDN yoki SIZNING nomi): Elektron pochta manzili:
Uning amal qilish muddati 10 000 kunni tashkil etadi, bu Google Android ilovalariga imzo qoʻyish uchun talab qiladigan sertifikatning amal qilish muddatiga teng. Google Play. Agar siz signalist bo'lsangiz, bir yoki ikki yilga ro'yxatdan o'ting.

Hammasi! Endi biz serverlarimiz uchun sertifikatlar yaratishimiz va ildiz sertifikatini mijoz mashinalarimizga o'rnatishimiz mumkin.

Biz CA tomonidan imzolangan sertifikat yaratamiz

Kalit yaratish.

Openssl genrsa -out server101.mycloud.key 2048
Sertifikat so'rovini yarating.

Openssl req -new -key server101.mycloud.key -out server101.mycloud.csr
Bu erda server nomini ko'rsatish muhim: domen yoki IP (masalan, domen server101.mycloud)

Umumiy ism (masalan, SIZNING ismingiz): server101.mycloud
va sertifikat so'rovini ildiz sertifikatimiz bilan imzolang.

Openssl x509 -req -in server101.mycloud.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server101.mycloud.crt -kunlar 5000
Endi siz rootCA.crt sertifikatini mijozlarga o'rnatishingiz kerak

rootCA.crt- siz uni do'stlaringizga berishingiz, o'rnatishingiz, serverdan nusxa ko'chirishingiz, ommaviy foydalanishga joylashtirishingiz mumkin
rootCA.key- sir saqlanishi kerak

Ildiz sertifikati o'rnatilmoqda

Windows

IE, Chrome - Windows sertifikatlar omboridan foydalaning.

Mening unga boradigan yo'lim quyidagicha:

Chrome - Sozlamalar - Sertifikatlarni boshqarish…
Ishonchli ildiz sertifikat organlari - Import - rootCA.crt yorlig'ini tanlang
Chrome-ni qayta ishga tushiring

Windows-dagi FireFox o'z omboriga ega.

Java-ning o'z ombori mavjud.

Mac OS X

Safari, FireFox, Chrome - tizim omboridan foydalaning.

KeyChain Access-ni ishga tushiring.
Menyuga o'ting Fayl - Import ob'ektlari (kirish yoki tizim) - faylni tanlang rootCA.crt.
So'raganda, biz javob beramiz - Har doim ishoning.

Shaxsiy Safari uchun loginni tanlang.

Ubuntuda

sudo mkdir /usr/share/ca-certificates/extra sudo cp rootCA.crt /usr/share/ca-certificates/extra/rootCA.crt sudo dpkg-reconfigure ca-certificates sudo update-ca-certificates

Go'da server dasturi

Imzolangan sertifikatimizdan foydalanadigan Go server dasturi myserver.go.
paketning asosiy importi ("log" "net/http") func main() ( http.Handle("/files/", http.StripPrefix("/files/", http.FileServer(http.Dir("./files)" /")))) go func() ( log.Fatal(http.ListenAndServeTLS(":8443", "server101.mycloud.crt", "server101.mycloud.key", nil)) )() http.ListenAndServe( ":8080", nol))
myserver.go-ni ishga tushiring
Dasturni server101.mycloud serverida ishga tushirish orqali brauzeringiz https://server101.mycloud:8443/ sahifasidan shikoyat qilmaydi va tizimda rootCA.crt ni ilgari o'rnatgan bo'lsangiz, uni mahalliy sifatida ochadi. ildiz sertifikati sifatida.

Pythonda server

Import BasHTTServer, SellinHTTServer, SSL httpd = BasmpServer.htttserver (httpd1wApp_sock (httpd1wets, server_side = rost) httpd.serve_forever()

# kalit va sertifikatni bitta faylga nusxalash cat server101.mycloud.key server101.mycloud.crt > server101.mycloud.pem # serverni python python myserver.py da ishga tushirish

PS

Shuni ta'kidlash kerakki, joker sertifikatlar xavfsiz emas, agar tajovuzkor bitta serverdan joker sertifikatga ega bo'lsa, u boshqa barcha serverlarga xavf tug'diradi. Virtual bulutli serverlar har qachongidan ham mashhur. Ko'pincha fon vazifalari alohida virtual serverlarda bajariladi. Bunday serverlar soni doimiy ravishda o'sib bormoqda. Uning sertifikat organi muhim element butun tizimning xavfsizligi.

SSL(Secure Sockets Layer) - mijoz va server o'rtasida xavfsiz ulanishni o'rnatishni ta'minlaydigan kriptografik protokol. Keyinchalik, SSL 3.0 protokoli asosida TLS deb nomlangan RFC standarti ishlab chiqildi va qabul qilindi.

Protokol TCP/IP-dan foydalangan holda mijoz va server o'rtasidagi maxfiy aloqani ta'minlaydi va shifrlash uchun assimetrik ochiq kalit algoritmidan foydalanadi. Ochiq kalitni shifrlash ikkita kalitdan foydalanadi va bittasi xabarni shifrlash uchun ishlatilishi mumkin. Shunday qilib, agar biz shifrlash uchun bitta kalitdan foydalansak, demak, shifrni ochish uchun boshqa kalitdan foydalanishimiz kerak. Bunday vaziyatda biz ochiq kalitni nashr qilish va maxfiy kalitni sir saqlash orqali xavfsiz xabarlarni olishimiz mumkin.

SSL protokoli ikkita kichik protokoldan iborat: SSL yozish va qo'l siqish protokoli. SSL yozish protokoli ma'lumotlarni uzatish uchun ishlatiladigan formatni belgilaydi. SSL protokoli birinchi ulanish o'rnatilganda server va mijoz o'rtasida bir qator xabarlar almashish uchun SSL rekord protokoli yordamida qo'l siqishni o'z ichiga oladi.

Autentifikatsiya va kalit almashinuvi.

SSL autentifikatsiyaning uchta turini qo'llab-quvvatlaydi: ikkala tomonning autentifikatsiyasi (mijoz - server), autentifikatsiya qilinmagan mijoz bilan server autentifikatsiyasi va to'liq anonimlik. Har safar server autentifikatsiya qilinganida, kanal o'rtadagi odam hujumiga qarshi xavfsizdir, ammo mutlaqo anonim seans bunday hujumga tabiiy ravishda zaifdir. Anonim server mijozni autentifikatsiya qila olmaydi. Agar server autentifikatsiya qilingan bo'lsa, uning sertifikatlash xabari qabul qilinadigan sertifikat organiga olib boradigan haqiqiy sertifikatlashtirish zanjirini taqdim etishi kerak. Oddiy qilib aytganda, autentifikatsiya qilingan mijoz serverga haqiqiy sertifikat taqdim etishi kerak. Har bir tomon boshqa tomonning sertifikatining amal qilish muddati hali tugamagan yoki bekor qilinmaganligini tekshirish uchun javobgardir. Asosiy maqsad kalit almashish jarayoni faqat mijoz va serverga ma'lum bo'lgan mijoz sirini (pre_master_secret) yaratishdir. Yashirin (pre_master_secret) umumiy sirni (master_secret) yaratish uchun ishlatiladi. Umumiy sir sertifikatni, shifrlash kalitlarini, MAC sirini (xabarning autentifikatsiya kodi) va "tugallangan" xabarni tekshirish uchun xabar yaratish uchun kerak. To'g'ri "tugallangan" xabarni yuborish orqali tomonlar to'g'ri sirni bilishlarini isbotlaydilar (pre_master_secret).

SSL sertifikati kimga kerak va nima uchun?

2018 yildan boshlab har bir veb-saytga SSL sertifikati o'rnatilishi kerak. Agar siz yangi veb-sayt ochayotgan bo'lsangiz, u shunchaki ma'lumot beruvchi sayt yoki blog bo'lsa ham, unda SSL sertifikati o'rnatilgan bo'lishi kerak. Googleda SSL sertifikatining mavjudligi yoki yo'qligi ( HTTPS protokoli) veb-saytingiz uchun reyting omillaridan biridir.

SSL sertifikati firibgarlarning foydalanuvchilar sizning veb-saytingizga kiritgan shaxsiy ma'lumotlarini ushlashiga yo'l qo'ymaslik uchun kerak. Shaxsiy ma'lumotlar - bu hisob loginlari va parollari, bank kartalari raqamlari, manzillar elektron pochta va hokazo. Bu shuni anglatadiki, SSL sertifikati bank veb-saytlarida foydali bo'ladi, to'lov tizimlari, korporatsiyalar, onlayn-do'konlar, ijtimoiy tarmoqlar, davlat korxonalari, onlayn forumlar va boshqalar.

SSL sertifikati sayt egasi uchun foydalidir: bu orqali siz saytga shaxsiy maʼlumotlarni kiritish xavfsiz ekanligini tasdiqlaysiz va mijozlarga tashvish bildirasiz. Agar odam tashvishlansa maxfiy ma'lumotlar noto'g'ri qo'llarga tushadi, u oladi qo'shimcha kafolatlar. Foydalanuvchilar uchun kamroq xavf, yuqori kompaniya obro'si.

SSL sertifikati, sertifikatlash organi.

SSL ishlashi uchun serverda bo'lishi kerak SSL sertifikati. Shifrlash texnologiyasi sertifikatlarga tayanmaydi, lekin ular faqat bir-biri bilan aloqa o'rnatmoqchi bo'lgan xostlar muloqot qilishini ta'minlash uchun zarurdir. Agar har bir xost boshqasining sertifikatini tekshira olsa, ular seansni shifrlashga rozi bo'lishadi. IN aks holda ular shifrlashni butunlay rad etishadi va ogohlantirish yaratadilar, chunki... haqiqiylik yo'q.

Sertifikat organi yoki Sertifikatlash organi (CA) - elektron raqamli imzo kalitlari sertifikatlarini chiqaradigan tashkilot yoki bo'linma, u foydalanuvchilarning kriptografik kalitlarini boshqarish uchun mas'ul bo'lgan global ma'lumotnoma xizmatining tarkibiy qismidir; Ochiq kalitlar va foydalanuvchilar haqidagi boshqa ma'lumotlar sertifikatlashtirish organlari tomonidan quyidagi tuzilishga ega raqamli sertifikatlar ko'rinishida saqlanadi:

Sertifikatning seriya raqami;

Elektron imzo algoritmining obyekt identifikatori;

Sertifikatlash organining nomi;

Eng yaxshi sanadan oldin;

Sertifikat egasining nomi (sertifikat egasining nomi);

Sertifikat egasining ochiq kalitlari (bir nechta kalitlar bo'lishi mumkin);

Sertifikat shuningdek, Umumiy nom qatorida to'liq malakali domen nomini (RFC 821 FQDN) o'z ichiga oladi. biri mumkin bo'lgan hujumlar- DNS-spoofing - ma'lumotlar yuborilishidan oldin aniqlanadi.

SSL sertifikatlarining turlari

Ajratish har xil turlari Tekshiruv turiga qarab SSL sertifikatlari:

Domen tomonidan tasdiqlangan sertifikatlar - domen nomining haqiqiyligini tasdiqlang. Kompaniya haqida ma'lumot mavjud emas.

Kompaniya tomonidan tasdiqlangan sertifikatlar - nafaqat domen haqida, balki sertifikat berilgan kompaniya haqida ham ma'lumotlarni o'z ichiga oladi. Ular foydalanuvchilar tomonidan juda ishonchli.

Domen va subdomenlar uchun sertifikatlar ( Joker belgi SSL) - bitta sertifikat bilan cheksiz miqdordagi subdomenlarni himoya qilish. Sertifikat ma'lum bir muddat uchun beriladi domen nomi va shu bilan birga barcha subdomenlarni himoya qiladi. Ushbu sertifikatlar domen tomonidan tasdiqlangan yoki tashkilot tomonidan tasdiqlangan bo'lishi mumkin.

Extended Validation SSL (EV SSL) sertifikatlari mijozlar ishonchining eng yuqori darajasini ta'minlaydi. Agar foydalanuvchi EV SSL sertifikatiga ega bo'lgan saytda bo'lsa, brauzer manzil satrini yashil rangda ajratib ko'rsatadi.

Wildcard SSL sertifikatlari nafaqat asosiy domenni (your_domain.ru), balki subdomenlarni (www.your_domain.ru, ssl.your_domain.ru, secure.your_domain.ru va boshqalar) himoya qiluvchi sertifikatlardir. Veb-server va pochta serverlarida foydalanish mumkin. Wildcard sertifikatiga so'rovni yaratishda umumiy nom (CN) sifatida "*.domain.com" dan foydalaning, bu erda domain.com sizning domen nomingizdir.

Bepul sertifikatlash idoralari

Sizga qanday sertifikat organi kerak? Hammasi sertifikatdan foydalanish holatiga bog'liq.

• Shaxsiy foydalanish. Agar siz sertifikatdan faqat shaxsiy maqsadlarda foydalanishni rejalashtirmoqchi bo'lsangiz, faqat sizga yoki cheklangan miqdordagi foydalanuvchilarga (masalan, kompaniyangiz xodimlariga) kerak bo'lganda, siz o'zingizning sertifikatlashtirish organiga aylanishingiz mumkin.

  Rasmiy foydalanish. Agar siz bilan rasmiy aloqada bo'lishingiz kerak bo'lsa tashqi foydalanuvchilar Va pochta serverlari, xizmatlarga murojaat qilishingiz kerak bo'ladi rasmiy markaz sertifikatlash.

Bepul sertifikat(sertifikat organi) brauzer tomonidan qo'llab-quvvatlanishi kerak, aks holda uni o'zingiz yaratish osonroq bo'ladi. Asosiysi, sertifikatni to'g'ri yaratish. Agar o'z-o'zidan imzolangan sertifikat to'g'ri yaratilgan bo'lsa, faqat sertifikatni tekshirishning iloji yo'qligi haqidagi xato ko'rsatiladi, masalan, Mozilla Thunderbird pochtasi: "Sertifikatni tekshirish mumkin emas - sertifikat bergan tomon ishonchsiz".

Sertifikat faqat berilgan bo'lsa foydali bo'ladi ishonchli markaz sertifikatlash (ular derazalarga o'rnatilgan) va agar u majburiyatlar bilan ta'minlangan bo'lsa (odatda 10 000 AQSh dollaridan). Boshqa barcha sertifikatlar o'z-o'zidan imzolangan sertifikatlardan farq qilmaydi, ularni istalgan davr uchun o'zingiz yaratishingiz mumkin.

Bepul markazlar SSL sertifikati:

• # nano /etc/dovecot/dovecot.conf ... ## SSL sozlamalari ssl_cert_file = /etc/dovecot/certs/imapd.pem ssl_key_file = /etc/dovecot/certs/imapd.pem ssl_ca_file = /etc/dovecot/certs/ imapd.pem...

  Barcha mavjud sertifikatlarni sanab o'ting

  Openssl s_client -connect 10.26.95.225:443 -showcerts SSLEngine yoqilgan # eski SSLv2 va SSLv3 protokollaridan foydalanishni o'chirib qo'ying SSLProtocol all -SSLv2 -SSLv3 # yoki o'chirish siz hamma narsani o'chirib qo'yishingiz va faqat keraklilarini yoqishingiz mumkin #SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2 SSLCertificateFile / etc/ apache2/ certs/ httpsd.pem SSLCertificateKeyFile / etc/ apache2/ certs/ httpsd.pem # SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem # SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key ...