Enterprise edycja

Wsadowa walidacja podpisów

W skrócie

NextPDF Enterprise waliduje podpisy cyfrowe w wielu dokumentach PDF w jednym wywołaniu. NextPDF\Enterprise\Signature\BatchSignatureValidator::validate() przyjmuje listę dokumentów i zwraca BatchValidationReport. Każdy podpis przechodzi ten sam potok fail-closed: kryptograficzne uwierzytelnianie CMS nad podpisanym zakresem bajtów, walidację łańcucha certyfikatów zakotwiczoną w zaufaniu oraz sprawdzanie unieważnienia OCSP/CRL. Raport zawiera szczegóły dla każdego dokumentu i podpisu — CertChainStatus, RevocationStatus, TimestampStatus — tak aby narzędzia zgodności mogły ponownie wyprowadzić każdy werdykt z zarejestrowanych dowodów.

Model werdyktu jest celowo rygorystyczny. Podpis jest Valid tylko wtedy, gdy wszystkie dowody są potwierdzone afirmatywnie. Brakujące dowody unieważnienia dają Indeterminate, nigdy Valid. Ta strona omawia orkiestrator wsadowy i jego typy wynikowe. Weryfikacja pojedynczego dokumentu po stronie AdES jest udokumentowana w Weryfikacja podpisu. Osadzanie materiału walidacji długoterminowej jest udokumentowane w Archiwum.

Dostępność i licencjonowanie

Ta funkcja jest dostarczana w NextPDF Enterprise (nextpdf/enterprise) i aktywuje się z kopertą licencyjną poziomu Enterprise. Wdrożenie bez tego uprawnienia nie ładuje klas tej funkcji. Porównaj edycje i uzyskaj licencję.

Instalacja

composer require nextpdf/enterprise

Metapakiet nextpdf/premium również rozwiązuje pakiet Enterprise. Aktywacja używa Twojej koperty licencyjnej Enterprise; zobacz Licencjonowanie i aktywacja. Typy wsadowe są autoładowane pod NextPDF\Enterprise\Signature. Nie jest wymagane żadne rozszerzenie PHP poza bazową linią silnika.

Przegląd koncepcyjny

Jedno wywołanie validate() przetwarza listę wartości DocumentSignatureInput. Każde wejście niesie identyfikator dokumentu, surowe bajty PDF oraz opcjonalne zakotwiczenia zaufania w formacie PEM. Walidator wyodrębnia słowniki podpisów każdego dokumentu i uruchamia trzy etapy na podpis.

Etap 1 — uwierzytelnianie kryptograficzne. Odłączony blok CMS/PKCS#7 z /Contents jest weryfikowany nad bajtami, które pokrywa /ByteRange. Weryfikator sam ponownie oblicza skrót treści i porównuje go z atrybutem podpisanym messageDigest. Nigdy nie ufa skrótowi dostarczonemu przez producenta (RFC 5652 §5.6). Wartość podpisu musi się zweryfikować, a certyfikat podpisujący musi być powiązany z CMS. Brakujące lub zniekształcone /Contents lub /ByteRange, nieparsowalny CMS, niezgodność skrótu lub nieudane sprawdzenie podpisu — wszystkie zawodzą w trybie fail-closed. Podpis, który weryfikuje się pod SHA-1, jest traktowany jako słaby i nigdy nie stanowi pełnego zaliczenia.

Etap 2 — walidacja łańcucha i zakotwiczenie zaufania. Łańcuch podpisującego odzyskany z CMS jest walidowany jako prospektywna ścieżka certyfikacji. Dostarczone przez Ciebie trustedCerts są wejściem zakotwiczenia zaufania, w sensie RFC 5280 §6.1.1: końcówka łańcucha musi pasować do dostarczonego zakotwiczenia po odcisku palca DER SHA-256. Strukturalnie spójny łańcuch, którego końcówka nie jest skonfigurowanym zakotwiczeniem, nigdy nie jest raportowany jako zaufany. Bez użytecznych zakotwiczeń raportowany jest tylko werdykt strukturalny, a CertChainStatus::$trusted pozostaje false.

Etap 3 — unieważnienie. Unieważnienie działa na odzyskanym łańcuchu po uwierzytelnieniu, odzwierciedlając model ETSI EN 319 102-1, w którym sprawdzanie unieważnienia następuje po udanej walidacji ścieżki (klauzula 5.2.6.2). OCSP jest podstawowe: liczy się tylko kryptograficznie zweryfikowana odpowiedź, jako Good lub Revoked. Ścieżka CRL jest zapasowa i poświadcza świeżość listy. Gdy żaden klient nie jest skonfigurowany, status to unavailable.

