# Brak możliwości złożenia podpisu e-dowodem XADES w demo EZD RP **URL:** \ **Category:** Użytkowanie i praca w systemie\ **Created:** [12 Grudzień 2025 10:02 UTC](https://forum.ezdrp.gov.pl/t/brak-mozliwosci-zlozenia-podpisu-e-dowodem-xades-w-demo-ezd-rp/3628 "2025-12-12T10:02:42Z")\ **Posts on this page:** 4\ **Page:** 1
**Autor:** ![MarcinF](https://avatars.discourse-cdn.com/v4/letter/m/e47c2d/32.png) [@MarcinF](https://forum.ezdrp.gov.pl/u/MarcinF)\ **Data wpisu:** [12 Grudzień 2025 10:02 UTC](https://forum.ezdrp.gov.pl/t/brak-mozliwosci-zlozenia-podpisu-e-dowodem-xades-w-demo-ezd-rp/3628/1 "2025-12-12T10:02:42Z")
Przy próbie podpisania dokumentu certyfikatem z e-dowodu w formacie XAdES pojawia się błąd i komunikat “rsa key data expected”. Po wybraniu PAdES podpis certyfikatem z e-dowodu przebiega prawidłowo. Analogicznie wygląda sytuacja z podpisem certyfikatami EC (podobnie jak na e-dowodzie, szyfrowane krzywymi eliptycznymi) na kartach. Starszego typu certyfikaty RSA działają poprawnie zarówno dla PAdES jak i dla XAdES. Wygląda na to że w aplikacji NaskDESK do obsługi PAdES zaimplementowano zarówno RSA jak i EC a dla XAdES tylko RSA. ---
**Autor:** ![quiris](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.ezdrp.gov.pl/quiris/32/498_2.png) [@quiris](https://forum.ezdrp.gov.pl/u/quiris)\ **Data wpisu:** [12 Grudzień 2025 10:12 UTC](https://forum.ezdrp.gov.pl/t/brak-mozliwosci-zlozenia-podpisu-e-dowodem-xades-w-demo-ezd-rp/3628/2 "2025-12-12T10:12:33Z")
Zgadza się. To samo jest w przypadku EZD PUW. Informacja z linii wsparcia PWPW dla e-dowodu osobistego w sprawie „rsa key data expected”: > Dzień dobry, > Komunikat nie pochodzi z naszej biblioteki i sugeruje, że wymagany jest certyfikat RSA, a certyfikaty na e-dowodzie są certyfikatami EC. > > Podsumowując zgłoszenie : > > - nie jest to wina biblioteki PKCS#11, > - biblioteka zachowuje się prawidłowo, > - rodzaj pliku oraz podpisu nie ma wpływu na działanie biblioteki, > - na edowodzie certyfikaty rządowe są wydane na krzywych eliptycznych, certyfikaty kwalifikowane na edowodzie oraz na kartach CUZ standardowo wydawane są na kluczach RSA, > - oprogramowanie NASK dla formatu PAdES potrafi obsłużyć klucze na krzywych eliptycznych oraz RSA dlatego podpis wykonuje się prawidłowo w obu przypadkach, > - oprogramowanie NASK dla formatu XAdES nie potrafi obsłużyć kluczy na krzywych eliptycznych i oczekuje kluczy RSA, dlatego podpis certyfikatem rządowym się nie udaje, a podpis certyfikatem kwalifikowanym się udaje. > > **Z naszej strony zalecalibyśmy kontakt z NASK i poproszenie o dodania wsparcia w ich oprogramowaniu dla kluczy na krzywych eliptycznych dla formatu XAdES analogicznie jak robią to dla formatu PAdES.** > > Pozdrawiamy, Zespół eDO ---
**Autor:** ![quiris](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.ezdrp.gov.pl/quiris/32/498_2.png) [@quiris](https://forum.ezdrp.gov.pl/u/quiris)\ **Data wpisu:** [12 Grudzień 2025 10:22 UTC](https://forum.ezdrp.gov.pl/t/brak-mozliwosci-zlozenia-podpisu-e-dowodem-xades-w-demo-ezd-rp/3628/3 "2025-12-12T10:22:23Z")
Ze swojej strony zgłosiłem ten problem i potrzebę naprawy do CRM EZD PUW. Jeśli macie dostęp do wsparcia NASK-u dla EZD RP to zgłoście analogiczną potrzebę naprawy. Bo to naprawdę nie jest jakieś _rocket science_ dodanie obsług certyfikatów EC. Sam wczoraj przy wsparciu AI napisałem aplikację w Pythonie, która mi podpisuje PAdES, XAdES za pomocą certyfikatów EC (e-dowód osobisty) i RSA (Sigillum karta BLUE) przy wsparciu DSS Demonstration WebApp (tworzy poprawną strukturę wyjściową podpisanych danych). ---
**Autor:** ![quiris](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.ezdrp.gov.pl/quiris/32/498_2.png) [@quiris](https://forum.ezdrp.gov.pl/u/quiris)\ **Data wpisu:** [19 Grudzień 2025 20:04 UTC](https://forum.ezdrp.gov.pl/t/brak-mozliwosci-zlozenia-podpisu-e-dowodem-xades-w-demo-ezd-rp/3628/4 "2025-12-19T20:04:05Z")
Otrzymałem zaiste _ekscytującą_ odpowiedź na moje zgłoszenie o potrzebie dodania obsługi EC w EZD PUW: > „Addin wymaga certyfikatów RSA. W tym momencie prace które miały by na celu rozszerzenie możliwość podpisywania o certyfikaty EC nie są prowadzone. > Możliwe, że będzie to jeszcze zaplanowane. > W tym momencie proszę korzystać z certyfikatów kwalifikowanych. > Zamykam zgłoszenie.” Czyli tak: 1. nie ma obsługi **bezpłatnych** podpisów osobistych 2. dodatki EZD AddIn oraz Nask Desk (bliźniacze aplikacje - z tymi samym problemami) nie mają wersji dla systemów Linux oraz MacOS. **Wymuszenie korzystania z Windows.** Ciekawie to wygląda w kontekście obowiązku zapewniania przez Państwo neutralności technologicznej w systemach rozwijanych z pieniądze z budżetu państwa. Przypominam przepis z ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne: > **neutralność technologiczna** - zasada równego traktowania przez władze publiczne technologii teleinformatycznych i tworzenia warunków do ich uczciwej konkurencji, w tym zapobiegania możliwości eliminacji technologii konkurencyjnych przy rozbudowie i modyfikacji eksploatowanych systemów teleinformatycznych lub przy tworzeniu konkurencyjnych produktów i rozwiązań; Pięknie to współbrzmi z tym: > Analiza Fundacji Instrat wskazuje, że 99% przeanalizowanych zamówień publicznych bezpośrednio lub pośrednio wyklucza produkty inne niż oferowane przez Microsoft. Do zamówień wprost wykluczających konkurencję eksperci zaliczyli aż 20% zamówień. Prawie cała reszta zawierała zapisy, które wykluczały konkurencję na inne sposoby, np. wymagając, by interfejs zawierał elementy 3D. Tylko jedno postępowanie zaklasyfikowano jako nie preferujące Microsoftu – przeprowadził je Narodowy Instytut Fryderyka Chopina. [https://instrat.pl/zamowienia-na-pozor-otwarte/](https://instrat.pl/zamowienia-na-pozor-otwarte/)