9 grudnia 2025

Implementacja wewnętrznego systemu podpisów PAdES LTA opartego na prywatnej infrastrukturze PKI Webtechnika 2025

Wdrożyliśmy prywatną infrastrukturę PKI umożliwiającą automatyczne podpisy PAdES LTA dla dokumentów PDF z pełną kontrolą nad certyfikatami. System zapewnia długoterminową weryfikację bez dostępu do internetu, zgodność z ETSI i integrację z aplikacjami webowymi. Idealne rozwiązanie dla organizacji chcących uniezależnić się od zewnętrznych dostawców podpisów elektronicznych.

Implementacja wewnętrznego systemu podpisów PAdES LTA opartego na prywatnej infrastrukturze PKI Webtechnika 2025

Wprowadzenie

Organizacje, które chcą uniezależnić się od zewnętrznych usługodawców podpisu elektronicznego i zautomatyzować procesy podpisywania dokumentów, coraz częściej budują własne PKI (Public Key Infrastructure). Celem projektu było zapewnienie pewnego, długotrwałego i automatycznie weryfikowalnego podpisu dokumentów PDF w standardzie PAdES LTA, z pełną kontrolą nad cyklem życia certyfikatów użytkowników oraz z możliwością integracji z aplikacjami webowymi.

Architektura PKI zastosowana w projekcie

System opiera się na dwupoziomowej hierarchii PKI.

Root Certificate Authority (Root CA)

• Funkcja wyłącznie podpisywanie certyfikatu Sub-CA.
• Działa jako trust anchor.
• Klucz prywatny Root CA jest trwale odseparowany od środowiska operacyjnego (offline CA).
• Udostępniane certyfikat Root CA w formacie PEM, Certificate Revocation List (CRL) Root CA.

Subordinate Certificate Authority PAdES (Sub-CA)

• Odpowiada za generowanie certyfikatów użytkowników podpisujących dokumenty.
• Obsługuje OCSP dla bieżącej weryfikacji statusu certyfikatu.
• Generuje i publikuje Certificate Revocation List (CRL).
• Sub-CA posiada jasno zdefiniowany profil PAdES, zgodny z wymaganiami dotyczącymi użycia: digitalSignature=true, contentCommitment, nonRepudiation=true.
• Zakazane: keyCertSign, crlSign, encipherment i inne nieistotne dla podpisów osobowych.
• Taki profil odpowiada zaleceniom ETSI EN 319 411-2 oraz wymogom Adobe PDF Signature.

Proces podpisywania certyfikatów użytkowników (End Entity)

1. Rejestracja podmiotu uprawnionego
   Zewnętrzne systemy potrzebujące dostępu do Sub-CA PAdES muszą zdobyć Access Token. Odbywa się to poprzez wysłanie request POST na endpoint rejestracji w CA.
   Body: commonname "Authorized Entity name", countryname "PL", email "test@test.pl".
   Następnie Sub-CA PAdES rozpatrzy prośbę o dostęp i jeśli dostęp został przyznany, zostaje wysłany email z linkiem umożliwiającym pobranie Access Token. Link jest ważny przez 24h od wysy
   ki lub do pierwszego użycia. Access Token należy następnie umieszczać przy każdym request w Request Header: Authorization: Access-Token-to-CA-PAdES.
2. Rejestracja End Entity
   Osoby ubiegające się o podpisany certyfikat (End Entity) muszą najpierw zostać zarejestrowane w systemie aby otrzymać Secret Token. Odbywa się to poprzez wysłanie request POST na endpoint rejestracji end entity.
   Header: Authorization: Access-Token-to-CA-PAdES
   Body: email "jk@example.pl", commonname "Jan Kowalski", countryname "PL", stateorprovincename "warminsko-mazurskie", localityname "Olsztyn".
   W otrzymanej odpowiedzi (response) znajdować się będzie Secret Token: {"secrettoken": "Secret-Token"}.
3. Podpisanie CSR
   Gdy End Entity posiada swój Secret Token, następnym krokiem jest wygenerowanie pary kluczy i Certificate Signing Request (CSR), a następnie wysłanie CSR poprzez POST na endpoint Sub-CA PAdES /sign.
   CSR musi być w formacie PEM i spełniać profil PAdES. Gdy wszystko jest poprawne, Sub-CA PAdES zwraca certyfikat użytkownika w formacie PEM o ważności 5 lat.
4. Generowanie pliku .p12
   End Entity czy klucz prywatny + certyfikat + chain dostępny do pobrania i otrzymuje chroniony hasłem plik .p12, który może wykorzystać do złożenia podpisu PAdES LTA. Plik .p12 zawiera pełen zestaw potrzebny do podpisywania: klucz prywatny, certyfikat użytkownika i cały łańcuch CA.

