OpenConnect برای یک توکن به کدام PKCS#11 URI نیاز دارد؟

کارت هوشمندی که از قبل کلید درست را دارد، باز هم باید به آن گفته شود کدام شیء روی آن را استفاده کند. OpenConnect در چنین حالتی فایل .key کپی‌شده نمی‌خواهد؛ یک PKCS#11 URI می‌خواهد که گواهی را نام ببرد و، وقتی جست‌وجوی خودکار نمی‌تواند کار را تمام کند، کلید خصوصی کنار آن را. بخش آزاردهنده این است که یک URI از نظر نحوی معتبر هیچ چیز را اثبات نمی‌کند. باید ثبت‌نامی را نام ببرد که دروازه از قبل به آن اعتماد دارد، نه صرفاً شیئی که کارت حاضر است باز کند.

کارخواه به‌جای کلید صادرشده چه می‌خواهد

گزینه -c معمولاً یک مسیر فایل می‌گیرد، اما وقتی مقدار به‌عنوان PKCS#11 URI تجزیه شود، OpenConnect آن را ارجاعی به شیئی درون توکن می‌داند، نه به فایلی روی دیسک. گزینه -k برای کلید خصوصی همین‌گونه رفتار می‌کند. چیزی صادر نمی‌شود و کلید هرگز از محافظتی که کارت فراهم می‌کند بیرون نمی‌رود. چیزی که کارخواه از شما می‌خواهد نامی است که ماژول توکن، انبار گواهی و ثبت‌نام دروازه بر آن توافق دارند.

همین آخرین محدودیت جایی است که بیشتر تلاش‌ها می‌مانند. یک URI می‌تواند کاملاً درست ساخته شده باشد و باز هم گواهی‌ای را انتخاب کند که دروازه رد می‌کند، چون اعتبار و مرتبط بودن دو پرسش جدا هستند. بررسی‌ای که ارزش انجام دادن دارد مقایسه با سابقه ثبت‌نام است، نه جست‌وجوی نخستین شیئی که تصادفاً باز می‌شود.

دو URI، دو کار متفاوت

URI گواهی پاسخ می‌دهد که کدام هویت را ادعا می‌کنید. به شیئی گواهی اشاره می‌کند که کلید عمومی و خط موضوع آن با نمایه حساب یا دستگاهی که مدیر VPN صادر کرده مطابقت دارد. همان گواهی معمولاً همراه با شیئی کلید خصوصی که کنارش ذخیره شده می‌آید، و همین جفت است که دست‌دادن TLS واقعاً به آن نیاز دارد.

URI کلید پاسخ می‌دهد که ماده خصوصی متناظر کجا زندگی می‌کند وقتی OpenConnect نمی‌تواند آن را استنباط کند. تنها با تنظیم -c، کارخواه جست‌وجوی کلید را از ویژگی‌های گواهی می‌سازد؛ ارائه -k حدس را با ارجاع صریح به شیء جایگزین می‌کند. PIN توکن سومین ورودی است و ارتباطی ندارد: کارت را برای عملیات باز می‌کند و هرگز شیئی را شناسایی نمی‌کند.

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

هر چیزی در آن رشته گیومه‌شده داده است. نقطه‌ویرگول‌ها ویژگی‌های URI را جدا می‌کنند و فرارهای درصدی نویسه‌هایی را کد می‌کنند که در غیر این صورت تجزیه را می‌شکند، پس کل آرگومان باید سالم از پوسته بیرون بیاید.

یافتن URI که با ثبت‌نام شما مطابقت دارد

GnuTLS ابزار p11tool را همراه دارد که فهرست می‌کند کاربر جاری واقعاً از طریق p11-kit به چه چیزی می‌رسد. با p11tool --list-tokens شروع کنید، سپس شیءهای گواهی روی توکنی را که برایتان مهم است فهرست کنید. وقتی شیءها فقط پس از PIN ظاهر می‌شوند --login را اضافه کنید، و موضوع و صادرکننده را با سابقه ثبت‌نام مقایسه کنید نه اینکه نخستین چیزی را که ظاهر می‌شود بردارید.

