VPN mijozi kalitini qanday yaratish va imzolash uchun CSR ni qanday topshirish

Erta yoki kech, VPN foydalanuvchisi administrator sertifikat yaratishi uchun maxfiy kalitni elektron pochta orqali yuborishni taklif qiladi va rad etish kerak bo'lgan narsa aynan shu taklifdir. Ishlaydigan oqim kalitni birinchi buyruqdan boshlab mijozda saqlaydi: mijoz uni yaratadi, sertifikatni imzolash so'rovini yuboradi, beruvchi uni tekshiradi va ruxsat beradi, imzolangan sertifikat esa qaytib kelib uni yaratgan kalitning yonida turadi. Quyidagi tekshiruv ro'yxati har qadamda yopiq tarzda muvaffaqiyatsiz bo'ladi va bu asosiy jihat, chunki besh qadamdan ikkitasi odamlar shoshganda o'tkazib yuboradigan qadamlardir.

1-qadam: kalitni u yashaydigan joyda yarating

Kalitni saqlaydigan mashinada yarating va o'sha yerda qoldiring. Dasturiy kalit qat'iy ruxsatlarga ega faylga tushadi; apparat bilan qo'llab-quvvatlanadigan yoki boshqariladigan ombordagi kalit hech qachon faylga aylanmaydi va uning ro'yxatga olish yo'li odatda OpenSSL buyrug'i emas, alohida vosita. Qanday bo'lmasin, hech kim maxfiy yarmini ko'rishi shart emas.

Dasturiy oqim shunday ko'rinadi, kalit va so'rov bitta sessiyada yaratiladi:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

umask qatori ko'ringanidan muhimroq. Usiz kalit sukut bo'yicha ruxsat beruvchi tizimda hamma o'qiy oladigan tarzda yoziladi va faylni keyin nusxalash buni tarqatadi. Mavjud kalitni qayta ishlatish u allaqachon himoyalangan va siyosatingizga mos bo'lsa qonuniy; har bir qurilma uchun yangisini yaratishni asoslash osonroq.

2-qadam: shaxsni so'rovga joylashtiring, elektron pochtaga emas

So'rov yaratilishidan oldin VPN aslida nimani autentifikatsiya qilishini hal qiling, chunki bu javob CSR ichiga tegishli. OpenVPN an'anaviy ravishda mijoz shaxsini sertifikatning umumiy nomiga bog'laydi va strongSwan kabi vositalar shaxs satrini sub'ekt yoki sub'ektning muqobil nomi bilan taqqoslaydi. Mening ismim alice deb aytadigan xat dalil emas va sub'ekti shu narsani aytadigan so'rov faqat biroz yaxshiroq.

Tekshiruvchingiz bittasini tekshirganda sub'ektning muqobil nomini qo'shing, chunki zamonaviy taqqoslash eski CN ni ko'pincha e'tiborsiz qoldiradi:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

CN ni qisqa, barqaror va noutbuk modeliga emas, hisobga bog'langan holda saqlang. Foydalanuvchi qurilmasining seriya raqamini o'z ichiga olgan nom birinchi apparat almashtirilishini kutayotgan qo'llab-quvvatlash muammosidir.

3-qadam: imzolashdan oldin so'rovni tekshiring

Beruvchi ikki xil narsani tekshiradi va ularni aralashtirish klassik xatodir. Birinchidan, so'rov ichki jihatdan izchil: imzo u olib yurgan ochiq kalitga qarshi tekshiriladi. Ikkinchidan, so'rovchi so'rov talab qilgan narsaga haqli va bunga hech qanday kriptografik tekshiruv javob bera olmaydi.

Mexanik qism bitta buyruq va u sub'ekt bilan birga tekshiruv natijasini chop etishi kerak:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

Bu nima isbotlashiga e'tibor bering. Tekshirilgan so'rov faqat yuboruvchida topshirish vaqtida mos maxfiy kalit bo'lganini ko'rsatadi; yuboruvchining sub'ektda nomlangan shaxs ekanini isbotlamaydi va so'ralgan guruh yoki marshrutga ruxsat bermaydi. Ro'yxatga olish ko'rigi alohida darvoza va hech kim tasdiqlamagan guruh uchun so'rov jimgina tahrirlanish o'rniga rad etilishi kerak.

4-qadam: ruxsat bering, so'ngra aniq kengaytmalar bilan imzolang

Imzolash CA so'rovni so'zma-so'z qabul qilish o'rniga siyosatni hal qiladigan joy. Amal qilish muddati, kalitdan foydalanish va rol kengaytmasi kengaytmalar fayliga tegishli, olti oydan keyin eslay olmaydigan standart qiymatlarga emas. VPN autentifikatsiyasi uchun mijoz sertifikatiga maqsad sifatida mijoz autentifikatsiyasi kerak.

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

Agar bittasi allaqachon ishlatilayotgan bo'lsa, mavjud seriya fayli bilan -CAserial dan foydalaning va CA kalitini oflayn yoki siyosatingiz nomlagan himoyalangan omborda saqlang. Sertifikatlarning seriya raqamlari har bir beruvchi uchun noyob bo'lishi kerak; seriya faylini noldan qayta yaratish bekor qilishni noaniq qiladigan to'qnashuvlar xavfini tug'diradi.

Nima berilganini yozib boring: seriya raqami, sub'ekt, so'ralgan shaxs, tasdiqlagan shaxs va muddat. Aynan shu yozuv keyin bekor qilish qarori tayanadigan narsadir va agar ro'yxatga olish izi faqat pochta qutisida yashasa, uni faqat sertifikatdan tiklab bo'lmaydi.

5-qadam: uni mos kalitning yoniga o'rnating va juftlikni isbotlang

Mijoz sertifikat va beruvchi zanjirini oladi, hech qachon kalitni emas. Ulanishdan oldin sertifikat diskda allaqachon mavjud kalit bilan haqiqatan juftlik hosil qilishini tasdiqlang, chunki mos kelmaydigan juftlik juda keyin chalkash qo'l berish xatosini keltirib chiqaradi:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

Ikki dayjest mos kelishi kerak. So'ngra ulanib, server qayd etadigan shaxs siz ruxsat bergan shaxs ekanini tasdiqlang, faqat tunnel ko'tarilganini emas. Agar kalit yo'qolsa yoki qurilma almashtirilsa, javob bekor qilish va yangi qurilmadan yangi so'rovdir; administratordan boshqa joydan kalitni qaytarib yuborishni so'rash asl nusxani tiklamaydi va so'rovni xavfsiz qilgan modelni jimgina buzadi.