| Field | Value | Copy |
|---|---|---|
| {{ row.k }} | {{ row.v }} |
A certificate chain only works when each certificate is linked to the correct issuer above it. If the wrong intermediate is bundled with a leaf certificate, clients can reject the chain even though the leaf itself still looks current and well formed.
That is why a quick issuer-pairing check is useful during renewals, deployment reviews, and incident response. This tool compares one leaf certificate with one candidate issuer certificate, then turns the result into a verdict, a trust score, and a short set of follow-up notes.
A realistic case is a web team deciding which intermediate belongs with a newly issued leaf certificate. What matters is not only whether the pair looks related, but also whether the issuer is marked as a CA, whether both certificates are still within their validity windows, and whether the pairing clears the stricter rules you would use for production rollout.
The output is designed for triage rather than raw ASN.1 inspection. You get an evidence matrix, a risk briefing, and a visual split between cryptographic confidence, policy compliance, and validity posture so you can see which part of the decision is driving the verdict.
A passing verdict here does not mean a browser or operating system will trust the chain. This bundle checks a leaf and one candidate issuer, then applies local policy scoring; it does not build a full certification path, consult trust stores, or evaluate revocation.
The best first pass is to paste the leaf certificate into the first field, paste the immediate issuing CA into the second field, and leave the default deployment profile in place. That gives you the strictest normal read on DN alignment, CA signaling, current validity, and the expiry guardrail before you loosen anything.
This tool is a good fit when you already have a leaf certificate and one plausible issuer and need a quick answer about whether they belong together. It is a poor fit when the real question is broader, such as whether a browser trusts the entire chain or whether a host is serving every certificate in the right order.
Incident triage so validity warnings remain visible without blocking the run as aggressively as the deployment profile.GO but the issuer badge names a certificate you did not expect, stop there and confirm you pasted the immediate issuer rather than a root or a different branch intermediate.REVIEW or BLOCK because of date pressure, read the leaf and issuer day counts before changing the profile. That tells you whether the problem is the pairing itself or simply an expiry guardrail that is too close for the current task.Use the evidence matrix as the handoff summary, but make your final trust decision with a full path check outside this page. The tool is strongest when it helps you narrow the right issuer quickly, not when it is asked to stand in for full PKI validation.
The server-side helper accepts two PEM inputs, extracts the first certificate block from each field, and creates Node.js X509Certificate objects from those blocks. From there it returns the subject and issuer strings, common names, serial numbers, validity dates, SHA-256 fingerprints, and whether the candidate issuer is marked as a CA certificate.
The most important implementation boundary is the helper's use of x509.checkIssued(otherCert). Node documents that method as a way to see whether a certificate was potentially issued by another certificate by comparing certificate metadata, and it explicitly points readers to x509.verify(publicKey) for actual signature verification. In other words, the bundle's Signature verified badge is a candidate-issuer compatibility signal, not a full cryptographic proof.
After the helper returns its evidence, the browser computes the trust model locally. The selected profile sets rules for DN alignment, CA-flag enforcement, validity-window enforcement, and minimum remaining days. The result is then split into three component scores, clamped to 100, and mapped to GO, REVIEW, or BLOCK according to the active profile.
| Stage | What the tool does | What it tells you |
|---|---|---|
| PEM extraction | Uses the first certificate block from each input field | Confirms exactly which two certificates are being compared |
| Helper comparison | Returns checkIssued, issuer/subject strings, CA flag, dates, fingerprints, and helper warnings |
Builds the raw evidence for a possible issuer relationship |
| Policy scoring | Applies DN, CA, and validity rules from the selected profile | Shows whether the pair is acceptable for deployment, triage, or broad diagnostics |
| Verdict mapping | Combines hard failures, profile failures, and trust score thresholds | Produces the headline decision and recommendation notes |
| Component | How points are assigned | Why it moves the verdict |
|---|---|---|
| Cryptographic confidence | 55 points when the helper says the candidate issuer potentially issued the leaf | A failed pairing is the fastest path to BLOCK in every profile |
| Policy compliance | Points come from DN alignment, CA signaling, and the expected issuer role | Shows whether the pair fits your local chain policy, not just whether it looks related |
| Validity posture | Uses the browser's current time plus the expiry guardrail for leaf and issuer certificates | Separates a technically matching issuer from one that is too close to expiry or already outside the window |
The default deployment profile is intentionally strict. It requires DN alignment, requires the issuer CA flag, enforces current validity for both certificates, and expects at least 30 remaining days for each certificate. The triage profile keeps CA enforcement but relaxes DN strictness and does not hard-fail on validity windows. The diagnostics profile keeps the evidence broadest by disabling the CA and validity hard gates and setting the expiry guardrail to zero.
| Profile | Headline rule | Interpretation |
|---|---|---|
| Deployment gate | GO requires no hard fail, no policy or validity fail, and trust score >= 85 |
Use when you are deciding whether the pairing is fit for production rollout |
| Incident triage | BLOCK on hard fail or score < 70; otherwise REVIEW if policy or validity issues remain |
Use when you need quick sorting during an outage or certificate incident |
| Chain diagnostics | BLOCK only on hard fail; otherwise REVIEW if any issue remains or score < 60 |
Use when you want broad evidence before making a stricter decision elsewhere |
Privacy and network behavior. The certificates are posted to a helper endpoint for analysis, so this is not a local-only parser. The helper responds with Cache-Control: no-store, but you should still treat both PEM inputs as server-exposed data and avoid using certificates you are not willing to transmit.
Scope limits. The bundle does not build multi-certificate paths, check revocation, or compare served hostnames against SAN values. It answers a narrower question: does this leaf appear to match this candidate issuer under the selected local policy?
Run the assessment once with the strictest suitable profile before you adjust any advanced rule.
Decision profile. Leave Deployment gate selected if you need the strictest first pass, or switch to Incident triage or Chain diagnostics when you are deliberately gathering evidence under looser rules.Leaf certificate (PEM) and one PEM block into Issuer certificate (PEM). If the inputs are missing, the tool stops with an input error asking for both certificates.Advanced only if you need to change the expected issuer role, disable strict DN alignment, disable CA enforcement, disable validity checks, or change the expiry guardrail in days.Assess Chain and wait for the summary box to show the headline verdict, trust score, and the signature, policy, and validity badges.Evidence Matrix first. Check Issuer DN Matches Leaf Issuer, Issuer Has CA Flag, Leaf Days Remaining, and Issuer Days Remaining before you rely on the headline alone.Risk Briefing to read the gate findings and recommendations, then switch to Trust Pulse if you need a quick visual of which score component is pulling the verdict down.Once the pair looks plausible here, carry the same leaf and issuer into your full chain validation workflow instead of treating this assessment as the last step.
The headline verdict is useful only when you read it together with the evidence fields. GO means the pair cleared the selected local policy and did not trip the profile's hard failures. It does not mean the full chain is trusted by clients, and it does not confirm revocation or hostname coverage.
Signature verified fails, treat the pair as suspect immediately and move to a fuller chain investigation.Signature verified passes but Policy mismatch or Validity at risk remains, the certificates may still be related but not suitable for the task implied by the chosen profile.Leaf Days Remaining or Issuer Days Remaining is below the expiry guardrail, the result is telling you about operational risk, not necessarily a wrong issuer pairing.The false-confidence trap is reading a high trust score as equivalent to browser trust. The corrective check is to take the same certificate set and run full path validation with the intended intermediates and trust store before you deploy.
Production handoff with the expected intermediate. A leaf certificate for www.example.com is paired with the intermediate that issued it, the issuer CA flag is true, the issuer DN matches the leaf issuer, and both certificates have more than 30 days remaining. Under Deployment gate the result lands on GO, which means the pair looks suitable for a normal production chain review.
Incident triage with a near-expiry issuer. During an outage, the same leaf is checked in Incident triage against the expected issuer, but the issuer has only 5 days remaining. The pairing may still clear the helper comparison while the validity notes turn cautionary, which is the right signal for emergency triage: the issuer relationship looks plausible, yet the operational risk still needs follow-up.
Bundle pasted into the wrong field. An operator pastes a full certificate chain into the issuer field, and the first block belongs to an unrelated root. The verdict drops to BLOCK because the candidate issuer does not line up with the leaf. The fix is to isolate the immediate issuing CA in the issuer field and rerun the assessment.
Because the tool only compares one leaf certificate with one candidate issuer and then applies local scoring. Browser trust also depends on the rest of the path, the trust store, hostname coverage, and revocation state.
In this bundle it is the helper's candidate-issuer check based on Node's checkIssued behavior, not a full verify(publicKey) signature proof. Treat it as strong evidence for pairing, not as a final PKI verdict.
The helper takes the first PEM certificate block from each field. If you paste a bundle, only the first certificate in that text is used for the comparison.
No. The leaf and issuer PEM data are posted to a helper endpoint for analysis. The response is marked no-store, but you should still avoid submitting certificates you would not send to a server.
The helper returns the certificate dates, but the browser computes remaining days from its own current clock. A skewed local clock or a different reporting cutoff can change the displayed day counts.
validFrom and validTo dates.