Odpowiedź: Takie funkcjonowanie obsługi czytnika kart elektronicznych wynika z architektury systemu terminalowego wbudowanego w MS Windows.
W ramach zdalnej sesji terminalowej użytkownik ma udostępnione te zasoby serwera, które przewiduje architektura usług terminalowych i zostały odpowiednio skonfigurowane przez administratora (nie obejmuje to portów USB Serwera!) oraz wybrane zasoby lokalne stacji roboczej, z której następuje zdalne połączenie do serwera terminalowego Windows (czyli tej stacji roboczej, na której pracuje aplikacja klienta terminalowego Remote Desktop Connection).

Wśród zasobów, które mogą być przenoszone ze zdalnej stacji roboczej do sesji terminalowej na serwerze Windows jest czytnik kart elektronicznych.

Jego przenoszenie ze stacji roboczej do serwera jest konfigurowalne przez użytkownika w opcjach dodatkowych klienta terminalowego (aplikacji Remote Desktop Connection).

Niestety czytnik kart elektronicznych podłączony do fizycznych portów serwera terminalowego nie jest udostępniany dla sesji terminalowych użytkowników zdalnych pracujących na tym serwerze.

Dlatego właśnie aplikacja użytkownika uruchomiona w sesji terminalowej „widzi” czytnik i kartę włożoną do tego czytnika tylko jeśli jest to czytnik lokalny podłączony do zdalnej stacji roboczej, na której uruchomiony jest Remote Desktop Connection i z której następuje połączenie do serwera Windows.

Aplikacja ta niestety nie może „widzieć” czytnika podłączonego bezpośrednio do portów USB serwera Windows.

I odwrotnie: aplikacje uruchamiane bezpośrednio na serwerze (ale nie w ramach sesji terminalowej) potrafią używać wyłącznie jego czytników lokalnych podłączonych do serwera i „nie widzą czytników” podłączonych do stacji roboczych użytkowników zdalnych.

Przenoszenie czytników w standardowy sposób w Windows Terminal Services (w ramach protokołu RDP) nie odbywa się na poziomie przenoszenia komunikacji z „urządzeniem USB”, ale jest to przenoszenie logicznej komunikacji z kartą elektroniczną na poziomie stosu bibliotek API obsługi czytników kart elektronicznych zgodnego z architekturą PC/SC.

Istnieją aplikacje firm trzecich rozszerzające standardową architekturę terminalową MS Windows i pozwalające na przenoszenie wybranych urządzeń podłączonych do portów USB pomiędzy dowolnymi komputerami (w tym również sesją terminalową na serwerze Windows i serwerem Windows), jednak użycie takich aplikacji może powodować kolizję z naturalnymi mechanizmami udostępniania np. czytnika kart ze stacji roboczej dla aplikacji pracującej w sesji terminalowej na serwerze i nie jest objęte standardowo wsparciem naszej firmy.

Odpowiedź: Aby czytnik i karta działały w połączeniu terminalowym (RDP) do serwera Windows muszą być spełnione następujące warunki:

• Czytnik musi zostać podłączony poprawnie do stacji klienckiej np. Windows 10/11. Na tej stacji muszą zostać zainstalowane sterowniki czytnika lub używany czytnik musi być zgodny ze standardem CCID, dla którego system Windows posiada natywnie generyczny sterownik czytnika kart inteligentnych. Czytnik musi być widoczny w managerze urządzeń i poprawnie działać na stacji roboczej (np. poprawnie informować o włożeniu/wyciągnięciu karty elektronicznej).
• Na stacji klienckiej musi działać usługa systemowa „Karta Inteligentna” (Smartcard).
• W aplikacji klienta RPD (Remote Desktop Connection), w opcjach zaawansowanych musi być włączone przenoszenie lokalnego czytnika kart elektronicznych w sesji RDP (tzn. udostępnianie kart w nim włożonych dla aplikacji na serwerze terminalowym Windows).
• Na serwerze Windows (dostępnym przez RDP) musi być zainstalowane oprogramowanie CryptoCard Suite dla kart CryptoCard Graphite (Plus/Pro) lub co najmniej stosowne biblioteki middleware (wchodzące w skład pakietu CryptoCard Suite, ale mogące funkcjonować bez pełnego pakietu).

Scenariusz funkcjonowania takiej konfiguracji wygląda następująco:

