Separate certificate links from trust decisions
A signature link proves a supplied-key relationship. Preserve the full graph and make trust, identity and deployment decisions separately.
Keep an edge separate from a trust conclusion
A supplied certificate graph answers a useful question: which supplied key actually verifies which signed certificate? That question has a concrete local input and an auditable result. It still leaves the identity and policy decisions needed by a trust validator.
T314 retains every exact-name candidate and its true or false result. It also retains original duplicates, complete unknown extension bytes and paths that fail to reach an unambiguous supplied endpoint. Hiding a failed candidate or discarding an ambiguous parent would remove information needed to understand the bundle.
An ordered file has a precise meaning
One non-CA leaf and exactly one verified CA parent at each step permit a supplied order. The terminal self-signature does not resolve an alternative verified CA parent. Missing parents, competing parents and cycles therefore remain reports without an ordered PEM.
The checked five-block example yields four unique certificates and the path [0,2,1]; the wrong-key same-Name intermediate stays visible with a false leaf edge. Ordered PEM preserves three original DER objects and includes the supplied endpoint. This does not prescribe a server deployment file or authorize an endpoint as a trust anchor.
| Available evidence | Separate decision |
|---|---|
| Actual PKCS#1 v1.5 SHA256 edge | System trust / full PKIX path validation |
| Exact issuer/subject DER match | Other RFC 5280 Name equivalences |
| Declared dates and extensions | Current validity / usage / constraints / critical semantics |
| Complete supplied order | Hostname / revocation / server deployment policy |
Preserve complete evidence before sharing
Public certificates can disclose names, identifiers and extension payloads. Local processing does not remove that content from complete JSON/CSV/PEM downloads. Review the originals and complete reports before sharing them. URI, markup and extension data stay inert; the tool does not fetch a missing parent.
Keep the complete files rather than copying a shortened table cell. JSON retains exact decimal serials, all metadata, original DER and every candidate; CSV protects formula-leading cells. The copied summary and 2,000-unit table cells identify results while the downloads carry the full evidence.
- Keep original SHA256 alongside the report so a later review identifies the same source.
- Do not interpret unknown critical extensions or pathLength as enforced merely because their declared values appear.
Make bounded work reproducible
The 2 MiB total-input, 100-block, 10,000-node and 10 MiB output budgets constrain actual work, not just the visible preview. Duplicate blocks still consume parse work. The 10,000-pair guard is reached by 100 supplied unique certificates with matching Names; a genuine unfinished signature run can be cancelled and restored from the same source bytes.
Choose a separate correctly configured path validator for trust, current time, hostname, key usage, constraints and revocation. T314 labels those checks as unperformed, so a useful signature-link result can be used without inventing a broader security conclusion.
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.