Podpis Gov nie widzi certyfikatu? Jak to naprawić

Kiedy klikasz „podpisz" i aplikacja patrzy na ciebie pustym oknem bez żadnego certyfikatu - a termin złożenia dokumentu mija za godzinę - frustracja potrafi być niemal fizyczna. Problem z wykrywaniem certyfikatu kwalifikowanego w środowiskach do podpisu elektronicznego jest starszy niż większość użytkowników myśli i ma znacznie więcej warstw niż typowe „zaktualizuj i uruchom ponownie". Za niewidocznym certyfikatem kryje się zazwyczaj precyzyjny łańcuch zależności - między wersją środowiska uruchomieniowego, sterownikami kryptograficznymi, interfejsem komunikacyjnym a samą aplikacją - i wystarczy pęknięcie w jednym ogniwie, żeby cały mechanizm odmówił posłuszeństwa w najmniej odpowiednim momencie.

• Przyczyny braku certyfikatu w Podpis Gov
• Aktualizacja Javy dla certyfikatów
• Sterowniki middleware do Podpis Gov
• Odświeżanie listy certyfikatów
• Sprawdzanie USB i PKCS#11 w Podpis Gov
• Pytania i odpowiedzi - Podpis Gov nie widzi certyfikatu

Przyczyny braku certyfikatu w Podpis Gov

Aplikacja do podpisu elektronicznego nie widzi certyfikatu z jednego prostego powodu: gdzieś na ścieżce między sprzętem a oprogramowaniem dochodzi do zerwania komunikacji. Token USB lub karta kryptograficzna same w sobie działają poprawnie - przechowują klucz prywatny i certyfikat kwalifikowany w bezpiecznej pamięci układu. Problem polega na tym, że aplikacja nie potrafi do tej pamięci dotrzeć bez odpowiednio skonfigurowanego pośrednika, czyli warstwy oprogramowania, która tłumaczy sygnały między urządzeniem a logiką aplikacji.

Najczęstszą przyczyną, którą można potwierdzić w zdecydowanej większości zgłoszeń do pomocy technicznej, jest brak lub nieprawidłowa wersja środowiska Java. Podpis Gov i podobne aplikacje opierają się na rozbudowanym środowisku uruchomieniowym napisanym w Javie, a konkretne wersje tej platformy obsługują różne zestawy bibliotek kryptograficznych. Jeżeli zainstalowana Java pochodzi sprzed kilku lat, może po prostu nie rozumieć formatu, w jakim nowoczesny token prezentuje swoje dane - tak jak starsza przeglądarka nie wyświetli poprawnie strony napisanej w nowszych standardach CSS. Mechanizm jest banalny, konsekwencja jednak poważna: aplikacja nie dostaje żadnego komunikatu o błędzie, po prostu nie widzi urządzenia.

Drugi filar problemów to sterowniki middleware, czyli oprogramowanie pośredniczące instalowane przez dostawcę certyfikatu. Każdy wystawca certyfikatów kwalifikowanych dostarcza własny pakiet oprogramowania zawierający pliki .dll (w systemach Windows) lub .dylib (w macOS), które implementują standardowy protokół komunikacyjny PKCS#11 lub interfejs MSCAPI. Bez tych plików aplikacja dosłownie nie ma jak zapytać tokena o listę dostępnych certyfikatów - brakuje jej słownika, którym mogłaby się porozumieć z kryptograficznym hardware'em. Co istotne, sam fakt, że token świeci się po podpięciu do portu USB, absolutnie nic nie mówi o tym, czy sterowniki są poprawnie zainstalowane.

Trzecia grupa przyczyn jest mniej oczywista, bo dotyczy nie samych komponentów, lecz stanu aplikacji między sesjami. Folder konfiguracyjny przechowuje w pamięci podręcznej listę wykrytych certyfikatów z poprzednich uruchomień - jeśli token był podpięty podczas instalacji i od tamtej pory zmienił się numer seryjny certyfikatu po odnowieniu, aplikacja może wciąż próbować wczytać nieaktualne dane i zwracać pusty wynik zamiast świeżej listy. To subtelna, ale dość powszechna pułapka przy odnowieniach certyfikatów kwalifikowanych, gdzie użytkownicy spodziewają się automatycznej aktualizacji, a ta nigdy nie następuje bez ingerencji.

