Neatbo.

Inspect every supplied certificate signature link

Read complete supplied PEM certificates, verify every exact-name RSA-SHA256 candidate, and retain missing, ambiguous and cyclic connection evidence.

Start with the supplied connection question

A user with a root, signing, subordinate and server hierarchy wanted to check every link after bundle order appeared to change a result. T314 makes each supplied-key candidate visible instead of presenting one undifferentiated pass. It solves the bounded connection and ordering task; it does not reproduce a trusted OpenSSL validation result.

Select 1–20 certificate-only UTF-8 PEM originals. Optional leading UTF-8 BOM and PEM whitespace are accepted. Do not include private keys, CMS bags or descriptive text outside the blocks. The input files are read locally; certificate URLs and unknown extension bytes remain inert data.

  • Keep the original files for provenance. Reports retain original name, size and SHA256.
  • Every original certificate is parsed and counted before byte-identical certificate duplicates collapse.

Know exactly which candidates are tested

A candidate exists only when original issuer and subject DER bytes are equal. Each candidate is actually verified with RSA PKCS#1 v1.5 and SHA256, including self-signatures and false candidates. An equal-looking Name encoded differently is not silently declared equivalent.

The first profile supports strict X.509 v3 DER, 2048–8192-bit odd RSA moduli and odd exponents 3–4294967295, canonical NULL algorithm parameters, exact UTC/Generalized times, and four stated Name string types. Unknown algorithms, Name types, unique IDs or malformed encodings reject the complete input. A structurally supported certificate with a bad signature remains in the complete report with a false edge.

Separate the available findings
FindingWhat the result establishesWhat remains unvalidated
signatureValid=trueSupplied RSA key verifies the exact signed bytesTrust, identity, dates and policy
ca/pathLengthDeclared BasicConstraints valuesKey usage and constraint enforcement
No verified exact-DER issuerNo supplied candidate passed the stated ruleEquivalent Names or a missing external issuer
Unique supplied orderOne non-CA leaf with one verified CA parent per stepServer-ready TLS fullchain policy

Check the complete example

The controlled input contains five blocks: a leaf, root, intermediate, repeated root and a second same-Name intermediate with a different public key. All five originals consume 207 DER-node visits. Four unique certificates produce five real signature candidates. The wrong-key leaf candidate is false; the other four candidates are true.

The only leaf path is [0,2,1]. The ordered download preserves the DER bytes of that leaf, intermediate and supplied self-signed endpoint. The 80-bit leaf serial 1208925819614629174706181 remains an exact decimal string. A same-key second parent instead creates ambiguity; an actual cross-signed cycle is retained as a cycle and cannot produce an invented order.

Download the entire audit trail

certificate-links.json retains every original/duplicate mapping, raw DER, all Name attributes, declared dates, exact serials, extensions, ASN.1 spans/inventory and true/false candidate edges. Unknown critical extensions are retained as explicitly unvalidated bytes. certificates.csv includes every unique certificate; signature-links.csv includes every candidate. Only a permitted path adds ordered-supplied-certificates.pem.

CSV applies formula protection to any formula-leading cell, while exact literal values remain in JSON. The table shows all unique certificates, with 2,000 UTF-16 units per cell; copied text is a labelled summary. Use downloads to inspect complete long fields and all edges, rather than treating the preview as the report.

  • Declared notBefore/notAfter are recorded, without checking the current clock.
  • The supplied endpoint is included for evidence and is not promoted to a trusted anchor.

Apply simultaneous limits and recover

Original files and certificate work are charged before deduplication. A well-formed input can still produce an oversized complete report; that run refuses all output. The actual native proofs cover all independently reachable ceilings and first excesses, a real 10 MiB output, and cancelled signature work restored from the same originals. Native proofs do not replace browser interaction acceptance.

Each ≤ 2 MiB is implied by the combined ≤ 2 MiB bound. At most 100 unique certificates implies at most 10,000 ordered candidate pairs: 10,000 is reachable, and a 101st original is refused before a larger allocation. Supported schema depth is at most 6. Nested constructed depth 64 outside that profile is structurally scanned then refused; depth 65 hits a protective guard. Neither is a supported-certificate capacity promise.

Budgets apply together
DimensionPublished bound
Selected originals1–20; combined ≤ 2 MiB; each ≤ 2 MiB
Original blocks / all DER-node visits100 / 10,000 before duplicate collapse
Candidate pairs / source name10,000 / 512 UTF-16 units
Complete JSON + CSV + conditional PEMTogether ≤ 10 MiB; no partial success
CancellationFresh Worker with the same original files can recover

References

Tools in this category

Expand a tool to see its steps, options and supported formats, then open its workspace.

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

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.

Steps

  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.

Capabilities 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.
Open Inspect supplied certificate signature links →