– aplikacja pracująca w sesji terminalowej na serwerze Windows (np. MS Outlook), (której wizualizację użytkownik widzi w okienku Klienta RDP na stacji roboczej), chcąc skorzystać z karty elektronicznej uruchamia na tym serwerze oprogramowanie middleware pochodzące od producenta karty (jeden z interfejsów API oprogramowania CryptoCard Suite w przypadku używania karty CryptoCard Graphite),
– wszelkie składniki oprogramowania CC Suite pracują na serwerze terminalowym Windows (nie jest wymagana jego instalacja na stacji roboczej Klienta RDP),
– CC Suite prosi system operacyjny serwera o listę dostępnych dla niego czytników kart,
– system udostępnia listę czytników PRZENOSZONYCH w sesji RDP ze stacji klienta RDP (czytników podłączonych do stacji klienta, na której uruchomiony jest w danej chwili RDP Klient, np. aplikacja Remote Desktop Connection),
– jeśli w czytniku na stacji Klienta włożona jest karta elektroniczna, to CC Suite (np. moduł CryptoTech miniDriver API albo CryptoTech PKCS#11 API) pracujący na serwerze zobaczy włożoną kartę do czytnika kart i może rozpocząć dialog z tą kartą,
– aplikacja (np. MS Outlook) przekazuje dla CC Suite serię poleceń (np. wykonania podpisu elektronicznego z użyciem karty CryptoCard), które są tłumaczone na stosowną sekwencję komend niskiego poziomu przekazywanych do czytnika kart dostępnego dla aplikacji pracujących w sesji terminalowej),
– komendy te są transparentnie przenoszone z serwera terminowego (z wnętrza sesji terminalowej danego użytkownika), przez kanał RDP, do aplikacji klienta RDP (np. Remote Desktop Connection) pracującej na stacji roboczej użytkownika,
– Klient RDP przekazuje te komendy do karty włożonej do czytnika podłączonego lokalnie do tej stacji roboczej,
– karta wykonuje zlecone zadania, np. generuje podpis elektroniczny „zlecony” jej przez aplikację (np. MS Outlook) pracującą na serwerze terminalowym Windows.

Odpowiedź: Niezależnie od rodzaju używanej karty i metody dostępu do funkcjonalności karty używanej przez aplikację użytkownika, w ramach konfiguracji komputera i systemu operacyjnego musi poprawnie działać czytnik kart i obsługujące go komponenty tego systemu operacyjnego (stos PC/SC oraz sterownik czytnika kart).

Uruchamiając aplikację CryptoCard Manager dla używanej karty (np. CryptoCard Graphite) należy sprawdzić czy aplikacja pokazuje czytnik kart, który jest fizycznie podłączony do komputera oraz pokazuje nazwę/model włożonej do niego karty. Karta odpowiednia od pracy z zainstalowanym oprogramowaniem będzie rozpoznana i wskazywana jako karta CryptoCard (np.) Graphite Plus.

Dodatkowo w dolnej części kontekstowej aplikacji CryptoCard Manager pojawią się podstawowe informacje o czytniku i karcie w nim włożonej (jeśli jest to karta z rodziny CryptoCard). Czytniki „mini” w formacie USB Pendrive posiadają kartę w formacie ID-000 (format „SIM”) na stałe włożoną do czytnika, czyli wkładając/wyciągając taki czytnik do portu USB będzie znikała/pojawiała się karta razem z czytnikiem w ramach zasobów systemu operacyjnego.

Brak ikony czytnika w tej aplikacji, informacja „Brak karty” lub „Nieznana karta” wskazują na określone wady konfiguracji systemu operacyjnego użytkownika lub niewłaściwą kartę włożoną do czytnika (np. kartę innego producenta lub kartę uszkodzoną).

Należy zwrócić uwagę, że rozwiązanie CryptoCard Suite wykorzystuje dostępne w systemie operacyjnym czytniki kart zgodne ze standardem PC/SC i jeśli czytnik nie jest poprawnie obsługiwany przez komponenty systemu operacyjnego, ma niewłaściwe sterowniki, jest uszkodzony itp. to aplikacja CryptoCard Manager nie będzie w stanie poprawnie współdziałać z takim czytnikiem i kartą CryptoCard do niego wsuniętą.

