Sign Checker Laravel Package

Product Decisions This Supports

• Feature scoping — signature-aware document intake. If your roadmap includes accepting signed PDFs (supplier invoices, signed contracts, HR documents, ZUGFeRD/Factur-X e-invoices), this package answers the narrow question "does this PDF carry a digital signature, and does it validate against a given certificate?" That is enough to gate a workflow: accept → manual review → reject.
• Build vs. buy for the "is this document signed?" checkbox. It is a small, single-purpose library rather than a platform. The realistic decision it informs is fork/vendor vs. buy a commercial PDF signing SDK vs. delegate to a validation service — the package makes the cheap end of that spectrum concrete and testable in a spike.
• Roadmap input for compliance-driven work. Signature verification is a recurring requirement in DACH e-invoicing and contract workflows. Evaluating this package surfaces the real cost drivers early — trust chains, revocation checking (OCSP/CRL), long-term validation (LTV) — which are exactly the items a compliance roadmap must budget for.
• Risk triage on inbound documents. Even at minimum viable scope, "signed / unsigned / signature invalid" is a useful fraud and audit signal, and a reason to route a document to a human rather than auto-post it.
• A cheap reference implementation. The source is a readable example of parsing PDF signature dictionaries and running OpenSSL verification in PHP — useful as design input even if you ultimately don't adopt it.

When to Consider This Package

Consider it when all of the following hold:

• Your stack is PHP/Laravel and you want verification in-process, with no external API call and no per-document fee.
• You need basic embedded-signature verification (PKCS#7/CAdES-style signature present in the PDF, integrity check, certificate match against a configured root/trusted certificate) — not full eIDAS qualified-signature validation.
• Volume and criticality are low to moderate: internal review queues, supplier onboarding, an MVP, or a proof of concept you intend to harden later.
• You have — or can borrow — PHP/OpenSSL competence in-house and are prepared to vendor the code into your repo and own it.
• You accept zero-community risk: 0 stars, 0 dependents, last release December 2023. Treat it as unmaintained source code you adopt, not a dependency you consume.

Look elsewhere when:

• You need legally defensible validation — qualified signatures, trust-list handling, timestamp validation, OCSP/CRL revocation, or LTV. Use a dedicated validator (commercial SDK such as SetaPDF-Signer, iText, or a managed validation/signature service) and get the compliance answer from legal, not from a library.
• You need high throughput or hardened parsing — PDF signature parsing is adversarial-input territory; a 0-star package is not where you want your attack surface.
• You require support, SLAs, security advisories, or Laravel 11/12 and PHP 8.4 compatibility guarantees. Last release 2023 plus no dependents means framework-version drift is a real, near-term breakage risk.
• Verification is not your differentiator. If a third-party API can answer "valid / invalid / unknown" for a few cents per document, buying removes an entire maintenance line item from your backlog.
• You would have to write the trust-chain logic yourself anyway — at that point the package adds little beyond a starting point.

How to Pitch It (Stakeholders)

To executives: There is a free, small Laravel package that can check whether a PDF is digitally signed and whether the signature holds up. It is a good, low-cost way to prototype signature-aware document intake before we commit budget to a commercial signing/validation vendor. It is not a compliance solution — it does not do qualified-signature validation, revocation checking, or long-term validation, and it has effectively no user base or maintainer activity since December 2023. Recommendation: fund a short spike, not a dependency. Use it to learn what we actually need, then make a build-vs-buy call with real requirements in hand.

To engineering: Single-purpose library, small surface area, permissive enough to vendor into our codebase and own. Expect to pin it, fork it, and add tests — 0 stars, 0 dependents, no release since 2023 means no upstream safety net and likely PHP/Laravel version friction. Do not put it on a hot path with untrusted PDFs without a security review of the parsing layer. Treat it as a reference implementation and a spike vehicle; budget the hardening work explicitly rather than assuming it away.