Rzadziej, lecz nie wyjątkowo, problem leży po stronie samego portu USB lub koncentratora. Układy kryptograficzne w tokenach pobierają stosunkowo mało prądu, jednak są wrażliwe na niestabilność napięcia i zakłócenia elektromagnetyczne typowe dla tanich hubów USB bez zasilania. Port zasilany bezpośrednio z płyty głównej zapewnia stabilne 500 mA zgodnie ze specyfikacją USB 2.0 - koncentratory pasywne często dzielą ten budżet między kilka urządzeń, co w praktyce oznacza, że token działa kapryśnie lub jest wykrywany tylko przez chwilę po podpięciu, zanim zniknie z listy urządzeń systemowych.

Aktualizacja Javy dla certyfikatów

Aktualizacja środowiska Java to krok, który działa nie dlatego, że „nowe jest lepsze", ale dlatego że kolejne wydania platformy aktualizują wewnętrzny rejestr obsługiwanych algorytmów kryptograficznych i formatów certyfikatów. Certyfikaty kwalifikowane wydawane według aktualnych standardów europejskich (eIDAS) używają krzywych eliptycznych oraz funkcji skrótu SHA-256 i SHA-384. Starsze wersje środowiska Java, szczególnie te sprzed wydania 11, mogą traktować część tych algorytmów jako niezaufane lub wręcz nieobsługiwane - aplikacja widzi token, ale nie potrafi zinterpretować struktury danych certyfikatu.

Przed aktualizacją warto sprawdzić, która wersja Javy jest aktualnie używana przez aplikację Podpis Gov. Sam system operacyjny może mieć zainstalowanych kilka równoległych wersji środowiska, a aplikacja niekoniecznie korzysta z tej najnowszej - wybiera tę wskazaną w zmiennych środowiskowych lub w swoim własnym pliku konfiguracyjnym. Komenda java -version w wierszu poleceń pokazuje wersję domyślną dla systemu, ale nie zawsze tę, z której korzysta konkretna aplikacja. Warto zweryfikować, czy w katalogu instalacyjnym Podpis Gov nie ma własnego podfolderu z dedykowanym środowiskiem uruchomieniowym.

Przy aktualizacji Javy należy mieć świadomość jednej technicznej pułapki: instalacja nowej wersji nie usuwa automatycznie poprzedniej. Przez pewien czas system ma zarejestrowane dwie lub trzy wersje jednocześnie, a aplikacja może nadal wskazywać na starą. Mechanizm jest prosty - wpis w rejestrze Windows lub w zmiennej PATH wskazuje na konkretną ścieżkę instalacji, a nowa wersja ląduje w innym katalogu. Po instalacji warto ręcznie zweryfikować, czy ścieżka w zmiennej JAVA_HOME faktycznie prowadzi do najnowszego wydania, bo to ten wpis decyduje o tym, który interpreter obsłuży aplikację.

Usunięcie folderu konfiguracyjnego aplikacji po aktualizacji Javy jest krokiem, który większość poradników pomija, a który rozwiązuje sporą część przypadków nieudanej aktualizacji. Folder ten, zazwyczaj ukryty w katalogu profilu użytkownika, zawiera skompilowane cache bibliotek kryptograficznych z poprzedniej wersji środowiska. Nowa Java ładuje się prawidłowo, lecz aplikacja wciąż próbuje użyć starych, niekompatybilnych plików tymczasowych - skutek jest paradoksalny: po aktualizacji działa gorzej niż przed. Usunięcie folderu zmusza aplikację do zbudowania konfiguracji od nowa przy następnym uruchomieniu.

Na systemach macOS obraz sytuacji jest nieco inny: Apple od wersji systemu Catalina usunął własne środowisko Java z dystrybucji systemowej, co oznacza, że użytkownicy komputerów Apple muszą samodzielnie zainstalować środowisko uruchomieniowe przed pierwszym użyciem aplikacji do podpisu. Brak tej instalacji objawia się komunikatem o braku obsługiwanego środowiska lub - co gorsza - cichym niepowodzeniem uruchomienia bez jakiegokolwiek opisu błędu.

