Зашто OpenVPN и даље тражи датотеку приватног кључа уз токен

Уметнете токен, провајдеров сопствени алат га види, а VPN клијент и даље тражи датотеку приватног кључа. Тај упит није доказ да токен није подржан. Обично значи да профил никада није рекао клијенту да користи токен, па се вратио на уносе сертификата и кључа које очекује по дифолту.

Две одвојене вредности морају бити исправне пре него што се тај повратак заустави: провајдер који излаже токен и идентитет сертификата унутар њега. Оне се задају различитим опцијама и лако их је заменити.

Клијент тражи датотеку јер профил тако налаже

Дифолт профил очекује датотеку сертификата и датотеку приватног кључа, или један PKCS#12 пакет. Кад ти уноси недостају, клијент нема шта да учита и понаша се скоро као код датотеке која недостаје, због чега се симптом чита као покварена путања, а не као механизам који недостаје. Путања PKCS#11 замењује те уносе уместо да их допуњује, па ће профил који и даље наводи датотеку кључа наставити да користи ту датотеку. Намерно уклоните датотечне уносе и пустите токену да обезбеди обе половине.

Опција провајдера именује библиотеку међуслоја, а не уређај и не сертификат. Да ли паковани клијент може да учита ту библиотеку зависи од тога како је изграђен, укључујући необавезну подршку за p11-kit коју неке градње укључују, а друге изостављају. Општи водич не може да вам каже какав распоред има ваш пакет.

Серијализовани идентитет је друга вредност

Идентитет сертификата је дугачак серијализовани низ који производи процес откривања и није путања библиотеке, PIN токена ни назив VPN налога. Често садржи знакове које треба ставити под наводнике, а вредност без наводника може бити скраћена или погрешно прочитана без јасне грешке. Употребите клијентову сопствену опцију откривање идентитета да излистате шта токен излаже, затим тачно копирајте жељени унос. Бирање првог објекта на листи је начин на који уређај на крају представи погрешан сертификат.

Резултат откривања одговара и на претходно питање: да ли је токен уопште видљив кроз тог провајдера. Ако ништа не излистава, проблем је изнад VPN клијента и припада међуслоју.

Процес који се повезује мора да дође до токена

Операција са токеном која успева у вашој радној сесији не доказује ништа о системској услузи. Услуга може да ради као други корисник, у другом монтажном именском простору, са путањом модула која изоставља библиотеку провајдера или без дозволе за отварање чвора уређаја. Утврдите који процес заправо држи везу и тестирајте из тог контекста.

Руковање PIN-ом заслужује засебну одлуку. Референтна имплементација нуди кеш PIN-а и заштићену путању провере аутентичности, а обоје постоји како би оператер могао да изабере ток рада уместо да га измисли. Не претварајте захтев без надзора у PIN у чистом тексту унутар заједничког профила, јер то мења заштиту токена за удобност. Тамо где токен забрањује извоз кључа, потписивање се дешава на уређају и PIN је једина локална тајна. Третирајте га с пажњом коју то подразумева.

Шта токен не замењује

Токен проверава аутентичност клијента у оквиру примењене политике и не замењује клијентове провере на серверу. Успешно изабран сертификат није дозвола за прихватање неочекиваног сертификата приступника, а те две провере штите супротне смерове.

Упис и даље мора да се догоди код издаваоца, а приступник и даље мора да овласти идентитет.

За прихватање раздвојите фазе: провајдер се учитава, тражени сертификат је пронађен, приватни кључ се користи с локалним овлашћењем, VPN проверава аутентичност и операција са ресурсом успева. Зауставите се на првој фази која не успе уместо да кружите кроз лозинке и поново инсталирате криптографски слој.

Бележите верзије, власништво модула, изабрани јавни идентификатор и очишћене грешке, а PIN-ове и пакете акредитива оставите изван тог записа.