OpenConnect token uchun qaysi PKCS#11 URI ga muhtoj?

To'g'ri kalitni allaqachon saqlagan smart-karta ham unda qaysi obyektdan foydalanishni bilishi kerak. OpenConnect bunday holatda nusxalangan .key faylini xohlamaydi; u sertifikatni nomlaydigan PKCS#11 URI ni, avtomatik qidiruv ishni tugata olmasa, yonidagi shaxsiy kalitni ham nomlashni xohlaydi. Noqulay jihati shundaki, sintaktik jihatdan to'g'ri URI hech narsani isbotlamaydi. U karta ochishga tayyor bo'lgan obyektni emas, shlyuz allaqachon ishonadigan yozuvni nomlashi kerak.

Mijoz eksport qilingan kalit o'rniga nima xohlaydi

-c parametri odatda fayl yo'lini oladi, lekin qiymat PKCS#11 URI sifatida tahlil qilinsa, OpenConnect uni diskdagi faylga emas, token ichidagi obyektga havola deb qaraydi. -k parametri shaxsiy kalit uchun ham xuddi shunday ishlaydi. Hech narsa eksport qilinmaydi va kalit karta beradigan himoyani hech qachon tark etmaydi. Mijoz sizdan token moduli, sertifikatlar ombori va shlyuz yozuvi kelishadigan nomni xohlaydi.

Ko'p urinishlar aynan shu oxirgi cheklovda to'xtaydi. URI juda yaxshi tuzilgan bo'lishi mumkin va baribir shlyuz rad etadigan sertifikatni tanlashi mumkin, chunki haqiqiylik va tegishlilik alohida savollardir. Qilishga arziydigan tekshiruv yozuv yozuvi bilan qiyoslashdir, tasodifan ochilgan birinchi obyektni izlash emas.

Ikki URI, ikki xil ish

Sertifikatning URI si qaysi shaxsni da'vo qilayotganingizga javob beradi. U ochiq kaliti va subyekt satri VPN administratori bergan hisob yoki qurilma profiliga mos keladigan sertifikat obyektiga ishora qiladi. Xuddi shu sertifikat odatda yonida saqlangan shaxsiy kalit obyekti bilan keladi va TLS qo'l berishiga aynan shu juftlik kerak.

Kalitning URI si OpenConnect buni aniqlay olmasa, mos keladigan shaxsiy material qayerda ekaniga javob beradi. Faqat -c o'rnatilgan bo'lsa, mijoz sertifikat xossalaridan kalit qidiruvini quradi; -k berish taxminni aniq obyekt havolasi bilan almashtiradi. Tokenning PIN i uchinchi, bog'liq bo'lmagan kiritishdir: u amal uchun kartani ochadi va hech qachon obyektni aniqlamaydi.

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

O'sha qo'shtirnoq ichidagi satrning barchasi ma'lumotdir. Nuqta-vergullar URI atributlarini ajratadi va foiz escape'lari tahlilni buzadigan belgilarni kodlaydi, shuning uchun butun argument qobiqdan sog'lom o'tishi kerak.

Yozuvingizga mos keladigan URI ni topish

GnuTLS bilan p11tool keladi, u joriy foydalanuvchi p11-kit orqali haqiqatda nimaga yeta olishini sanab beradi. p11tool --list-tokens bilan boshlang, so'ng sizga muhim bo'lgan tokendagi sertifikat obyektlarini sanang. Obyektlar faqat PIN dan keyin ko'rinsa --login qo'shing va birinchi ko'ringanini tanlash o'rniga subyekt va chiqaruvchini yozuv yozuvi bilan qiyoslang.

Agar token umuman ko'rinmasa, muammo OpenConnect ostida: p11-kit da o'sha oraliq dastur uchun ro'yxatga olingan modul yo'q yoki modul boshqa hisob uchun ro'yxatga olingan. Tizim darajasidagi ro'yxat /etc/pkcs11/modules ostida, foydalanuvchi papkasi esa tizim nusxasiga tegmasdan xuddi shu narsani saqlashi mumkin. Modul faylidagi provayder yo'li o'quvchi dasturi haqiqatda o'rnatgan kutubxonaga ishora qilishini tekshiring.

URI ni ro'yxatdan nusxalashda uning atrofidagi qo'shtirnoqlarni saqlang. Qo'shtirnoqsiz nuqta-vergullar argumentni birinchi atributda kesadi va mijoz keyin topa olmaydigan obyekt haqida xabar beradi.

Avtomatik kalit qidiruvi taslim bo'lganda

OpenConnect sertifikatning URI sidan kalit qidiruvini chiqara oladi, lekin u amalga oshiradigan aniq moslashtirish versiyaga bog'liq, obyekt turi va yorliq bilan ishlash vaqt o'tishi bilan o'zgargan. URI ni ishlaguncha qisqartirish haqidagi maslahat eski aylanma yo'lni tasvirlaydi, talabni emas. Chiqarilgan qidiruv muvaffaqiyatsiz bo'lsa, sertifikat URI sini yanada noaniq narsaga aylantirish o'rniga kalitni -k bilan aniq nomlang.

Mijozni ayblashdan oldin kalit borligini va p11tool --list-keys bilan ko'rinishini tasdiqlang. So'ng obyekt imzolash yoki deshifrlash uchun yaroqli deb belgilanganini tekshiring, chunki noto'g'ri atributlar bilan yaratilgan kalit URI qanchalik to'g'ri bo'lsa ham qo'l berishni tugata olmaydi. OpenVPN profilidagi ketma-ketlashtirilgan pkcs11-id qiymatini OpenConnect parametriga ko'chirmang; ikkala mijoz bir kart bilan gaplashsa ham turli identifikator formatlaridan foydalanadi.

Agar URI hal bo'lib, PIN qabul qilinsa, lekin autentifikatsiya baribir muvaffaqiyatsiz bo'lsa, URI ni sozlashni to'xtating. Shlyuzning o'z xatosini o'qing, chunki keyingi muvaffaqiyatsizlik tokendan yuqorida.

Faqat URI muammolariga o'xshaydigan muvaffaqiyatsizliklar

Boshqa protokolda gaplashadigan shlyuz URI ingiz to'g'ri yoki noto'g'ri bo'lishidan qat'i nazar bir xil muvaffaqiyatsizlikka uchraydi. OpenConnect eski vpnc mijozini biron sababga ko'ra almashtirgan va karta qo'llab-quvvatlashi mos kelmaydigan shlyuz protokolini mos qilmaydi. Obyekt atributlariga yana bir soat sarflashdan oldin serverning kutilgan protokoli va autentifikatsiya tartibini tasdiqlang.

Server shaxsini tekshirish ham alohida qatlam. Mijoz shlyuz sertifikatini o'z ishonch ombori bilan tekshiradi va bu tekshiruv karta o'z qismini bajarib bo'lgandan keyin ishlaydi. O'quvchi ruxsatlari va to'xtagan pcscd xizmati bir xil tashqi belgini keltiradi, o'qib bo'lmaydigan token, lekin tuzatish ancha oson.

Obyektdan tashqariga qarab ishlang: p11tool tokenni ko'radimi, sertifikat va kalitni ko'radimi, OpenConnect URI ni qabul qiladimi, shundan keyingina shlyuz shaxsni qabul qiladimi deb so'rang. Har bir qadamning o'z xato xabari bor va har birini tekshirish keyingisidan arzon.