Sterowniki middleware do Podpis Gov

Middleware kryptograficzny to warstwa oprogramowania, która nie wykonuje samego podpisu, lecz tworzy znormalizowany kanał komunikacji między aplikacją a urządzeniem kryptograficznym. Bez niej aplikacja musiałaby mieć wbudowaną obsługę każdego modelu tokena z osobna - co jest technicznie niemożliwe przy kilkudziesięciu urządzeniach dostępnych na rynku. Standard PKCS#11, znany też pod nazwą Cryptoki, definiuje dokładny interfejs funkcji, które każde oprogramowanie middleware musi implementować: inicjalizacja sesji, lista slotów, lista obiektów w slocie, operacja podpisu. Aplikacja wywołuje te funkcje przez wskazany plik .dll lub .dylib, nie wiedząc nic o fizycznym protokole komunikacji z konkretnym tokenem.

Ścieżki do plików sterowników różnią się w zależności od dostawcy certyfikatu i zainstalowanego oprogramowania towarzyszącego. W systemach Windows szukanie zazwyczaj zaczyna się w katalogach C:\Program Files lub C:\Program Files (x86) - warto przeszukać folder instalacyjny oprogramowania dostawcy pod kątem plików z rozszerzeniem .dll zawierających w nazwie człony takie jak „pkcs11", „cryptoki" lub nazwę producenta tokena. Różni wystawcy certyfikatów kwalifikowanych mogą używać różnych nazw tych plików, co jest jednym z częstszych źródeł zamieszania - użytkownik szuka „pkcs11.dll" i nie znajduje, bo plik nazywa się inaczej, lecz pełni tę samą rolę.

Na macOS biblioteki middleware instalują się zwykle w katalogach /usr/local/lib/ lub w dedykowanym folderze w katalogu Applications. Pliki .dylib działają identycznie jak windowsowe .dll - implementują ten sam standard PKCS#11, tyle że w formacie binarnym właściwym dla architektury Apple. Istotna różnica polega na tym, że macOS od wersji Big Sur stosuje restrykcje Gatekeeper również do bibliotek ładowanych dynamicznie: plik .dylib bez odpowiedniej sygnatury kryptograficznej od Apple'a może zostać zablokowany przed załadowaniem bez żadnego komunikatu dla użytkownika, co objawia się dokładnie tak samo jak brak sterownika - pustą listą certyfikatów.

Wskazanie pliku sterownika w aplikacji Podpis Gov odbywa się przez ustawienia interfejsu PKCS#11. Użytkownik otwiera sekcję konfiguracji, wybiera typ interfejsu (PKCS#11 zamiast domyślnego MSCAPI), a następnie wskazuje ścieżkę do pliku biblioteki. Mechanizm jest następujący: po wskazaniu ścieżki aplikacja ładuje bibliotekę do pamięci i wywołuje funkcję inicjalizacyjną C_Initialize - jeśli ta zwróci kod CKR_OK, komunikacja jest nawiązana i aplikacja od razu prosi o listę dostępnych slotów, w których mogą znajdować się certyfikaty. Jeśli cokolwiek jest nie tak z plikiem lub ścieżką, inicjalizacja kończy się błędem, który użytkownik widzi najczęściej jako pustą listę lub enigmatyczny komunikat „nie znaleziono certyfikatów".

Ważna kwestia, której nie wolno zbagatelizować: oprogramowanie middleware dostarczone przez dostawcę certyfikatu jest zazwyczaj dopasowane do konkretnego modelu fizycznego tokena lub karty. Użycie biblioteki od innego producenta lub innego modelu urządzenia nie spowoduje uszkodzenia danych, ale prawie na pewno skończy się błędem inicjalizacji - protokoły niskopoziomowe komunikacji z układem kryptograficznym różnią się między producentami, nawet jeśli warstwowy interfejs PKCS#11 jest ustandaryzowany.

Odświeżanie listy certyfikatów

