Dzień dobry,
Przy próbie weryfikacji dokumentu w EZD RP pojawia się błąd Weryfikacja negatywna - nie znaleziono łańcucha zaufania. Prawdopodobnie problem jest przez to, że EZD obsługuje starszą wersję urzędu pośredniego i trzeba by było dodać nowy. Niestety nie wiemy w którym miejscu się to robi.
Wersja EZD RP: 1.26.103
Z góry dziękuję za wskazówki.
U mnie też w dniu dzisiejszym pojawił się ten sam problem. W zeszłym tygodniu podpisy działały prawidłowo.
Zwracam uwagę na potencjalny inny problem: TLv6 is coming: Upgrade now to avoid signature validation failures
Zmiana weszła 29 kwietnia.
EZD PUW wymagał aktualizacji modułu weryfikatora wydanego specjalnie z tego powodu.
Dzień dobry,
opisany problem może dotyczyć kwestii wprowadzenia TLv6, w związku z tym w publicznym repozytorium dostępna jest nowa wersja systemu EZD RP v26.106.11, dostosowana do wymagań DSS 6.1.1.
Rekomendowałbym aktualizację systemu EZD RP do najnowszej wersji.
Jeżeli jednak z jakichś powodów nie są Państwo gotowi na pełne podniesienie wersji, to jest możliwość skorzystania z rozwiązania przejściowege, które polega wyłącznie na podniesieniu wersji komponentu do weryfikacji podpisu czyli wpe-rest, bez konieczności podnoszenia całej wersji systemu. Instrukcja w zakresie przejściowego rozwiazania zamieszczam poniżej.
W przypadku dalszego użytkowania poprzednich wersji systemu lub nieaktualnego komponentu wpe-rest, usługa weryfikatora podpisów nie będzie działała prawidłowo.
Aktualizacja WPE-REST
- Przechodzimy w rancher na zakładkę Deployments:
- Wyszukujemy wpe-rest i następnie z prawej strony klikamy trzy kropeczki i wybieramy opcję „Edit Config"
- W polu Container Image, zmieniamy aktualną wersję i wpisujemy „26.106.2"
Bardzo dziękuję. W jaki sposób ponownie zweryfikować pisma, które są oznaczone czarną kropką?
Od kilku/kilkunastu wersji EZD RP można skorzystać wielokrotnie z opcji “Weryfikacja podpisu” dostępnego z prawego menu po zaznaczeniu danego dokumentu checkboxem. Zaakceptowanie wykonania operacji poskutkuję wymuszeniem ponownej weryfikacji podpisu przez EZD RP.
Niestety to nie działa. Po kliknięciu oznaczenie zmienia się na żółtą kropkę a po chwili znowu na czarną.
Być może problem nie jest związany z TLv6 i DSS 6.1.1.
Jeżeli weryfikacja jest negatywna również w oprogramowaniu dostawcy jakiegoś podpisu kwalifikowanego to problem nie jest po stronie EZD RP.
Może to problem z danym typem pliku: XLSX i podpis Xades dla plików XLSX z polskimi znakami w nazwie albo inna sytuacja.
Dodam, że problem z weryfikacją pisma dotyczy tylko pism sprzed aktualizacji wpe-rest. Po aktualizacji wpe-rest weryfikacja nowych pism działa prawidłowo. Co w takiej sytuacji najlepiej zrobić?
Tak jak pisałem wcześniej:
Być może problem nie jest związany z TLv6 i DSS 6.1.1.
Jeżeli weryfikacja jest negatywna również w oprogramowaniu dostawcy jakiegoś podpisu kwalifikowanego to problem nie jest po stronie EZD RP.
Mogą Państwo np. wgrać pismo do systemu od nowa by np. weryfikacjauruchomiła się od zera, a może problem leży w innym aspekcie i pierwszym krokiem weryfikacji jest weryfikacja podpisu na danym pliku poza EZD RP.
Problem może być zależny też np. od nazwy, rodzaju pliku i podpisu i wymagać szerszego opisu błędu.
Pełna racja. W takich wątpliwych przypadkach odpalam np. Sigillum Sign i weryfikuję tym narzędziem. Dodam, że Sigillum Sign też został zaktualizowany niedawno właśnie w związku z wdrożeniem wersji 6 List Zaufania. Tu dokładnie chodzi o to, że zarówno Sigillum Sign, jak i Weryfikator w EZD RP, czy też w EZD PUW wykorzystują Digital Signature Services. I DSS w tym wypadku wymagał podniesienia do wersji 6.1.1. Wcześniejsza wersja „nie rozumie” wersji 6 List Zaufania.
Przy okazji zwracam uwagę na groźny błąd w EZD RP (w EZD PUW też) związany z pokazywaniem statusów:
Weryfikator stosuje błędną logikę agregacji statusów podpisów na poziomie dokumentu. Zgodnie z ETSI EN 319 142-2 (dla PAdES) i powszechną praktyką walidatorów eIDAS, dokument otrzymuje status pozytywny wyłącznie, gdy każdy zawarty podpis uzyskał TOTAL-PASSED.
Obecna implementacja wyświetla wynik pozytywny mimo obecności podpisów ze statusem TOTAL-FAILED, co odpowiada błędnemu warunkowi OR zamiast AND.