Werdykt dla pojedynczego podpisu to SignatureValidationStatus. Taksonomia odzwierciedla model statusu ETSI EN 319 102-1 (TOTAL-PASSED / TOTAL-FAILED / INDETERMINATE) na poziomie pojedynczego podpisu:

Dowody	Werdykt
Certyfikat potwierdzony jako unieważniony	`Invalid` (rozstrzygający, niezależnie od innych sprawdzeń)
Uwierzytelnianie CMS nieudane, nie odzyskano materiału podpisującego	`Error`
Uwierzytelnianie CMS nieudane, materiał podpisującego obecny	`Invalid`
Uwierzytelniony, ale łańcuch się nie waliduje	`Invalid` (lub `Error` bez łańcucha)
Uwierzytelniony i łańcuch prawidłowy, ale brak potwierdzonego zakotwiczenia zaufania	`Indeterminate`
Uwierzytelniony, łańcuch prawidłowy, zaufany, ale brak rozstrzygającego braku unieważnienia	`Indeterminate`
Wszystkie powyższe potwierdzone afirmatywnie	`Valid`

Reguła rozstrzygającego braku unieważnienia. „Nieudowodniono unieważnienia” to nie to samo co „udowodniono brak unieważnienia”. Werdykt Valid wymaga co najmniej jednego wyniku unieważnienia Good. Zweryfikowana jako dobra odpowiedź OCSP jest formą rozstrzygającą: potwierdza własny status certyfikatu podpisującego. Kryptograficznie zaakceptowana, świeża CRL również spełnia bramkę w tej implementacji, ale wyłącznie jako poświadczenie świeżości i integralności — ścieżka nie parsuje wpisów per numer seryjny, więc nie zapewnia żadnej gwarancji unieważnienia per numer seryjny i nigdy pozytywnego werdyktu revoked. Konfiguruj OCSP wszędzie tam, gdzie liczy się pozytywne wykrywanie unieważnienia: wdrożenie tylko z CRL nie ujawni unieważnionego certyfikatu jako Invalid. Gdy zarówno wyniki OCSP, jak i CRL są Unknown lub Unavailable, status unieważnienia jest nieokreślony, a werdykt to Indeterminate. Wynika to z ETSI EN 319 102-1: niedostępna informacja o statusie unieważnienia skutkuje INDETERMINATE, nigdy zaliczeniem (klauzula 5.1.3, TRY_LATER). Jest to utwardzenie zachowania w 3.1.0 z wpływem na wsteczną zgodność: wcześniejsze wydania mogły raportować Valid bez rozstrzygających dowodów unieważnienia. Wdrożenia, które nie konfigurują żadnego klienta OCSP lub CRL, teraz często widzą Indeterminate tam, gdzie wcześniej widziały Valid.

Dwie granice uczciwie ramują tę funkcję. Po pierwsze, walidator wsadowy nie ocenia osadzonych tokenów znacznika czasu: TimestampStatus w wynikach wsadowych zawsze jest stanem nieobecności. Ocena znacznika czasu RFC 3161 należy do weryfikacji pojedynczego dokumentu; zobacz Weryfikacja podpisu. Po drugie, ta strona dotyczy walidacji tylko do odczytu. Osadzanie materiału DSS/VRI dla długoterminowej ważności to funkcja Archiwum.

Dlaczego działa to w ten sposób

Nośną decyzją jest producent werdyktu w trybie fail-closed. Valid jest wybijany tylko z afirmatywnych dowodów na wszystkich trzech osiach: uwierzytelnianie kryptograficzne, łańcuch zakotwiczony w zaufaniu i rozstrzygający brak unieważnienia. Cokolwiek niepotwierdzonego degraduje się do Indeterminate, zamiast domyślnie zaliczać, co jest postawą EN 319 102-1 wobec brakującego materiału unieważnienia. Przepustowość wsadowa nigdy nie odkupuje rygoru: warstwa wsadowa jest orkiestracją nad tym samym audytowanym weryfikatorem CMS używanym dla pojedynczego dokumentu, więc przebieg 1 000 dokumentów stosuje identyczną kryptografię. Raport oddziela też dowody od werdyktu — CertChainStatus i RevocationStatus rejestrują wejścia, na których opiera się każdy werdykt, tak aby audytor mógł go później ponownie wyprowadzić.