اگر توکن اصلاً ظاهر نشود، مشکل پایین‌تر از OpenConnect است: p11-kit هیچ ماژولی برای آن میان‌افزار ثبت نکرده، یا ماژول برای حساب دیگری ثبت شده است. ثبت در سطح سیستم زیر /etc/pkcs11/modules قرار دارد، و یک شاخه به‌ازای هر کاربر می‌تواند همان را بدون دست زدن به نسخه سیستم نگه دارد. بررسی کنید که مسیر ارائه‌دهنده در فایل ماژول به کتابخانه‌ای اشاره کند که نرم‌افزار خواننده واقعاً نصب کرده است.

وقتی URI را از فهرست کپی می‌کنید، گیومه‌های اطرافش را نگه دارید. نقطه‌ویرگول‌های بدون گیومه آرگومان را در نخستین ویژگی می‌برند و کارخواه سپس از شیئی خبر می‌دهد که نمی‌تواند پیدا کند.

وقتی جست‌وجوی خودکار کلید تسلیم می‌شود

OpenConnect می‌تواند از URI گواهی یک جست‌وجوی کلید استخراج کند، اما تطبیق دقیقی که انجام می‌دهد به نسخه بستگی دارد و برخورد با نوع شیء و برچسب در گذر زمان تغییر کرده است. توصیه‌ای که می‌گوید URI را کوتاه کنید تا کار کند، یک راه‌حل دور زدن قدیمی را توصیف می‌کند، نه یک الزام. اگر جست‌وجوی استخراج‌شده شکست بخورد، کلید را به‌صراحت با -k نام ببرید به‌جای اینکه URI گواهی را به چیزی مبهم‌تر تبدیل کنید.

پیش از سرزنش کارخواه تأیید کنید که کلید وجود دارد و با p11tool --list-keys دیده می‌شود. سپس بررسی کنید که شیء برای امضا یا رمزگشایی قابل استفاده علامت خورده باشد، چون کلیدی که با ویژگی‌های نادرست ساخته شده باشد نمی‌تواند دست‌دادن را کامل کند، هر قدر هم URI درست باشد. مقدار سریال‌شده pkcs11-id را از نمایه OpenVPN به گزینه OpenConnect منتقل نکنید؛ این دو کارخواه حتی وقتی با یک کارت سخن می‌گویند قالب‌های شناسه متفاوت دارند.

اگر URI حل شود و PIN پذیرفته شود اما احراز هویت باز هم شکست بخورد، تنظیم URI را متوقف کنید. خطای خود دروازه را بخوانید، چون شکست بعدی بالاتر از توکن است.

شکست‌هایی که فقط شبیه مشکلات URI هستند

دروازه‌ای که پروتکل دیگری سخن می‌گوید، چه URI شما درست باشد چه نادرست، یکسان شکست می‌خورد. OpenConnect کارخواه قدیمی vpnc را به دلیلی جایگزین کرد، و پشتیبانی از کارت پروتکل ناسازگار دروازه را سازگار نمی‌کند. پیش از صرف یک ساعت دیگر روی ویژگی‌های شیء، پروتکل مورد انتظار سرور و ترتیب احراز هویت را تأیید کنید.

اعتبارسنجی هویت سرور هم لایه‌ای جداگانه است. کارخواه گواهی دروازه را با انبار اعتماد خود بررسی می‌کند و این بررسی پس از آن اجرا می‌شود که کارت سهم خود را انجام داده است. مجوزهای خواننده و سرویس متوقف‌شده pcscd همان نشانه بیرونی را پدید می‌آورند، توکنی ناخواندنی، اما با اصلاحی بسیار ساده‌تر.

از شیء به بیرون کار کنید: آیا p11tool توکن را می‌بیند، آیا گواهی و کلید را می‌بیند، آیا OpenConnect URI را می‌پذیرد، و تنها آن‌گاه بپرسید آیا دروازه هویت را می‌پذیرد. هر گام پیام خطای خودش را دارد و آزمودن هر یک از گام بعدی ارزان‌تر است.