Którego PKCS#11 URI potrzebuje OpenConnect dla tokenu?

Karta inteligentna, która już zawiera właściwy klucz, i tak musi dostać informację, którego obiektu na niej użyć. OpenConnect nie chce w tej sytuacji skopiowanego pliku .key; chce PKCS#11 URI nazywającego certyfikat i, gdy automatyczne wyszukiwanie nie może dokończyć pracy, klucz prywatny obok niego. Kłopot w tym, że poprawny składniowo URI niczego nie dowodzi. Musi nazwać rejestrację, której brama już ufa, a nie tylko obiekt, który karta zechce otworzyć.

Czego klient chce zamiast wyeksportowanego klucza

Opcja -c zwykle przyjmuje ścieżkę pliku, ale gdy wartość jest parsowana jako PKCS#11 URI, OpenConnect traktuje ją jako odwołanie do obiektu wewnątrz tokenu, a nie do pliku na dysku. Opcja -k zachowuje się tak samo w przypadku klucza prywatnego. Nic nie jest eksportowane i klucz nigdy nie opuszcza ochrony, którą daje karta. Klient potrzebuje od ciebie nazwy, co do której zgodne są moduł tokenu, magazyn certyfikatów i rejestracja w bramie.

Właśnie na tym ostatnim ograniczeniu zatrzymuje się większość prób. URI może być doskonale zbudowany i mimo to wybrać certyfikat, który brama odrzuci, bo ważność i trafność to osobne pytania. Sprawdzenie, które warto wykonać, to porównanie z rekordem rejestracji, a nie szukanie pierwszego obiektu, który przypadkiem się otworzy.

Dwa URI, dwa różne zadania

URI certyfikatu odpowiada na pytanie, jaką tożsamość zgłaszasz. Wskazuje obiekt certyfikatu, którego klucz publiczny i wiersz podmiotu pasują do profilu konta lub urządzenia wydanego przez administratora VPN. Ten sam certyfikat zwykle przychodzi z obiektem klucza prywatnego zapisanym obok, i to właśnie ta para jest potrzebna uzgadnianiu TLS.

URI klucza odpowiada na pytanie, gdzie mieszka odpowiedni materiał prywatny, gdy OpenConnect nie potrafi go wywnioskować. Przy ustawionym tylko -c klient buduje wyszukiwanie klucza z właściwości certyfikatu; podanie -k zastępuje domysł jawnym odwołaniem do obiektu. PIN tokenu to trzecie, niepowiązane wejście: odblokowuje kartę na czas operacji i nigdy nie identyfikuje obiektu.

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

Wszystko w tym ujętym w cudzysłów ciągu to dane. Średniki rozdzielają atrybuty URI, a sekwencje procentowe kodują znaki, które inaczej zepsułyby parsowanie, więc cały argument musi przetrwać powłokę nietknięty.

Znalezienie URI odpowiadającego twojej rejestracji

GnuTLS dostarcza p11tool, który wylicza, do czego bieżący użytkownik naprawdę dociera przez p11-kit. Zacznij od p11tool --list-tokens, a potem wylistuj obiekty certyfikatów na tokenie, który cię interesuje. Dodaj --login, gdy obiekty pojawiają się dopiero po PIN-ie, i porównaj podmiot oraz wystawcę z rekordem rejestracji, zamiast wybierać to, co pojawi się pierwsze.

Jeśli token w ogóle się nie pojawia, problem leży poniżej OpenConnect: p11-kit nie ma zarejestrowanego modułu dla tego pośrednika albo moduł jest zarejestrowany dla innego konta. Rejestracja systemowa znajduje się w /etc/pkcs11/modules, a katalog użytkownika może zawierać to samo bez ruszania kopii systemowej. Sprawdź, czy ścieżka dostawcy w pliku modułu wskazuje bibliotekę, którą oprogramowanie czytnika rzeczywiście zainstalowało.

Gdy kopiujesz URI z listy, zachowaj otaczające go cudzysłowy. Średniki bez cudzysłowów skracają argument przy pierwszym atrybucie, a klient zgłasza wtedy obiekt, którego nie może znaleźć.

Gdy automatyczne wyszukiwanie klucza się poddaje

OpenConnect potrafi wyprowadzić wyszukiwanie klucza z URI certyfikatu, ale dokładne dopasowanie, które wykonuje, zależy od wersji, a obsługa typu obiektu i etykiety zmieniała się z czasem. Rada, by skracać URI, aż zacznie działać, opisuje stare obejście, a nie wymóg. Jeśli wyprowadzone wyszukiwanie zawiedzie, nazwij klucz jawnie przez -k, zamiast przerabiać URI certyfikatu na coś bardziej mglistego.

Zanim obwinisz klienta, potwierdź, że klucz istnieje i jest widoczny przez p11tool --list-keys. Potem sprawdź, czy obiekt jest oznaczony jako użyteczny do podpisu lub odszyfrowania, bo klucz wygenerowany z błędnymi atrybutami nie ukończy uzgadniania, choćby URI był najpoprawniejszy. Nie przenoś zserializowanej wartości pkcs11-id z profilu OpenVPN do opcji OpenConnect; oba klienty używają różnych formatów identyfikatora, nawet gdy rozmawiają z tą samą kartą.

Jeśli URI się rozwiązuje i PIN jest akceptowany, ale uwierzytelnianie nadal zawodzi, przestań dostrajać URI. Przeczytaj błąd samej bramy, bo następna awaria jest powyżej tokenu.

Awarie, które tylko wyglądają jak problemy z URI

Brama mówiąca innym protokołem zawiedzie identycznie niezależnie od tego, czy twój URI jest poprawny, czy nie. OpenConnect zastąpił stary klient vpnc z jakiegoś powodu, a obsługa kart nie czyni niezgodnego protokołu bramy zgodnym. Potwierdź oczekiwany protokół serwera i układ uwierzytelniania, zanim spędzisz kolejną godzinę na atrybutach obiektu.

Weryfikacja tożsamości serwera to również osobna warstwa. Klient sprawdza certyfikat bramy względem swojego magazynu zaufania, a to sprawdzenie odbywa się po tym, jak karta zrobiła już swoje. Uprawnienia czytnika i zatrzymana usługa pcscd dają ten sam objaw zewnętrzny, nieczytelny token, przy znacznie prostszej naprawie.

Pracuj od obiektu na zewnątrz: czy p11tool widzi token, czy widzi certyfikat i klucz, czy OpenConnect akceptuje URI, i dopiero wtedy pytaj, czy brama akceptuje tożsamość. Każdy krok ma własny komunikat błędu i każdy jest tańszy w testowaniu od następnego.