SSL CA Matcher

Introduction

TLS chain problems often start with a simple mismatch. A leaf certificate can still be inside its validity window and still fail in practice because the wrong intermediate is attached, the candidate issuer is not actually a CA certificate, or the pair does not fit the local rollout policy you care about.

This checker focuses on that narrow decision. You paste one leaf certificate and one candidate issuer certificate, choose a decision profile, and the page turns that pair into a headline verdict, a local trust score, an evidence matrix, a risk briefing, a Trust Pulse chart, and a JSON bundle you can hand to someone else.

That makes it useful when you are comparing candidate intermediates during a renewal, checking whether an outage was caused by the wrong issuer being bundled, or collecting quick evidence before a deeper PKI review. It is much less useful when the real question is broader, such as whether a browser trusts the full path, whether hostname coverage is correct, or whether the certificate has been revoked.

Keep the scope narrow as you read the result. This page compares one leaf with one candidate issuer and then scores the match against its own local rules. It does not build a full certification path to a trust anchor, consult operating-system trust stores, check revocation, or validate hostnames against subject alternative names.

Use the result as a fast pair-check and a documentation aid. Make the final trust call with a fuller chain-validation workflow once you know which issuer relationship looks plausible.

Technical Details

The helper accepts two PEM inputs and uses the first certificate block it finds in each field. From those two certificates it returns the parsed subject and issuer distinguished names, common names, serial numbers, validity dates, SHA-256 fingerprints, the issuer CA boolean when available, and a short warning list. The on-page evidence matrix is built directly from that returned data plus the local assessment values.

The strongest signal on this page is the issuer-fit check. The certificate API used by the helper treats that check as a way to ask whether the leaf was potentially issued by the supplied issuer by comparing certificate metadata, while public-key signature verification remains a separate operation. On this page, the Signature verified badge therefore means that the supplied issuer looks like a plausible issuer for the leaf. It does not mean that the full certification path has been built and trusted by a client.

Policy scoring is then added on top of the helper output. Strict DN mode compares the parsed issuer string from the leaf with the parsed subject string from the candidate issuer. CA enforcement looks only at the issuer certificate's CA boolean. Validity posture is calculated in the browser from the returned validity start and end dates plus your current browser clock, so skewed local time can change the day counts.

trust score = min(100, cryptographic confidence + policy compliance + validity posture)

The score is best read as a local decision aid, not as a percentage of real-world trust. Some combinations can exceed one hundred raw points, and the page clamps the displayed total back to 100. A high score therefore means the pair matched this page's rules well, not that a standard body has assigned an official grade.

Two limits deserve special attention. First, the page posts both PEM inputs to a helper endpoint, so the certificates do not stay local to the browser. Second, the Root CA expectation changes the scoring weight only; it does not prove that the candidate issuer is self-signed, is present in a trust store, or can anchor a valid path on its own.

Everyday Use & Decision Guide

Start with the profile that matches the decision you actually need to make. Deployment gate is the best default when you are deciding whether a leaf and an intermediate belong together for production rollout. Incident triage is better when you need a quick answer during an outage and can tolerate looser date handling for the first pass. Chain diagnostics is the broadest review mode when you are still sorting through several candidate issuers.

The page is strongest when you already know which two certificates you want to compare. It is weak when the missing piece is somewhere else in the chain. If you still need to discover the correct intermediate, prove revocation state, confirm trust-anchor selection, or check whether the server is presenting the full chain in the right order, treat this page as one checkpoint rather than the whole workflow.

• Paste one certificate block in each field. If you paste a bundle, only the first certificate block in that text is used.
• Upload is convenient for .pem, .crt, .cer, or plain-text certificate files, but the file loader still fills only one field at a time.
• Leave Issuer role expectation on Intermediate CA unless you truly expect the candidate issuer to be a root certificate.
• If the result shifts mainly because of remaining-day warnings, the issuer pairing may still be correct even though the operational timing is poor.
• Use the evidence matrix or JSON output when the result needs to be attached to a ticket, change record, or handoff note.

A sensible pattern is to use this page to narrow the likely issuer first, then rerun the same material in a full chain validator with the intended intermediates and trust anchors. That keeps the pair-selection job separate from the broader client-trust job.

Step-by-Step Guide