Tło projektowe: Podpisywanie na dużą skalę, bez kompromisów.

Powierzchnia API

Wszystkie symbole poniżej stanowią publiczne API w nextpdf/enterprise 3.1.0.

`BatchSignatureValidator`

final class BatchSignatureValidator
{
    public function __construct(
        ?SignatureExtractor $extractor = null,
        ?CertificateChainValidator $chainValidator = null,
        private readonly ?OcspClient $ocspClient = null,
        private readonly ?CrlFetcher $crlFetcher = null,
        ?CmsSignatureDataExtractor $cmsExtractor = null,
        private readonly ClockInterface $clock = new SystemClock(),
    )

    public function validate(array $inputs): BatchValidationReport
}

Rzuca lub zawodzi z: validate() rzuca \InvalidArgumentException, jeśli lista wejściowa jest pusta, oraz \OverflowException, gdy wsad przekracza 1 000 dokumentów. Dokument, który nie jest parsowalnym PDF, nie rzuca; staje się per-dokumentowym wynikiem Error. $clock jest zgodnym z PSR-20 Psr\Clock\ClockInterface używanym do decyzji o świeżości CRL, więc werdykty są deterministyczne pod zamrożonym zegarem testowym.

`DocumentSignatureInput`

final readonly class DocumentSignatureInput
{
    public string $documentId;

    public function __construct(
        string $documentId,
        public string $pdfData,
        public array $trustedCerts = [],
    )
}

Rzuca lub zawodzi z: \InvalidArgumentException, jeśli $documentId jest pustym łańcuchem. $trustedCerts jest listą certyfikatów zakotwiczenia zaufania w formacie PEM.

`BatchValidationReport`

final readonly class BatchValidationReport
{
    public function __construct(
        public array $documents,
        public int $totalDocuments,
        public int $totalSignatures,
        public int $totalValid,
        public int $totalInvalid,
        public float $durationMs,
    )

    public function allValid(): bool

    public function hasDocumentsWithoutSignatures(): bool

    public function toJson(?CertPiiGuard $piiGuard = null): string
}

Rzuca lub zawodzi z: toJson() rzuca \JsonException, jeśli kodowanie się nie powiedzie. allValid() jest true tylko wtedy, gdy istnieją podpisy i żaden nie jest nieprawidłowy. Domyślnie toJson() stosuje prywatny-domyślnie NextPDF\Enterprise\Signature\Eidas\CertPiiGuard, który maskuje nazwę podpisującego, wystawcę roota, nazwę TSA oraz diagnostykę problemów łańcucha; zobacz poziomy zaufania eIDAS po API tego strażnika.

`DocumentValidationResult` i `DocumentValidationStatus`

final readonly class DocumentValidationResult
{
    public function __construct(
        public string $documentId,
        public DocumentValidationStatus $status,
        public array $signatures,
        public int $validCount,
        public int $invalidCount,
    )

    public function hasSignatures(): bool

    public function totalSignatures(): int
}

enum DocumentValidationStatus: string
{
    case AllValid = 'all_valid';
    case SomeInvalid = 'some_invalid';
    case AllInvalid = 'all_invalid';
    case NoSignatures = 'no_signatures';
    case Error = 'error';
}

Rzuca lub zawodzi z: niczym. Niemutowalny obiekt wartości i backed enum.

`SignatureValidationResult` i `SignatureValidationStatus`

final readonly class SignatureValidationResult
{
    public function __construct(
        public SignatureValidationStatus $status,
        public CertChainStatus $certChain,
        public TimestampStatus $timestamp,
        public RevocationStatus $revocation,
        public string $signer,
        public string $level = '',
        public string $subFilter = '',
        public string $reason = '',
    )

    public function isValid(): bool
}

enum SignatureValidationStatus: string
{
    case Valid = 'valid';
    case Invalid = 'invalid';
    case Indeterminate = 'indeterminate';
    case Error = 'error';
}

Rzuca lub zawodzi z: niczym. $signer jest zweryfikowanym przez CMS podmiotem certyfikatu, gdy uwierzytelnianie przeszło, w przeciwnym razie pustym łańcuchem. $level jest etykietą wyprowadzoną z SubFilter (na przykład B-B dla ETSI.CAdES.detached), a nie ustaleniem zgodności AdES.

