Neatbo.

Inspect supplied certificate signature links

Verify every exact-name RSA-SHA256 link in local PEM certificates, preserve full evidence, and order a uniquely connected supplied chain.

Browser-local processingInputCertificate-only UTF-8 PEM bundlesOutputComplete signature-link JSON/CSV and conditional ordered PEMUp to 2 MiB per file · File limit: 20
  1. 1Add input
  2. 2Review and run
  3. 3Get your result

Tool input and files are processed in this browser without being uploaded.

Your input

Inputs are kept temporarily in this tab when switching tools. Refreshing or closing clears them; large results may need to be regenerated.

⌘ / Ctrl + Enter to run

or drag and drop them here

Files stay on this device. Your originals stay unchanged.

Up to 2 MiB per file · File limit: 20

    Preparing the tool…

    Before you start

    Select certificate-only PEM files. Inspect every supplied certificate and every exact issuer/subject DER match with real RSA-SHA256 signature verification. Review missing or ambiguous parents, failed signatures and cycles; download a unique supplied order only when the declared connection rule permits it.

    How to use this tool

    1. Select the public certificate-only PEM bundles, retaining their originals. Private keys are outside this task.
    2. Inspect source and unique counts, declared dates, every candidate signature result, leaf-path status and cycles.
    3. Download complete JSON and both CSV files; if a unique supplied path exists, also inspect its ordered PEM and retained DER.
    4. Make trust and deployment decisions in a separate properly configured validation process. This output does not establish them.

    Supported inputs and limits

    1–20 original UTF-8 PEM files, optional leading UTF-8 BOM; each ≤ 2 MiB and combined ≤ 2 MiB. Source names ≤ 512 UTF-16 units. Any filename is accepted for inspection: strict original PEM/DER content decides the format. The individual ceiling is implied by the combined ceiling, not an independent capacity.

    At most 100 original certificate blocks and 10,000 total DER-node visits across the bundle, counted before duplicate collapse. DER work includes original certificates, embedded RSA public keys and BasicConstraints. Duplicate certificates keep every source/block mapping and still consume work. Every source SHA256 and complete certificate DER is preserved.

    Strict supported X.509 v3 DER only: RSA 2048–8192 bits, odd modulus and exponent 3–4294967295, RSA PKCS#1 v1.5 SHA256 with canonical NULL parameters. UTC and Generalized times must have exact UTC syntax and real calendar dates. UTF8String, PrintableString, IA5String and BMPString Name attributes are supported. Unknown algorithms/Name string types, unique IDs, malformed DER, private-key blocks and non-certificate material refuse the complete bundle.

    All exact issuer-DER/subject-DER candidates receive actual signature verification, including failed and self-signature candidates. At most 10,000 pairs; this is implied by at most 100 unique certificates. 10,000 is reachable; 10,001 cannot independently coexist with that original-count bound. Name equivalences beyond exact DER equality remain unvalidated.

    Complete JSON, all certificate CSV rows, all signature-edge CSV rows and conditional ordered PEM together ≤ 10 MiB. JSON retains all Name attributes, serials as exact decimal strings, declared dates, ASN.1 spans/inventory, raw extensions, original duplicate mappings and every true/false edge. CSV protects formula-leading cells; JSON keeps exact literals. No truncated success.

    Preview shows every unique certificate (at most 100), with cells limited to 2,000 UTF-16 units; copied text is a labelled summary. Complete fields, edges and original DER are in downloads. DER depth 64 is an allocation guard: supported schema depth is at most 6; nested depth 64 outside the schema is refused as unsupported, and 65 hits the guard.

    Ordering requires one non-CA leaf and exactly one verified CA parent per step, ending at a supplied self-signed endpoint with no alternative verified CA parent. Ordered PEM includes that supplied endpoint and preserves DER bytes. Missing/ambiguous/cyclic paths do not get a guessed order. This is not a server-ready fullchain declaration.

    No system trust, PKIX path validation, current-date validity, hostname, key usage, pathLength constraints, unknown critical-extension semantics or revocation check. BasicConstraints CA/pathLength are declarations only. No certificate fetch, navigation, script execution or private-key use.

    Worked example

    Example input

    supplied-bundle.pem: leaf, root, intermediate, duplicate root and a same-Name intermediate with the wrong public key.
    Example options
    {}

    Example output

    5 original blocks → 4 unique certificates; 207 DER-node visits; 5 actual signature candidates, including 1 false link; unique order [0,2,1] preserves 3 supplied DER certificates.

    When something does not work

    Correct the named format, encoding or budget issue and rerun the originals. Cancellation discards results; the same selected bytes can be processed in a fresh Worker.

    Frequently asked questions

    Does a valid signature make the issuer trusted?

    No. It proves that the candidate supplied RSA key verifies these TBS/signature bytes. No trust anchor, current-date, hostname, revocation or complete PKIX validation is performed.

    Why can equal-looking issuer names remain unmatched?

    Candidate selection uses exact original issuer/subject DER. Some legitimate RFC 5280 Name equivalences differ in DER. Those comparisons are deliberately unvalidated; the tool does not silently replace the rule.

    Why is the supplied root included in ordered PEM?

    The result records the entire uniquely connected supplied path including its self-signed endpoint. It is evidence of supplied order, not a TLS server fullchain recommendation; deployment policy must be determined separately.

    Documentation & further reading

    Inspect every supplied certificate signature link →Separate certificate links from trust decisions →

    Related tools