OpenConnect token üçün hansı PKCS#11 URI tələb edir?

Artıq düzgün açarı saxlayan smart-kart yenə də ona hansı obyektin istifadə olunacağını deməlidir. OpenConnect belə halda kopyalanmış .key faylı istəmir; o, sertifikatı adlandıran PKCS#11 URI, avtomatik axtarış işi bitirə bilmədikdə isə yanındakı şəxsi açarı istəyir. Narahat edən hissə odur ki, sintaktik cəhətdən düzgün URI heç nə sübut etmir. O, şlüzün artıq etibar etdiyi qeydiyyatı adlandırmalıdır, sadəcə kartın açmağa hazır olduğu obyekti yox.

Müştəri ixrac edilmiş açar yerinə nə istəyir

-c seçimi adətən fayl yolunu qəbul edir, lakin dəyər PKCS#11 URI kimi təhlil olunduqda OpenConnect onu diskdəki fayla deyil, tokenin içindəki obyektə istinad kimi qəbul edir. -k seçimi şəxsi açar üçün eyni şəkildə davranır. Heç nə ixrac olunmur və açar kartın təmin etdiyi qorumanı heç vaxt tərk etmir. Müştərinin sizdən istədiyi, token modulunun, sertifikat anbarının və şlüz qeydiyyatının razılaşdığı bir addır.

Ən çox cəhd məhz sonuncu məhdudiyyətdə dayanır. URI tamamilə düzgün formalaşmış ola bilər və yenə də şlüzün rədd edəcəyi sertifikatı seçə bilər, çünki etibarlılıq və uyğunluq ayrı suallardır. Ən çox dəyər verilməli yoxlama qeydiyyat yazısı ilə müqayisədir, təsadüfən açılan ilk obyektin axtarışı deyil.

İki URI, iki fərqli iş

Sertifikat URI-si hansı kimliyi iddia etdiyinizi cavablandırır. O, açıq açarı və subyekt sətri VPN administratorunun verdiyi hesab və ya cihaz profilinə uyğun gələn sertifikat obyektinə işarə edir. Həmin sertifikat adətən yanında saxlanan şəxsi açar obyekti ilə gəlir və TLS mübadiləsinin həqiqətən ehtiyac duyduğu cüt budur.

Açar URI-si uyğun şəxsi materialın harada yerləşdiyini cavablandırır, o halda ki, OpenConnect bunu çıxara bilmir. Yalnız -c təyin edildikdə müştəri sertifikat xüsusiyyətlərindən açar axtarışı qurur; -k vermək təxmini açıq obyekt istinadı ilə əvəz edir. Token PIN-i üçüncü, əlaqəsiz girişdir: əməliyyat üçün kartı açır və heç vaxt obyekti müəyyən etmir.

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

Həmin dırnaqlı sətrin içindəki hər şey veridir. Nöqtəli vergüllər URI atributlarını ayırır, faiz qaçışları isə təhlili poza biləcək simvolları kodlaşdırır, ona görə də arqument bütövlükdə qabıqdan sağ çıxmalıdır.

Qeydiyyatınıza uyğun URI-ni tapmaq

GnuTLS p11tool alətini gətirir; o, cari istifadəçinin p11-kit vasitəsilə həqiqətən çata bildiyini sadalayır. p11tool --list-tokens ilə başlayın, sonra sizi maraqlandıran tokendəki sertifikat obyektlərini sadalayın. Obyektlər yalnız PIN-dən sonra görünürsə --login əlavə edin və ilk görünəni seçmək yerinə subyekti və verəni qeydiyyat yazısı ilə müqayisə edin.

Əgər token heç görünmürsə, problem OpenConnect-dən aşağıdadır: p11-kit-də həmin aralıq proqram üçün heç bir modul qeydiyyatdan keçməyib, ya da modul başqa hesab üçün qeydiyyatdadır. Sistem səviyyəsində qeydiyyat /etc/pkcs11/modules altındadır və istifadəçi üzrə kataloq sistem nüsxəsinə toxunmadan eyni şeyi saxlaya bilər. Modul faylındakı təminatçı yolunun oxuyucunun proqramının həqiqətən quraşdırdığı kitabxanaya işarə etdiyini yoxlayın.

URI-ni siyahıdan kopyalayarkən onun ətrafındakı dırnaqları saxlayın. Dırnaqsız nöqtəli vergüllər arqumenti ilk atributda kəsir və müştəri sonra tapa bilmədiyi obyekt barədə məlumat verir.

Avtomatik açar axtarışı əl çəkəndə

OpenConnect sertifikat URI-sindən açar axtarışı çıxara bilər, lakin apardığı dəqiq uyğunlaşdırma versiyadan asılıdır və obyekt növü ilə etiketin işlənməsi zamanla dəyişib. URI-ni işləyənə qədər qısaltmağı məsləhət görən mətn köhnə bir keçici həlli təsvir edir, tələb deyil. Əgər çıxarılan axtarış uğursuz olarsa, sertifikat URI-sini qeyri-müəyyən bir şeyə çevirmək yerinə açarı -k ilə açıq şəkildə adlandırın.

Müştərini günahlandırmazdan əvvəl açarın mövcud olduğunu və p11tool --list-keys ilə göründüyünü təsdiqləyin. Sonra obyektin imzalama və ya deşifrə üçün yararlı kimi işarələndiyini yoxlayın, çünki səhv atributlarla yaradılmış açar URI nə qədər düzgün olsa da əl sıxmanı tamamlaya bilməz. OpenVPN profilindəki seriyalaşdırılmış pkcs11-id dəyərini OpenConnect seçiminə köçürməyin; iki müştəri eyni karta müraciət etsə də fərqli identifikator formatları istifadə edir.

Əgər URI həll olunur, PIN qəbul edilir, amma autentifikasiya yenə də uğursuz olursa, URI-ni tənzimləməyi dayandırın. Şlüzün öz xətasını oxuyun, çünki növbəti uğursuzluq tokenin yuxarısındadır.

Yalnız URI problemlərinə bənzəyən uğursuzluqlar

Fərqli protokol danışan şlüz URI-niz düzgün olsa da səhv olsa da eyni cür uğursuz olacaq. OpenConnect köhnə vpnc müştərisini bir səbəbə görə əvəz etdi və kart dəstəyi uyğunsuz şlüz protokolunu uyğun etmir. Obyekt atributlarına daha bir saat sərf etməzdən əvvəl serverin gözlənilən protokolunu və autentifikasiya quruluşunu təsdiqləyin.

Server kimliyinin yoxlanması da ayrı bir qatdır. Müştəri şlüz sertifikatını öz etibar anbarına qarşı yoxlayır və bu yoxlama kart artıq öz hissəsini bitirdikdən sonra işləyir. Oxuyucu icazələri və dayanmış pcscd xidməti eyni xarici əlaməti — oxuna bilməyən token — yaradır, amma düzəlişi qat-qat sadədir.

Obyektdən bayıra doğru işləyin: p11tool tokeni görürmü, sertifikatı və açarı görürmü, OpenConnect URI-ni qəbul edirmi və yalnız bundan sonra şlüzün kimliyi qəbul edib-etmədiyini soruşun. Hər addımın öz xəta mesajı var və hər birini yoxlamaq sonrakından daha ucuzdur.