`CertChainStatus`

final readonly class CertChainStatus
{
    public function __construct(
        public bool $valid,
        public bool $trusted,
        public int $chainLength,
        public string $rootIssuer,
        public array $issues = [],
    )

    public function hasIssues(): bool
}

Rzuca lub zawodzi z: niczym. $trusted jest ustawiane tylko przy potwierdzonym trafieniu przynależności do zakotwiczenia zaufania, nigdy z niepustości listy zakotwiczeń.

`RevocationStatus` i `RevocationCheckResult`

final readonly class RevocationStatus
{
    public function __construct(
        public RevocationCheckResult $ocspStatus,
        public RevocationCheckResult $crlStatus,
        public bool $isRevoked,
        public ?DateTimeImmutable $revocationDate = null,
    )

    public static function unavailable(): self

    public function hasConclusiveGood(): bool
}

enum RevocationCheckResult: string
{
    case Good = 'good';
    case Revoked = 'revoked';
    case Unknown = 'unknown';
    case Unavailable = 'unavailable';
}

Rzuca lub zawodzi z: niczym z pokazanych składowych. Klasa udostępnia też sprawdzane pod kątem dowodów statyczne fabryki (good(), revoked(), fromResults()), które rzucają \InvalidArgumentException, gdy deklarowany status przeczy dowodom OCSP/CRL — wynik unieważniony nigdy nie może być wybity jako nieunieważniony, ani odwrotnie. hasConclusiveGood() jest true tylko dla statusu nieunieważnionego, gdzie co najmniej jedno sprawdzenie jest Good.

`TimestampStatus`

final readonly class TimestampStatus
{
    public function __construct(
        public bool $present,
        public bool $valid,
        public ?DateTimeImmutable $timestampTime = null,
        public string $tsaName = '',
        public array $issues = [],
    )

    public static function absent(): self
}

Rzuca lub zawodzi z: niczym. W wynikach wsadowych zawsze jest to stan absent(); zobacz Przypadki brzegowe i pułapki.

Przykład kodu — Szybki start

Zwaliduj jeden dokument i odczytaj raport. Ten przykład używa niepodpisanego PDF, więc wynik jest deterministyczny.

<?php

declare(strict_types=1);

require __DIR__ . '/vendor/autoload.php';

use NextPDF\Enterprise\Signature\BatchSignatureValidator;
use NextPDF\Enterprise\Signature\DocumentSignatureInput;

// A minimal, unsigned PDF: the validator reports it as no_signatures.
$unsigned = "%PDF-1.7\n1 0 obj\n<< /Type /Catalog >>\nendobj\ntrailer\n<< /Root 1 0 R >>\n%%EOF\n";

$validator = new BatchSignatureValidator();

try {
    $report = $validator->validate([
        new DocumentSignatureInput(documentId: 'doc-001', pdfData: $unsigned),
    ]);
} catch (\InvalidArgumentException $e) {
    // Empty input list, or an empty documentId.
    echo 'Rejected: ' . $e->getMessage() . "\n";
    exit(1);
}

echo 'Documents: ' . $report->totalDocuments . "\n";
echo 'Signatures: ' . $report->totalSignatures . "\n";

foreach ($report->documents as $doc) {
    echo $doc->documentId . ': ' . $doc->status->value . "\n";
}

echo 'All valid: ' . ($report->allValid() ? 'yes' : 'no') . "\n";
echo 'Unsigned documents: ' . ($report->hasDocumentsWithoutSignatures() ? 'yes' : 'no') . "\n";

Oczekiwany wynik:

Documents: 1
Signatures: 0
doc-001: no_signatures
All valid: no
Unsigned documents: yes

Zauważ, że allValid() raportuje tutaj no: wymaga co najmniej jednego podpisu i braku nieprawidłowych wyników, więc pusty zestaw podpisów nigdy nie przechodzi po cichu.

Przykład kodu — Produkcja

Zwaliduj katalog podpisanych umów z klientami unieważnienia, zakotwiczeniami zaufania, dzieleniem wsadu na fragmenty i raportem JSON chroniącym PII.

<?php

declare(strict_types=1);

require __DIR__ . '/vendor/autoload.php';