W systemach rodziny Windows, za obsługę czytnika w systemie operacyjnym odpowiedzialna jest głównie usługa systemu Windows (service) o nazwie „Karta Inteligentna” (Smart Card). Jeśli ta usługa jest zatrzymana lub zgłasza błędy, żadna aplikacja pracująca na tym systemie operacyjnym nie będzie w stanie komunikować się z kartą elektroniczną w czytniku i wykorzystywać jej funkcji (w tym oczywiście biblioteki i aplikacje z pakietu CryptoCard Suite oraz dowolne aplikacje użytkownika, które chciałby by wykorzystywać funkcje karty CryptoCard).

Ponieważ często okazuje się, że przyczyną problemów jest niepoprawnie skonfigurowany system operacyjny lub czytnik kart, użytkownik przed zgłoszeniem problemu powinien upewnić się, że posiada odpowiednio skonfigurowany system operacyjny oraz prawidłowo zainstalowany/skonfigurowany czytnik kart kryptograficznych.

Odpowiedź: Logowanie kartami jest możliwe jedynie wtedy, gdy komputer znajduje się w domenie Windows Active Directory i administrator poprawnie skonfigurował używanie kart do celu uwierzytelniania użytkowników w procesie logowania do komputera zarejestrowanego w ramach tej domeny.

Do takiego logowania konieczne jest m.in. wydanie na karcie certyfikatu umożliwiającego logowanie (stosując szablon Smart Card User lub Smart Card Logon) oraz odpowiednie skonfigurowanie Domeny Windows przez jej Administratora.

Odpowiedź: Z menu Tools -> Options -> Advanced wybrać sekcję Certificates. Nacisnąć przycisk „Manage Security Devices…”. W nowo otwartym okienku wpisać w polu „Module Name” – CryptoCard, w polu Module filename: wpisać odpowiednią ścieżkę do lokalizacji, gdzie zainstalowano oprogramowanie CryptoCard Suite w danym systemie operacyjnym.

Zależnie od tego czy używana jest aplikacja Mozilla Thunderbird w wersji 32bity czy 64bity, należy wskazać bibliotekę PKCS#11 DLL dla kart CryptoCard w odpowiedniej edycji (32 lub 64 bity).

W systemach 32bitowych instalowana jest tylko jedna wersja biblioteki PKCS#11 DLL (32bity) i znajduje się ona domyślnie w folderze „C:\Program Files\CryptoTech\CryptoCard\ CCGraphiteP11.dll”.

W systemach 64bitowych instalowane są dwie wersje biblioteki PKCS#11 DLL i zależnie od architektury aplikacji Thunderbird wskazać należy właściwą dla niej edycję tej biblioteki PKCS#11:

64bity: „C:\Program Files\CryptoTech\CryptoCard\ CCGraphiteP1164.dll”

32bity: “„C:\Program Files (x86)\CryptoTech\CryptoCard\CCGraphiteP11.dll”

Następnie po wybraniu przycisku OK w ramach opcji aplikacji Thunderbird, na liście dostępnych urządzeń powinno pojawić się dodatkowe urządzenie zgodne z PKCS#11 i lista raportowanych przez daną bibliotekę „slotów”, w których mogą znajdować się logiczne tokeny PKCS#11. Sloty zwykle odpowiadają fizycznym lub wirtualnym czytnikom kart zainstalowanym w systemie operacyjnym, ale czasami możliwa jest prezentacja tego samego czytnika wielokrotnie jeśli karta znajdująca się w tym czynniku zgłasza kilka logicznych tokenów PKCS#11.

Odpowiedź: Niestety, obecne systemy rodziny Windows , oprócz Windows VISTA SP1, nie umożliwiają przechowywania klucza i certyfikatu do EFS w jakimkolwiek innym miejscu oprócz „Magazynu osobistego”.

Odpowiedź: Karty CryptoCard Graphite posiadają min 64 kB pamięci zapisywalnej, z których ponad 25kB jest dostępne dla certyfikatów. W zależności od wielkości certyfikatu na takiej karcie powinno zmieścić się ok. 8 certyfikatów wraz z odpowiednimi kluczami.
Karty CryptoCard Graphite Plus/PRO posiadają min 72 kB pamięci zapisywalnej, z których ponad 32kB jest dostępne dla certyfikatów. W zależności od wielkości certyfikatu na takiej karcie powinno zmieścić się ok. 10 certyfikatów wraz z odpowiednimi kluczami.
Nie ma niestety żadnego ograniczenia na wielkość pojedynczego certyfikatu (zależy od jego profilu/szablonu/zawartości), dlatego też podane wyżej wartości nie są gwarantowane i powinny być traktowane jedynie orientacyjnie.