Lista certyfikatów widoczna w aplikacji nie jest aktualizowana na żywo - to migawka zrobiona w momencie uruchomienia lub ostatniego odświeżenia. Aplikacja wczytuje dostępne certyfikaty raz, przy starcie, i zapamiętuje wynik w pamięci podręcznej na czas całej sesji. Jeżeli token został podpięty po uruchomieniu aplikacji albo jeśli w międzyczasie upłynął czas ważności poprzedniego certyfikatu i wystawca zarejestrował nowy, lista pozostanie nieaktualna aż do ręcznego wymuszenia odczytu. Przycisk „Odśwież" lub analogiczne polecenie w menu aplikacji wywołuje ponowną inicjalizację PKCS#11 i przejście przez całą sekwencję wykrywania - tym razem ze świeżym odczytem z tokena.

Usunięcie folderu konfiguracyjnego idzie krok dalej niż zwykłe odświeżenie listy. Folder ten, w zależności od systemu, ukrywa się zazwyczaj w katalogu %APPDATA%\Podpis Gov na Windows lub w ~/Library/Application Support/ na macOS. Zawiera pliki XML lub JSON z zapamiętanymi konfiguracjami slotów, ścieżkami do bibliotek i listą seryjnych numerów certyfikatów widocznych podczas poprzednich sesji. Usunięcie całego folderu zmusza aplikację do pełnej reinicjalizacji przy następnym uruchomieniu - proces trwa kilka sekund dłużej, lecz gwarantuje, że żaden stary wpis z cache nie zasłoni aktualnego stanu tokena.

Sytuacja, w której certyfikat pojawiał się wcześniej i nagle przestał być widoczny po odnowieniu, jest klasycznym przypadkiem konfliktu między zapamiętanym stanem a rzeczywistością. Certyfikat kwalifikowany po odnowieniu ma nowy numer seryjny, nową datę ważności i techniczne rzecz biorąc jest zupełnie innym obiektem kryptograficznym niż poprzedni. Aplikacja może pamiętać stary numer seryjny i przy próbie wczytania certyfikatu szukać dokładnie tego identyfikatora - nie znajdując go, zwraca pusty wynik, choć nowy certyfikat siedzi na tokenie i czeka. Czyszczenie cache łamie to błędne koło.

Kolejność działań ma znaczenie: token powinien być podpięty do portu USB zanim aplikacja zostanie uruchomiona. Jeśli kolejność jest odwrotna, część implementacji PKCS#11 nie wykonuje pełnej reinicjalizacji przy wykryciu nowego urządzenia - obserwuje zdarzenia systemowe, lecz nie zawsze na nie reaguje, szczególnie gdy aplikacja jest w stanie oczekiwania. Podpięcie tokena przed startem aplikacji eliminuje tę kategorię problemów, bo inicjalizacja biblioteki kryptograficznej odbywa się już w obecności urządzenia.

Szczególnym przypadkiem jest środowisko wielosesyjne, typowe dla komputerów służbowych z domeną Windows. Jeżeli inny użytkownik systemu miał wcześniej otwartą sesję z tym samym tokenem, może istnieć aktywna blokada na slot PKCS#11 - token obsługuje jednocześnie co najwyżej kilka równoległych sesji kryptograficznych, a przekroczenie tego limitu objawia się zwróceniem kodu błędu CKR_SESSION_COUNT, który aplikacja może przetłumaczyć na użytkownikowi nieczytelne „brak certyfikatu". Odświeżenie listy po zamknięciu innych sesji lub po ponownym zalogowaniu do systemu rozwiązuje ten problem bez potrzeby dotykania konfiguracji sterowników.

Sprawdzanie USB i PKCS#11 w Podpis Gov

Zanim przystąpisz do głębszej diagnostyki konfiguracji PKCS#11, warto zacząć od weryfikacji po stronie systemu operacyjnego - menedżer urządzeń powinien pokazywać token jako rozpoznane urządzenie bez żółtego wykrzyknika. Jeśli urządzenie widnieje jako „nieznany sprzęt" lub w ogóle nie pojawia się na liście, problem leży głębiej niż brakujący plik .dll - brak sterownika systemowego (nie middleware, lecz sterownika niskopoziomowego dla klasy urządzeń USB Smart Card lub CCID) uniemożliwia w ogóle komunikację z tokenem. Sterowniki klasy CCID są wbudowane w Windows 10 i nowsze, ale mogą wymagać ręcznego włączenia usługi Smart Card w konfiguracji systemu.