use NextPDF\Enterprise\Security\Ltv\CrlFetcher;
use NextPDF\Enterprise\Security\Ltv\OcspClient;
use NextPDF\Enterprise\Security\Ltv\OcspResponseCache;
use NextPDF\Enterprise\Signature\BatchSignatureValidator;
use NextPDF\Enterprise\Signature\DocumentSignatureInput;
use NextPDF\Enterprise\Signature\SignatureValidationStatus;

// Any PSR-18 client works; Guzzle shown here.
$httpClient = new \GuzzleHttp\Client(['timeout' => 10]);

// Revocation clients make a conclusive non-revoked (Good) result reachable.
// Without them, every verdict tops out at Indeterminate. The response cache
// lets repeat signers across the batch resolve without extra network calls.
$validator = new BatchSignatureValidator(
    ocspClient: new OcspClient($httpClient, cache: new OcspResponseCache()),
    crlFetcher: new CrlFetcher($httpClient),
);

// Trust anchors are an input: the chain terminus must match one of these.
$anchors = [(string) file_get_contents('/etc/nextpdf/trust/enterprise-root.pem')];

$inputs = [];
foreach (glob('/var/contracts/signed/*.pdf') ?: [] as $path) {
    $inputs[] = new DocumentSignatureInput(
        documentId: basename($path),
        pdfData: (string) file_get_contents($path),
        trustedCerts: $anchors,
    );
}

$exit = 0;

// One call is capped at 1,000 documents; chunk larger runs.
foreach (array_chunk($inputs, 1000) as $batch) {
    try {
        $report = $validator->validate($batch);
        // Signer PII is redacted by default in the serialized report.
        file_put_contents('/var/log/nextpdf/batch-report.jsonl', $report->toJson() . PHP_EOL, FILE_APPEND); // one JSON document per line
    } catch (\InvalidArgumentException | \OverflowException $e) {
        fwrite(STDERR, 'Batch rejected: ' . $e->getMessage() . "\n");
        exit(2);
    } catch (\JsonException $e) {
        fwrite(STDERR, 'Report encoding failed: ' . $e->getMessage() . "\n");
        exit(3);
    }

    foreach ($report->documents as $doc) {
        foreach ($doc->signatures as $sig) {
            if ($sig->status !== SignatureValidationStatus::Valid) {
                $exit = 1;
                fwrite(STDERR, sprintf(
                    "%s: %s (chain trusted: %s, revoked: %s)\n",
                    $doc->documentId,
                    $sig->status->value,
                    $sig->certChain->trusted ? 'yes' : 'no',
                    $sig->revocation->isRevoked ? 'yes' : 'no',
                ));
            }
        }
    }
}

exit($exit);

Oczekiwany wynik (stderr, dla jednego dokumentu, którego dowody unieważnienia były niedostępne; pozostałe wiersze zależą od Twoich wejść):

contract-0042.pdf: indeterminate (chain trusted: yes, revoked: no)

Raport JSON serializuje pola tożsamości podpisującego przez domyślny CertPiiGuard, więc wpis dla pojedynczego podpisu wygląda tak (fragment, poglądowo):

{
    "status": "indeterminate",
    "signer": "[REDACTED]",
    "level": "B-B",
    "subFilter": "ETSI.CAdES.detached"
}

Przypadki brzegowe i pułapki