PAdES LTA - jak działa i dlaczego ten profil jest ważny

Podpis PAdES LTA (Long-Term Archival) to najwyższy poziom podpisu PDF wg ETSI. Zapewnia możliwość sprawdzenia podpisu nawet 20 lat później, kiedy certyfikaty wygasną, a serwery OCSP już nie istnieją.

• LT (Long-Term) - Do podpisu dołączane są odpowiedzi OCSP, CRL, certyfikaty CA i Sub-CA. Dzięki temu weryfikacja nie wymaga dostępu do Internetu.
• LTA (Long-Term Archival) - Do struktury PDF dodawany jest stempel czasowy TSA nakładany na cały zestaw danych podpisu. W tym projekcie wykorzystywana jest zewnętrzny TSA FreeTSA (freetsa.org). Zapewnia to dowód, że dokument istniał i był podpisany przed określona datą, niezależnie od ważności kluczy.

Wyniki wdrożenia

• Zaimplementowane rozwiązanie umożliwia pełną automatyzację rejestrowania użytkowników, w tym generowanie CSR, bezpieczne wydawanie certyfikatów podpisu.
• Podpisy w standardzie PAdES LTA, weryfikacja długoterminowa dzięki CRL, OCSP, TSA.
• Tworzenie .p12 do użytku w zewnętrznych systemach.
• Pełna, własna kontrola nad CA i cyklem życia certyfikatu.
• System jest zgodny z typową architekturą komercyjnych CA, ale w wersji uproszczonej i zoptymalizowanej pod potrzeby klienta.

Ograniczenia i minusy rozwiązania

• Brak zaufania globalnych przeglądarek PDF (np. Adobe Acrobat)
  To najważniejszy minus. Adobe Acrobat posiada własny Adobe Approved Trust List (AATL). Jeżeli Root CA nie znajduje się w tej liście, Adobe oznacza podpis jako niezaufany, użytkownik końcowy widzi ostrzeżenia, łańcuch certyfikatów musi być ręcznie dodany do zaufanych. To normalne i spodziewane przy prywatnym PKI.
• Brak zgodności z e-podpisem kwalifikowanym
  Jeżeli ktoś oczekuje kwalifikowanego podpisu - to podpis zaawansowany, nie kwalifikowany (brak certyfikacji przez kwalifikowanego dostawcę usług zaufania). Nie nadaje się do zastosowań prawnych wymagających kwalifikowanego podpisu (np. w administracji publicznej UE).

Przykładowe użycie - korzyści

Wdrożony system podpisów PAdES LTA pozwala organizacji w pełni zabezpieczyć wygenerowane pliki PDF oraz zagwarantować ich autentyczność poprzez podpisy osób, które są bezpośrednio powiązane z treścią dokumentu.

Dla osoby nietechnicznej

• Dokumentu nie da się podrobić ani zmienić po podpisaniu. Każda, nawet najmniejsza zmiana spowoduje, że podpis stanie się nieważny.
• Wiadomo dokładnie, kto potwierdził treść dokumentu i kiedy to zrobił. Podpis nie jest obrazkiem - to techniczny dowód przypisany do konkretnej osoby.

Dla osoby technicznej

• Automatyzacja i pełna kontrola nad procesem podpisywania. System może wpiąć się w pipeline aplikacji lub workflow biznesowy.
• Weryfikacja bez Internetu (LTA). Plik PDF da się zweryfikować nawet za 10-20 lat.
• Bezpieczeństwo na poziomie komercyjnych dostawców podpisu.

Korzyści dla biznesu

• Oszczędności - brak opłat za kwalifikowane podpisy zewnętrznych dostawców.
• Pełna niezależność - certyfikaty, polityki, klucze pod kontrolą firmy.
• Standaryzacja procesu podpisywania.
• Wiarygodność dokumentów i zgodność z wymaganiami sektorowymi.

Podsumowanie

Jest to opisanie wdrożenia prywatnej infrastruktury PKI oferującej podpisy PAdES LTA, w pełni zgodne z wymaganiami ETSI i praktykami przemysłowymi. System zapewnia wysoki poziom bezpieczeństwa, skalowalność i elastyczność, jednocześnie zachowując pełną kontrolę nad procesem certyfikacji. Jedynym istotnym minusem jest brak automatycznego zaufania w aplikacjach takich jak Adobe Acrobat - wymaga ręcznego zainstalowania certyfikatów Root CA.