Odpowiedź: Wynika to z przeznaczenia certyfikatu kwalifikowanego, którego budowa jednoznacznie definiuje jego przeznaczenie (niezaprzeczalność) i równie jednoznacznie wyklucza jakiekolwiek inne użycie.

Odpowiedź: W ramach części kwalifikowanej karty (QSCD) istnieje konieczność stosowania aplikacji karty o bardzo ściśle kontrolowanych parametrach bezpieczeństwa, które są zdefiniowane w profilu zabezpieczeń danej platformy kartowej i opisane w dokumentacji certyfikacyjnej definiującej zgodność z tym profilem wg Common Criteria EAL4+.
Parametry te narzucają pewne ograniczenia na swobodę definiowania i zmiany kodów PIN/PUK dla tego obszaru karty.

Przykładowo dla kart CryptoCard Graphite (Plus/PRO) z aplikacją QSCD występują następujące ograniczenia (w zakresie polityki PIN):

• Karty te dostarczane są z poufnym kodem transportowym o wybranej przez wystawcę długości (od 6 do 8 znaków).
• Postępowanie z nową kartą jest opisane w procedurze aktywacji karty otrzymanej od jej wydawcy.
• W ramach takiej procedury następuje też konieczna zmiana wartości kodu QSCD PIN z wartości przekazanej bezpiecznie przez Wydawcę karty na wartość wybraną przez Użytkownika.
• Bez wykonania takiej zmiany, karta jest tylko częściowo funkcjonalna, gdyż nie jest możliwe wykonanie podpisu bezpiecznego (z użyciem klucza QSCD) weryfikowanego tzw. „kwalifikowanym certyfikatem”
• Po wykonaniu min. jednorazowej zmiany kodu QSCD PIN na wartość wybraną przez Użytkownika karty, można już generować podpisy, które wymagają każdorazowo podawania tego kodu QSCD PIN w aplikacji podpisującej.
• Długość kodu użytkownika QSCD PIN nie może być krótsza niż 6 znaków (od 6 do 16 znaków).
• QSCD PIN może zostać zablokowany po podaniu 3 razy błędnego kodu QSCD PIN.
• Do odblokowania takiego zablokowanego kodu QSCD PIN należy użyć kodu odblokowującego QSCD PUN, który ma długość od 8 do 16 znaków i jego wartość początkowa jest przekazana bezpiecznie przez Wydawcę karty, ale może też zostać (opcjonalnie) zmieniona przez Użytkownika.

Odpowiedź: Domyślnie ustawione wartości kodów PIN dla kart CryptoCard Graphite (Plus/PRO):

Primary PIN                      1111
Administrator PIN         222222

Szczegółowe informacja na temat kodów PIN/PUK/Admin PIN itd. zwarte są na końcu podręcznika użytkownika dostępnego z poziomu aplikacji CryptoCard Graphite Manager lub w postaci pliku PDF w katalogu aplikacyjnym CryptoCard.

Odpowiedź: W takim przypadku, przed instalacją CC CloudSigner należy przejściowo zaznaczyć (enable) poniższe ustawienie konfiguracji serwera Windows:

„Turn off Windows installer RDS compatibility” w ramach:

Local Group Policy Editor”; „Administrative Templates”; „Computer Configuration”

„Windows Components” folder.
„Remote Desktop Services” folder.
„Remote Desktop Session Host” folder.
„Application Compatibility” folder.

Po instalacji można przywrócić to ustawienie do wartości używanej na danym serwerze Windows.

Odpowiedź: Przed odesłaniem wadliwego sprzętu zakupionego w naszej firmie należy zapoznać się z procedurą reklamacyjną opisaną tutaj -> https://www.cryptotech.com.pl/zglaszanie-usterki-sprzetu/

Odpowiedź: W trakcie uruchomienia CCGM system operacyjny Windows raportuje IE7 które nie jest obsługiwane przez naszą aplikację i CCGM nie poprawnie się uruchamia. Niestety przyczyn występowania tego problemu może być wiele i różnych, w zależności od konfiguracji, zainstalowanych aplikacji na komputerze. Od ustawień przeglądarki, poprzez ustawienia stacji, GPO, oprogramowanie antywirusowe, korporacyjne, etc.