1. Choose a profile before you paste anything. Use Deployment gate for rollout review, Incident triage for fast incident sorting, or Chain diagnostics when you want the broadest evidence set.
2. Paste one leaf certificate into Leaf certificate (PEM) and one candidate issuer into Issuer certificate (PEM). If you prefer file upload, the page places the uploaded certificate into the first empty certificate field.
3. Open Advanced only when you need to change the issuer-role expectation, disable or enable strict DN alignment, disable or enable CA enforcement, disable or enable validity-window checks, or change the expiry guard in days.
4. Click Assess Chain. The summary strip shows the headline verdict, the trust score, the leaf and issuer badges when common names are available, and the signature, policy, and validity status badges.
5. Read Evidence Matrix first. That table gives you the pair's raw identifiers, dates, fingerprints, boolean checks, and helper warnings in a copyable format. You can copy the table as CSV, download it as CSV, or export the same evidence as DOCX.
6. Open Risk Briefing next. The gate findings summarize what the page saw, and the recommended next move tells you whether to proceed, stop, or escalate into manual PKI review.
7. Use Trust Pulse when you want a visual split between cryptographic confidence, policy compliance, and validity posture. The chart can be downloaded as PNG, WEBP, JPG, or CSV.
8. Open JSON when you need the full structured bundle, including the active policy switches and the local assessment object. Copy or download it if another reviewer needs the exact state that produced the result.

Interpreting Results

The headline verdict should be read together with the evidence fields, not by itself. GO means the leaf and issuer pair fit the selected local policy well enough to pass that profile. REVIEW means there is still enough evidence of a plausible match to keep looking, but some combination of policy or timing risk needs a human decision. BLOCK means the pair failed badly enough that the page sees no safe reason to continue under the current profile.

The badge labels need careful reading too. Signature verified is the page's issuer-fit signal, not a browser-trust guarantee. Policy mismatch means one of the local switches rejected the pair, often because the DN strings did not line up or the issuer was not marked as a CA. Validity at risk can mean a certificate is already outside its validity window, or simply that it has fewer days remaining than the active guard allows.

The most common misread is treating a high trust score as equivalent to full client trust. The page never checks trust stores, revocation, hostname coverage, or the rest of the path. A clean result here is best understood as “this looks like the right issuer pair for the chosen local policy,” not “every TLS client will accept this chain.”

Worked Examples

Routine renewal with the expected intermediate. A team pastes a new leaf certificate and the intermediate that issued it, leaves Deployment gate in place, and sees a clean issuer-fit signal, matching DN strings, a CA-marked issuer, and comfortable remaining validity on both certificates. That is the best-case flow for this page. The result can land on GO, after which the team still needs full chain validation before rollout.

Outage triage with a near-expiry but still valid leaf. The same pair is checked during an incident with Incident triage selected. If the issuer relationship is good and both certificates are still currently valid, the default triage preset can still return GO even when only a few days remain, because validity-window enforcement is off by default in that mode. That is useful for emergency sorting, but it is a reason to switch back to Deployment gate before any lasting decision is made.

Full chain pasted into the issuer field. An operator pastes a whole bundle into the issuer box and the first certificate in that text is not the immediate issuer of the leaf. The page tests only that first block, so the issuer-fit signal fails and the verdict can drop to BLOCK. The fix is not to loosen the profile. The fix is to isolate the intended issuer certificate and rerun the pair.

FAQ:

Glossary:

Leaf certificate

The end-entity certificate being tested against a candidate issuer.

Issuer certificate

The certificate that may have signed the leaf certificate.

Distinguished name (DN)

The subject or issuer name string carried inside a certificate. This page compares the parsed strings directly when strict DN mode is enabled.

CA flag

The certificate-authority boolean carried by the issuer certificate. It indicates whether the certificate may be used to verify certificate signatures.

Validity window

The period from a certificate's start date to its end date. The page checks whether both certificates are currently inside that window when validity enforcement is active.

Trust anchor

A certificate or public key that a client already trusts as the starting point for path validation. This page does not select or test trust anchors.

References:

• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC Editor, May 2008.
• Node.js Crypto API: X509Certificate.checkIssued(), Node.js.
• Node.js Crypto API: X509Certificate.ca, Node.js.
• OpenSSL verify command documentation, OpenSSL Documentation.