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.
| Finding | What the result establishes | What remains unvalidated |
|---|---|---|
| signatureValid=true | Supplied RSA key verifies the exact signed bytes | Trust, identity, dates and policy |
| ca/pathLength | Declared BasicConstraints values | Key usage and constraint enforcement |
| No verified exact-DER issuer | No supplied candidate passed the stated rule | Equivalent Names or a missing external issuer |
| Unique supplied order | One non-CA leaf with one verified CA parent per step | Server-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.
| Dimension | Published bound |
|---|---|
| Selected originals | 1–20; combined ≤ 2 MiB; each ≤ 2 MiB |
| Original blocks / all DER-node visits | 100 / 10,000 before duplicate collapse |
| Candidate pairs / source name | 10,000 / 512 UTF-16 units |
| Complete JSON + CSV + conditional PEM | Together ≤ 10 MiB; no partial success |
| Cancellation | Fresh Worker with the same original files can recover |
References
- User task: check all links in a supplied bundle
Original author body and follow-up read on 2026-10-07. Layer-by-layer connection inspection matches; original OpenSSL/trust/server validation is a remaining gap.
- User task: Root / Intermediate / User certificates
Original question and first-party follow-up context read on 2026-10-07. Missing supplied issuer inspection is supported; the requested trusted-root validation is not replaced with a signature-link pass.
- RFC 5280: certificate fields, Name comparison and path validation
Sections 4.1, 6 and 7.1 read on 2026-10-07. This primary format reference establishes the distinction from full path/trust validation; it is not counted as user demand.
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
- Select the public certificate-only PEM bundles, retaining their originals. Private keys are outside this task.
- Inspect source and unique counts, declared dates, every candidate signature result, leaf-path status and cycles.
- Download complete JSON and both CSV files; if a unique supplied path exists, also inspect its ordered PEM and retained DER.
- 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.