Usługa Smart Card w systemie Windows działa jako daemon zarządzający dostępem do kart kryptograficznych i tokenów zgodnych ze standardem PC/SC. Jeśli ta usługa jest wyłączona lub zatrzymana - co zdarza się w środowiskach korporacyjnych z zaostrzonym Group Policy - aplikacja nie może nawiązać komunikacji z tokenem nawet przez PKCS#11, bo warstwa PC/SC jest niezbędnym pośrednikiem między sterownikiem USB a biblioteką kryptograficzną. Sprawdzenie stanu usługi odbywa się przez services.msc: usługa „Karta inteligentna" powinna być ustawiona na tryb automatyczny lub na żądanie, nie na wyłączony.

Konfiguracja interfejsu PKCS#11 w ustawieniach aplikacji wymaga precyzji przy wskazywaniu ścieżki. Najczęstszy błąd polega na wskazaniu folderu zamiast konkretnego pliku biblioteki albo na podaniu ścieżki zawierającej znaki specjalne (spacje, polskie litery w nazwie katalogu), które część implementacji PKCS#11 interpretuje błędnie. Przeniesienie pliku .dll do prostej ścieżki bez spacji, na przykład C:\pkcs11\, i zaktualizowanie wskazania w aplikacji eliminuje tę kategorię błędów. Mechanizm jest tu banalny: loader bibliotek dynamicznych w Windows wywołuje funkcję LoadLibraryEx, która obsługuje spacje w ścieżce, ale starsze implementacje PKCS#11 mogą korzystać z uproszczonego parsowania ścieżki, które spację traktuje jako koniec ciągu znaków.

Testowanie wskazanego pliku sterownika bez wychodzenia z aplikacji to funkcja, którą warto znać: po wskazaniu ścieżki do .dll i kliknięciu zatwierdzenia aplikacja powinna w ciągu kilku sekund pokazać listę dostępnych slotów - nawet pustych. Pojawienie się choćby jednego slotu, nawet bez certyfikatu, oznacza, że biblioteka PKCS#11 załadowała się prawidłowo i komunikacja z tokenem jest nawiązana. Brak jakichkolwiek slotów przy prawidłowym wskazaniu pliku sugeruje, że token nie jest podpięty lub że jest podpięty przez pasywny koncentrator, który nie zapewnia wystarczającego zasilania.

Zmiana portu USB to jeden z tych kroków, które brzmią trywialnie, lecz rozwiązują zaskakująco dużo przypadków. Porty USB na przednim panelu obudowy komputera stacjonarnego są z reguły podłączone przez wewnętrzny koncentrator na płycie głównej i mogą mieć ograniczone możliwości zasilania w porównaniu z portami z tyłu obudowy, podłączonymi bezpośrednio do kontrolera. Token kryptograficzny podczas operacji podpisu inicjuje intensywną komunikację i może przez chwilę pobierać prąd bliski granicy specyfikacji - niestabilny port to niestabilna sesja, co objawia się urywaniem połączenia dokładnie w połowie procesu inicjalizacji PKCS#11, przed załadowaniem certyfikatów.

Jeżeli wszystkie opisane kroki zostały wykonane i aplikacja nadal nie widzi certyfikatu, warto sięgnąć do dziennika zdarzeń systemowych Windows (Podgląd zdarzeń → Dzienniki Windows → Aplikacja) lub do logów aplikacji, jeśli ma ona opcję ich generowania. Kody błędów PKCS#11 są znormalizowane - CKR_DEVICE_REMOVED oznacza odłączenie tokena podczas sesji, CKR_PIN_LOCKED blokadę po zbyt wielu nieudanych próbach weryfikacji PIN, a CKR_TOKEN_NOT_PRESENT brak tokena w slocie. Każdy z tych kodów prowadzi do innego rozwiązania i pozwala skończyć z próbowaniem wszystkiego naraz.

Pytania i odpowiedzi - Podpis Gov nie widzi certyfikatu