איזה URI מסוג PKCS#11 צריך OpenConnect עבור טוקן?
OpenConnect רוצה URI מסוג PKCS#11 שממנה את תעודת הטוקן והמפתח שלו, ולא PEM מיוצא. אתרו את האובייקט שמתאים לרישום וצטטו אותו.
כרטיס חכם שכבר מחזיק במפתח הנכון עדיין צריך שיגידו לו איזה אובייקט עליו להשתמש. OpenConnect לא רוצה קובץ .key מועתק במצב כזה; הוא רוצה URI מסוג PKCS#11 שממנה את התעודה וכאשר החיפוש האוטומטי אינו יכול להשלים את העבודה, גם את המפתח הפרטי שלידו. החלק המסורבל הוא ש-URI תקין תחבירית אינו מוכיח דבר. עליו למנות את הרישום שהשער כבר סומך עליו, ולא רק אובייקט שהכרטיס מוכן לפתוח.
מה הלקוח רוצה במקום מפתח מיוצא
האפשרות -c מקבלת בדרך כלל נתיב קובץ, אך כאשר הערך מפוענח כ-URI מסוג PKCS#11, 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, ואז פרטו את אובייקטי התעודה על הטוקן שמעניין אתכם. הוסיפו --login כאשר האובייקטים מופיעים רק אחרי PIN, והשוו את הנושא והמנפיק לרשומת הרישום במקום לבחור את מה שמופיע ראשון.
אם הטוקן בכלל לא מופיע, הבעיה נמצאת מתחת ל-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, ורק אז שאלו אם השער מקבל את הזהות. לכל שלב יש הודעת שגיאה משלו, וכל אחד זול יותר לבדיקה מקודמו.