Pusta lista wejściowa rzuca \InvalidArgumentException; więcej niż 1 000 dokumentów w jednym wywołaniu rzuca \OverflowException. Dziel większe przebiegi na fragmenty, jak w przykładzie produkcyjnym.
Aktualizacja z wcześniejszych wydań: bez skonfigurowanego klienta OCSP lub CRL unieważnienie jest unavailable, więc żaden podpis nie może osiągnąć Valid. Wcześniejsze wydania raportowały tutaj Valid; 3.1.0 raportuje Indeterminate (zobacz Przegląd koncepcyjny).
Liczniki na poziomie dokumentu są rygorystyczne: tylko Valid zwiększa validCount. Invalid, Indeterminate i Error — wszystkie zwiększają invalidCount. Dokument, którego jedyny podpis jest Indeterminate, raportuje zatem all_invalid. Bramkuj po status pojedynczego podpisu, gdy rozróżnienie ma znaczenie.
Sprawdzenie OCSP działa tylko wtedy, gdy odzyskany łańcuch ma co najmniej dwa certyfikaty, ponieważ zapytanie potrzebuje wystawcy. Łańcuch jednocertyfikatowy przechodzi do ścieżki CRL lub unavailable.
crlStatus nigdy nie raportuje revoked w wynikach wsadowych. Zapasowa ścieżka CRL poświadcza tylko świeżość listy; autorytatywny wynik unieważnienia pochodzi z OCSP.
timestamp zawsze jest absent() w wynikach wsadowych. Walidator wsadowy nie ocenia osadzonych tokenów RFC 3161; użyj Weryfikacja podpisu do oceny znacznika czasu.
signer jest pusty, gdy uwierzytelnianie się nie powiodło. Gdy ustawiony, jest podmiotem CN (lub O) zweryfikowanego przez CMS certyfikatu — nigdy nieuwierzytelnionym łańcuchem /Name ze słownika podpisu.
Wpisy trustedCerts muszą być certyfikatami PEM. Pusta lub zniekształcona lista zakotwiczeń daje wyłącznie strukturalny werdykt łańcucha z trusted: false, ograniczając werdykt do Indeterminate.
Bajty, które nie zaczynają się nagłówkiem PDF, dają per-dokumentowy status error z zerową liczbą podpisów — bez wyjątku.
toJson() domyślnie redaguje PII. Przekaż new CertPiiGuard(disclosePii: true) tylko tam, gdzie masz udokumentowaną podstawę prawną do przetwarzania tożsamości podpisującego.

Uwagi dotyczące bezpieczeństwa

Producent werdyktu w trybie fail-closed. Valid wymaga wszystkiego z: zweryfikowanego uwierzytelniania CMS nad skrótem /ByteRange, prawidłowego łańcucha, potwierdzonej przynależności do zakotwiczenia zaufania i rozstrzygającego statusu nieunieważnionego. Każde niepotwierdzone sprawdzenie degraduje werdykt; nic nie zalicza domyślnie.
Brak prania tożsamości. Raportowany podpisujący jest kryptograficznie powiązanym podmiotem certyfikatu. Wpis /Name to kontrolowane przez atakującego metadane i nigdy nie jest ujawniany jako podpisujący.
Słabe algorytmy nigdy nie przechodzą. Podpis SHA-1, który się weryfikuje, jest nadal raportowany jako nieprawidłowy; ważność kryptograficzna pod słabym skrótem nie jest prana w pełne zaliczenie.
Zaufanie jest wejściem, nie wnioskiem. Dostarczone przez Ciebie zakotwiczenia są dopasowywane do końcówki łańcucha po odcisku palca DER SHA-256 (RFC 5280 §6.1.1). Samospójność łańcucha ani sama niepusta lista zakotwiczeń nigdy nie ustanawiają zaufania.
Unieważnienie jest rozstrzygające. Zweryfikowane oświadczenie o unieważnieniu wymusza Invalid niezależnie od każdego innego sprawdzenia; niedostępne dowody wymuszają Indeterminate.
Prywatność domyślnie w zserializowanym wyniku. toJson() maskuje CN podpisującego, DN wystawcy roota, nazwę TSA i diagnostykę problemów łańcucha, chyba że zrezygnujesz, implementując minimalizację danych z Artykułu 5(1)(c) RODO na granicy serializacji.
Deterministyczny czas. Decyzja o świeżości CRL odczytuje wstrzyknięty zegar PSR-20, a nie zegar ścienny hosta, więc werdykty unieważnienia są odtwarzalne w testach.

Zgodność

NextPDF Enterprise implementuje zachowanie oparte na ETSI EN 319 102-1 (trójwartościowy model statusu walidacji i reguła, że niedostępna informacja o unieważnieniu daje INDETERMINATE), RFC 5652 §5.6 (ponowne obliczanie skrótu po stronie weryfikatora) oraz RFC 5280 §6.1 (zakotwiczenia zaufania jako wejścia strony ufającej do walidacji ścieżki). Wsparcie to nie zgodność, a zgodność to nie certyfikacja. NextPDF nie posiada żadnej certyfikacji ani żadnej nie przyznaje. Walidator wsadowy nie jest kwalifikowaną usługą walidacji, a jego statusy są inżynierskimi werdyktami zbieżnymi z taksonomią EN 319 102-1 — a nie wskazaniami TOTAL-PASSED/TOTAL-FAILED/INDETERMINATE z pełnego procesu walidacji z klauzuli 5. W szczególności tryb wsadowy nie wykonuje żadnego dowodu istnienia ani przetwarzania znacznika czasu; obejmuje to weryfikacja pojedynczego dokumentu.