Problem pojawiający się głównie w środowiskach korporacyjnych, gdzie Windows posiada jakieś bardziej skomplikowane konfiguracje w zakresie polityk bezpieczeństwa i kompatybilności aplikacji pracujących w środowisku przeglądarkowym.

Głównie starszych aplikacji, które były pisane do działania w czasach Internet Explorer 7 lub starszych i które mają jakieś problemy w działaniu z nowszymi przeglądarkami, a zwłaszcza nowszym IE/EDGE, który jest częścią OS Windows. Wtedy administratorzy lub pakiety instalacyjne takich aplikacji modyfikują jakieś ustawienia systemowe by Windows raportował starszą wersję IE niż ma w rzeczywistości właśnie dla umożliwienia działania starych aplikacji korporacyjnych.

Czasami już firmy nie używają tych aplikacji, ale ustawienia domenowe lub systemowe pozostały zapomniane, choć nie są już w sumie używane.

Zdarzało się też, że program antywirusowy wprowadzał swoje zmiany w ustawieniach.

Generalnie chodzi o to, że gdzieś w ich systemach jest skonfigurowane (celowo albo przez historyczne niedopatrzenie) tzw. Enterprise Mode (https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-it-pro/internet-explorer-11/ie11-deploy-guide/what-is-enterprise-mode)

https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-it-pro/internet-explorer-11/ie11-deploy-guide/using-enterprise-mode

Ważne jest też, że takie konfiguracje (Enterprise Mode) mogą być kontrolowane centralnie, a nie tylko dla pojedynczej stacji w domenie.
Należy też pamiętać, że oddzielną sprawą jest włączenie tego trybu, a oddzielną (opcjonalne) konfigurowanie listy „sites”, które mają być obsługiwane w Enterprise Mode.

https://learn.microsoft.com/en-us/deployedge/edge-learnmore-configurable-sites-ie-mode

https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-it-pro/internet-explorer-11/ie11-deploy-guide/enterprise-mode-overview-for-ie11

Ponieważ taka konfiguracja może dotyczyć określonych zasobów, adresów, aplikacji itp. to w środowisku korporacyjnym można mieć (np.) skonfigurowane to tak, że adresy Intranetowe są obsługiwane przez IE11 (albo Edge w trybie IE11) ALE dodatkowo narzucona jest zgodność z Internet Explorer 7 („Compatibility Mode”).
CCGM używa systemowego browsera Windows (dawniej IE a obecnie Edge) i wymaga by zgłaszana wersja browsera (a co za tym idzie standard obsługi stron webowych) był min. IE 9 (bo w IE9 wprowadzono bardzo duże zmiany w zakresie standardów i technologii opisu storn webowych), ale zalecane jest używanie IE11, gdyż to ostatni standard wspierający DocumentMode.

Gdy zawołany systemowy browser (kontrolka programistyczna browsera Windows) raportuje, że jest w wersji IE7, to CCGM wypisuje komunikat, że z takim browserem systemowym nie może działać (zbyt stara wersja browsera).

Jednym z prostych (ale niekoniecznie dopuszczalnym w konkretnym środowisku korporacyjnym) obejść problemu, które pomogło części naszych Klientów, to ustawienie wyjątku w rejestrze dla naszej aplikacji:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
„CryptoCard Graphite Manager.exe”=dword:00002af8

* 00002af8 oznacza IE11

Warto przy okazji zaznaczyć, że sama aplikacja CryptoCard Graphite Manager (CCGM) nie jest niezbędna do działania karty w systemie operacyjnym i używania jej z różnymi aplikacjami Użytkownika.
CCGM służy wyłącznie do zarządzania kartą, jej kodami PIN, kluczami i certyfikatami i można te akcje wykonywać na dowolnym innym komputerze (nawet jako plik EXE z przenośnego nośnika pamięci).

Odpowiedź: Najprawdopodobniej jest to problem systemu operacyjnego, a nie instalatora naszego oprogramowania (chyba, że ten pierwotny pakiet instalacyjny MSI został usunięty z systemu).

Proszę zapoznać się z artykułem:

https://support.microsoft.com/pl-pl/windows/rozwiązywanie-problemów-uniemożliwiających-instalowanie-lub-usuwanie-programów-cca7d1b6-65a9-3d98-426b-e9f927e1eb4d

Odpowiedź: W środowiskach zarządzanych zdalnie czasami występuje potrzeba cichej instalacji pakietu na wielu zdalnych komputerach.
CryptoCard Graphite Suite dostępne jest również w posaci pakietu MSI używanego do instalacji przez Administratora, ale często przeszkodą w instalacji jest brak systemowego zaufania do certyfikatu producenta pakietu CryptoCard Graphite Suite.
Aby oprogramowanie to mogło zostać zdalnie zainstalowane, dany system operacyjny musi mieć zdefiniowane zaufanie dla certyfikatu używanego do podpisania komponentów oprogramowania wchodzących w skład pakietu, który te komponenty instaluje (pakietu MSI).
Certyfikat należy dodać do „TrustedPublisher” lokalnej maszyny poprzez GPO lub skrypt administracyjny.
Aktualny certyfikat należy wyeksportować z maszyny z zainstalowanym już oprogramowaniem z „TrustedPublisher” w certyfikatach.
W celu weryfikacji poprawności konfiguracji w kontekście zaufania do odpowiedniego certyfikatu można wykonać polecenia:

certutil.exe -addstore -f „TrustedPublisher” wyeksportowany_certyfikat.cer

Następnie uruchomić cichą instalację (tryb „silent”), która powinna zakończyć się pomyślnie.

Odpowiedź: W przypadku uszkodzenia konfiguracji (parametrów konfiguracyjnych przechowywanych lokalnie w kontekście danego użytkownika Windows), aplikacja CloudSigner czasami odmawia działania i nie pokazuje wirtualnej karty reprezentującej konto użytkownika w serwerze usług podpisywania zdalnego (np. mSZAFIR) lub nie pozwala dodać nowej karty wirtualnej.

W takim przypadku warto podjąć próbę przywrócenia konfiguracji CloudSigner do wartości domyślnych takich jak po świeżej instalacji aplikacji.
W tym celu należy:

– Zakończyć działanie aplikacji CloudSigner.
– Upewnić się (w „Menadżerze zadań”), że nie działa proces RepoServer.exe.
– W katalogu C:\Users\ZALOGOWANY_UŻYTKOWNIK\AppData\Local\CryptoTech\CloudSigner skasować folder „defaultRepo”.
(„AppData” jest ukrytym katalogiem i należy go ręcznie wpisać w „górnej” linii Windows Explorer lub włączyć pokazywanie ukrytych folderów w opcjach Windows Explorera).
– Uruchomić aplikację CloudSigner.
– Dodać nową kartę wirtualną tak jak po świeżej instalacji pakietu.

Odpowiedź: Jeśli występują nietypowe problemy z działaniem aplikacji CloudSigner to w ramach zgłoszenia do pomocy technicznej prosimy o przygotowanie i załączenie pliku z logiem diagnostycznym, gdyż przyspieszy to proces analizy problemy i zaproponowania jego rozwiązania.

Aby przygotować wymagany pliki z logiem wadliwego działania CloudSigner należy wykonać poniższe kroki:

– Zakończyć działanie aplikacji CloudSigner.
– Upewnić się (w „Menadżerze zadań”) że nie działa proces RepoServer.exe.
– W katalogu gdzie jest zainstalowana aplikacja CloudSigner (typowo jest to C:\Program Files\CryptoTech\CryptoCard\) otworzyć do edycji w jakimś edytorze tekstu plik RepoServer.ini (niezbędne uprawnienia Administratora tego systemu, gdyż to katalog aplikacji) i zmienić linijkę:

logging.loggers.root.level = notice
na
logging.loggers.root.level = debug

– Uruchomić CloudSignera i wykonać scenariusz działań skutkujący powstaniem zgłaszanego problemu lub błędu.
– Przesłać na adres pomoc.techniczna@cryptotech.com.pl jako załącznik powstały plik „repo.log” z C:\Users\ZALOGOWANY_UŻYTKOWNIK\AppData\Local\CryptoTech\CloudSigner\
– Ponownie zakończyć działanie aplikacji CloudSigner.
– Upewnić się (w „Menadżerze zadań”) że nie działa proces RepoServer.exe.
– Przywrócić wpis „notice” ponownie edytując plik RepoServer.ini.