| Field | Value |
|---|---|
| {{ row.label }} | {{ row.value }} |
| # | Role | Subject | Issuer | Expires | Days | Link | Key |
|---|---|---|---|---|---|---|---|
| {{ row.position }} | {{ row.role }} | {{ row.subject }} | {{ row.issuer }} | {{ row.validTo }} | {{ row.daysToExpiry }} | {{ row.linkStatus }} | {{ row.keyProfile }} |
{{ chainPem }}
Certificate chains are the sequences that link a leaf certificate to the certificate authorities that issued it. When that sequence is incomplete, out of order, expired, or paired with the wrong intermediate, a service can present a certificate and still fail in browsers, mail clients, APIs, or load balancers that cannot build a trustworthy path.
This tool checks that path from either direction. You can paste PEM blocks, upload a certificate file, or point it at a live host or URL. It then assembles the chain, follows Authority Information Access issuer links when possible, and returns a chain table, diagnostics summary, operator action list, expiry chart, PEM bundle, and JSON record that you can copy or download.
That makes it useful in two different moments of the same certificate lifecycle. One is incident response, when an endpoint is already serving something unexpected and you need evidence of what is actually on the wire. The other is deployment preparation, when you have certificate files in hand and want to confirm that the leaf and intermediates really connect before you install them on a server, proxy, CDN, or mail gateway.
A common example is a renewal where the leaf certificate was replaced but the intermediate bundle was not. Some clients may still connect while others fail because the path stops early or points at the wrong issuer, so chain evidence is more useful than a leaf-only certificate view.
A successful run here is a strong packaging and linkage check, not a universal trust verdict. The tool verifies adjacency, signatures, validity windows, and chain completeness as implemented by its helper, but it does not stand in for every browser, operating system trust store, or policy engine that may evaluate the same certificate path differently.
Start with the simplest input that matches the question you are trying to answer. If you are debugging a live service, enter the host or URL and let the helper fetch the peer certificate from the remote endpoint. If you are preparing a deployment bundle, paste the PEM content or upload the file you already plan to install. When both a host and PEM text are present, the package gives priority to the pasted certificate material, which is the safer path when you need to validate a candidate bundle before rollout.
Read the result in layers. The top summary tells you how many certificates were assembled, whether the chain reached a self-signed root, whether that root is included in the exported bundle, how many issuers had to be fetched from AIA, and whether the package considers the result healthy, worth review, or in need of action.
The Chain Summary tab is the next stop when the answer is not obvious. It shows subject and issuer names, validity dates, days remaining, CA flags, link status between neighboring certificates, and any warnings produced during path building. If the chain still looks wrong there, the Diagnostics and Operator Actions tabs turn the raw findings into counts, issue codes, and remediation steps that are easier to hand to another operator.
The advanced controls change meaning in specific ways. Port and SNI override matter when the wrong certificate may be tied to the wrong listener or virtual host. Max fetch depth limits how far the helper will chase AIA issuer links. Include root certificate changes only the exported bundle, not the underlying chain logic. Renewal lead time does not change certificate dates; it changes when the operator action list starts treating the chain as rotation-ready.
| Observed result | What it usually means | Best next check |
|---|---|---|
Complete to root and Verified links |
The helper found a clean parent sequence from the leaf toward a trust anchor. | Confirm expiry dates and decide whether the exported bundle should omit or include the root. |
Chain incomplete |
A parent certificate is missing, unreachable, or not discoverable from the available bundle and AIA hints. | Check whether the endpoint serves the right intermediates and whether issuer URLs are reachable from the helper path. |
Issuer DN mismatch or Signature mismatch |
The next certificate is not the actual issuing parent for the current one. | Replace mixed or misordered intermediates with the exact CA-issued chain for that leaf certificate. |
Root included |
The output PEM contains the self-signed trust-anchor certificate. | Keep it only when your installer expects that format; many runtime endpoints need leaf plus intermediates instead. |
This package always works through a helper request. When you run a live lookup, the browser sends the normalized host, selected port, optional SNI value, root-inclusion choice, and fetch-depth setting to the helper. When you paste PEM text or upload a certificate file, that certificate material is sent as part of the same request. The response is intended for request-time inspection rather than long-term caching, but the workflow should still be treated as data leaving the browser.
For live targets, the helper normalizes the host, clamps the port into the valid TLS range, and opens a TLS connection to collect the peer certificate chain directly from the endpoint. It records the remote IP, preserves the first certificate as the leaf, and walks any peer-supplied issuers upward. For pasted PEM input, the helper extracts every certificate block it can parse, orders the usable blocks into a leaf-to-parent path, and keeps unrelated extras aside instead of forcing them into the chain.
Parent discovery then happens in two passes. The helper first tries to match issuers from certificates already present in the seed bundle. If a parent is still missing, it inspects the Authority Information Access extension for CA Issuers URLs and tries to fetch issuer certificates from those locations over HTTP or HTTPS. That fetch can stop because there is no AIA URL, the URL does not respond, the returned data is not a certificate, the same certificate would create a loop, or the configured depth limit has been reached. All of those conditions become visible warnings instead of silent failures.
The tool also performs local chain checks that are useful in operations even when a full trust-store verdict is outside scope. It compares issuer distinguished names between adjacent certificates, verifies signatures between neighbors, calculates days to expiry from the certificate validity window, tags certificates as Expired, Not yet valid, Expiring soon, or healthy, and rolls those signals into a package-level assessment of Healthy, Review, or Action needed. That is why the operator actions can distinguish an urgent replacement from a routine renewal rehearsal.
Root handling is deliberate rather than cosmetic. If the helper reaches a self-signed root, the chain is considered complete, but the default exported bundle omits that root unless you explicitly enable it. Chain completeness and bundle composition are related questions, not identical ones.
| Field or view | What the package computes | Why it matters |
|---|---|---|
Link Status |
Per-hop issuer-name and signature checks between neighboring certificates | Shows whether a certificate really links to the next certificate in the assembled path |
Status and Days Left |
Validity-state labels derived from certificate dates | Separates hard failures such as expiry from shorter-term renewal planning |
Diagnostics |
Counts for expiry, not-yet-valid items, expiring-soon items, mismatches, warnings, and ignored extras | Condenses a long chain into a triage summary |
Operator Actions |
Priority-ranked remediation rows with deadlines and suggested owners | Turns certificate facts into work that can be assigned or tracked |
PEM Bundle and JSON |
The assembled output chain and the full structured helper response | Supports installer packaging, record keeping, and handoff to another operator |
Host or URL when you want to inspect what a live endpoint presents. Use Leaf certificate (PEM) or the upload field when you want to validate a bundle before deployment.Port and SNI override only when the service is not on the default TLS port or when a shared listener may present different certificates for different names.Max fetch depth at the default unless you know the chain requires more issuer lookups. Enable Include root certificate only if the target installer expects the self-signed root in the exported PEM.Build Chain and read the summary badges first. Confirm the number of certificates assembled, whether the chain is complete, whether the root is included or omitted, how many issuers were fetched from AIA, and which assessment badge the package assigned.Chain Summary next. Check subject and issuer names, dates, days remaining, CA flags, and per-row link status before trusting the exported bundle.Diagnostics and Operator Actions. Those tabs explain whether the problem is expiry, missing intermediates, wrong issuer pairing, extra certificates, or a warning condition such as unreachable AIA links.The first decision is whether the chain is complete in a way that matches your deployment goal. A Complete to root result with verified links means the helper found a consistent path. That does not automatically settle every trust question, but it does mean the bundle is internally coherent in the way this package checks it.
An incomplete chain usually means a missing intermediate, an AIA lookup that could not recover the parent, or a seed bundle that did not contain a usable parent path. A warning count by itself is not always fatal, but a warning paired with incompleteness should be treated as a packaging problem until you can explain why the missing parent does not matter in the target environment.
The best reading is usually to combine three views: the chain table for facts, the diagnostics tab for counts, and the operator actions tab for what to do next. If those three tell the same story, the result is ready for packaging or remediation. If they do not, pause and inspect the warnings rather than trusting the summary badge alone.
Checking a live endpoint after renewal. Suppose you enter example.com on port 443 and leave the PEM field empty. The helper fetches the peer certificate from the host, records the source IP, and tries to walk the path upward. If the service presents the new leaf but omits the intermediate, the chain may come back incomplete unless the missing parent can be recovered from AIA. In that case the diagnostics and warnings tell you whether the live endpoint is self-sufficient or still dependent on external issuer downloads.
Validating a bundle before installation. Suppose you paste a leaf certificate plus one intermediate into the PEM field while also leaving a host value in place. The pasted PEM takes priority, so the result reflects the candidate bundle rather than the current live endpoint. That is useful when you need to compare what is installed today against what you plan to install next without changing servers first.
No. The result shows that the helper could assemble and verify a coherent certificate path with its own checks. Browser trust still depends on local trust stores, name checks, policy rules, revocation handling, and client-specific behavior that are outside this package.
Because many server deployments ship the leaf certificate and intermediates while relying on the client trust store for the root. The tool still lets you include the root when a particular installer or packaging convention requires it.
The run continues, but the helper records a warning and may leave the chain incomplete. That is often a sign that the endpoint should serve the full intermediate chain itself instead of relying on AIA recovery.
No. This package relies on a helper for both live endpoint checks and pasted certificate parsing. Use the exports for local record keeping, but treat the request itself as a server-assisted workflow.