Zachowanie w trybie FIPS

Walidator wsadowy nie konsultuje żadnej polityki trybu FIPS, a włączenie trybu FIPS nie zmienia werdyktów wsadowych. Jego obsługa algorytmów po stronie weryfikacji jest stała i fail-closed: słabe (SHA-1) podpisy nigdy nie są raportowane jako Valid, z trybem FIPS lub bez niego. Polityka trybu FIPS Enterprise bramkuje stronę podpisywania/generowania, udokumentowaną w FIPS 140 — Dogłębne odniesienie. Wsparcie FIPS 140 jest deklaracją zdolności, a nie roszczeniem walidacji ani certyfikacji.

Kontrakt zachowania

validate() rzuca \InvalidArgumentException dla pustej listy i \OverflowException powyżej 1 000 dokumentów. Zniekształcone dokumenty nigdy nie rzucają; dają per-dokumentowe wyniki error.
Valid wymaga koniunkcji: CMS kryptograficznie zweryfikowany, łańcuch prawidłowy, przynależność do zakotwiczenia zaufania potwierdzona oraz RevocationStatus::hasConclusiveGood() prawdziwe.
Certyfikat potwierdzony jako unieważniony jest rozstrzygający: werdykt to Invalid niezależnie od wszystkich innych dowodów.
Oba sprawdzenia unieważnienia Unknown/Unavailable oznaczają Indeterminate, nigdy Valid (utwardzenie 3.1.0, wpływ na wsteczną zgodność).
Uwierzytelniony, prawidłowy pod względem łańcucha podpis bez potwierdzonego zakotwiczenia zaufania jest Indeterminate — autentyczny, zaufanie nieustanowione.
signer jest zweryfikowanym przez CMS podmiotem lub pustym łańcuchem; wpis /Name nigdy nie jest używany.
timestamp zawsze jest stanem nieobecności w wynikach wsadowych.
validCount liczy tylko Valid; wszystkie inne statusy wliczają się do invalidCount, a status dokumentu agreguje się z tych liczników.
toJson() stosuje prywatny-domyślnie CertPiiGuard, chyba że strażnik zostanie przekazany jawnie.
Sumy raportu są dokładnymi sumami po wynikach per dokument; durationMs to zmierzony czas ścienny wsadu.

Rozwiązanie zastępcze w Core

Moduł Bezpieczeństwo / Podpisywanie NextPDF Core jest stroną producenta: tworzy podpisy CMS, stosuje znaczniki czasu RFC 3161 oraz waliduje łańcuchy i unieważnienie dla materiału osadzanego w czasie podpisywania. Core nie dostarcza orkiestratora wsadowego po stronie weryfikacji: brak raportu wielodokumentowego, brak zagregowanej taksonomii statusów, brak werdyktów unieważnienia OCSP/CRL dla dokumentów stron trzecich i brak serializacji raportu chroniącej PII. Na samym Core musiałbyś sam wyodrębnić i zweryfikować każdy podpis oraz zbudować własne raportowanie. Weryfikacja pojedynczego dokumentu Enterprise (Weryfikacja podpisu) i ten orkiestrator wsadowy zapewniają tę warstwę.

Granica publikacji

Ta strona dokumentuje wyłącznie zewnętrznie obserwowalne zachowanie i wspieraną publiczną powierzchnię API. Wewnętrzne ścieżki przestrzeni nazw, klasy pomocnicze, tabele mechanizmów, nazwy plików runbooków i prefiksy zgłoszeń są poza zakresem.

Zobacz też

Weryfikacja podpisu — kryptograficzna weryfikacja pojedynczego dokumentu AdES/PAdES, w tym walidacja znacznika czasu i łańcucha archiwalnego
Archiwum — osadzanie materiału DSS/VRI i znaczników czasu dokumentu dla długoterminowej ważności
Walidacja — strukturalne sprawdzenia polityki tylko do odczytu, bez kryptografii
Podpis — Dogłębne odniesienie — dogłębne odniesienie modułu Signature
Poziomy zaufania eIDAS — API CertPiiGuard i mapowanie poziomów zaufania
Podpisywanie na dużą skalę, bez kompromisów — esej Insider o projektowaniu podpisywania i walidacji dużej skali
Poprawna walidacja podpisu — esej Insider o tym, dlaczego walidacja fail-closed ma znaczenie