SSL CA Matcher
Match a TLS leaf certificate to a candidate issuer with signature verification, CA checks, expiry horizons, and policy-based review guidance.{{ summaryTitle }}
{{ summaryLine }}
| Evidence | Status | Finding | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.status }} | {{ row.detail }} |
Recommended next move
- {{ note }}
The chart renderer is unavailable. The same evidence remains in the pair decision and ledger.
| Evidence | Value | Meaning | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.value }} | {{ row.detail }} |
A certificate can name a plausible issuer and still be paired with the wrong certificate. This happens when a server omits an intermediate, an administrator selects an older cross-signed CA, or two certificates share similar organization names but use different keys. The decisive pairwise question is whether the candidate issuer's public key verifies the leaf certificate's signature.
The leaf certificate identifies the site, service, device, or client at the end of a public key infrastructure (PKI) path. Its immediate issuer is usually an intermediate certificate authority (CA). A root CA normally sits farther up the path and becomes trusted through a trust store, so substituting a root for the missing intermediate usually does not repair the leaf-to-issuer link.
- Cryptographic link
- The leaf signature verifies with the candidate public key.
- Name link
- The leaf issuer distinguished name (DN) equals the candidate subject DN.
- CA authority
- Basic Constraints marks the candidate as able to issue certificates.
- Validity window
- Both certificates are currently valid and remain usable for the required rollout horizon.
These checks answer different questions. Matching names do not prove possession of the signing key, while a valid signature alone does not establish a complete trusted path. Full deployment validation must also consider the intended trust anchor, intermediate certificates, hostname or identity, certificate purpose, key usage, name constraints, policy constraints, and revocation status.
Expiry runway matters even before a certificate reaches its final day. A pair that works today may be unsuitable for a release that must remain stable through a maintenance freeze or a long device rollout. Treat a pairwise result as evidence for selecting the next issuer certificate, not as proof that every client will trust the final TLS configuration.
How to Use This Tool:
Compare one leaf certificate with the certificate expected to have signed it. Use the immediate issuing CA for an ordinary leaf-to-intermediate check.
- Paste or load the Leaf certificate in PEM form.
- Choose a Review profile. Use Deployment for a strict release decision, Triage during an incident, or Diagnostics while identifying a chain.
- Set Candidate CA role, then paste or load the Candidate issuer certificate. Private keys and certificate signing requests are not accepted.
- Set an Additional expiry buffer only when the release needs more runway than the profile baseline.
- Select Check certificate pair, then read the decision together with the signature, DN, CA, and validity evidence. If parsing fails, confirm that each input contains a certificate block bounded by the standard PEM begin and end lines.
Interpreting Results:
Issuer pair accepted means the signature verified and the selected profile found no blocking policy or expiry concern. Analyst review needed means the cryptographic link may be present but one or more identity, CA-authority, date, runway, or score conditions need attention. Pair rejected means the leaf signature did not verify with the candidate public key.
Give the signature result the most weight. A DN match is supporting identity evidence, not a substitute for signature verification. Even an accepted pair still needs full path validation against the actual client trust store, intended hostname and purpose, and the required revocation policy.
Technical Details:
Pairwise issuer checking parses the first certificate block from each input, verifies the leaf with the candidate public key, compares the leaf issuer DN with the candidate subject DN, reads the candidate's CA flag, and evaluates both validity windows at the time of the check. The candidate-role choice changes guidance only; it does not change the cryptographic signature result.
Rule Core
The three profiles apply different policy strictness and expiry horizons. An additional buffer is added to the profile baseline before the remaining-day checks are made.
| Profile | Exact DN required | CA flag required | Current validity required | Baseline horizon | Pass score |
|---|---|---|---|---|---|
| Deployment | Yes | Yes | Yes | 30 days | 85 |
| Triage | No | Yes | No | 7 days | 70 |
| Diagnostics | No | No | No | 0 days | 60 |
Formula Core
The evidence score is the rounded sum of signature, issuer-name, CA-authority, and validity points, bounded from 0 to 100.
| Component | Points | Rule |
|---|---|---|
| Signature | 45 or 0 | 45 only when the candidate public key verifies the leaf signature. |
| Issuer name | 15, 12, 4, or 0 | Deployment awards 15 for a match and 0 otherwise. Triage and Diagnostics award 12 for a match and 4 for a mismatch. |
| CA authority | 15, 12, 4, or 0 | Deployment and Triage award 15 only for a confirmed CA flag. Diagnostics awards 12 when confirmed and 4 otherwise. |
| Validity | 0 to 20 | Deployment awards 6 points for each currently valid certificate and 4 points for each certificate meeting the effective expiry horizon. Other profiles retain 20 points but still surface invalid dates for review. |
A failed signature always produces Pair rejected, regardless of score. With a valid signature, any profile concern, validity concern, or score below the profile threshold produces Analyst review needed. Only a valid signature with no concerns and a score at or above the threshold produces Issuer pair accepted.
Remaining days are whole 24-hour periods obtained by rounding down the interval from the evaluation time to the certificate expiry time. The effective horizon equals the profile baseline plus the additional buffer, which may be a whole number from 0 to 3,650 days.
Privacy and Scope Notes:
The certificate text is sent to a server-assisted checker when the comparison runs. Certificates are public-key documents, but they can still reveal internal hostnames, organization names, serial numbers, and deployment dates, so avoid submitting material that should not leave the current environment.
- The comparison accepts certificates only and does not require a private key.
- It checks one leaf and one candidate issuer, not a complete chain or trust store.
- It does not test hostname coverage, purpose, revocation, certificate policies, name constraints, or client-specific trust.
Worked Examples:
Missing intermediate during deployment
A server leaf is checked against a root certificate from the same CA family. The issuer and subject names may appear related, but the signature fails because an intermediate actually signed the leaf. The result is Pair rejected; obtain the immediate intermediate and repeat the pair check before building and validating the full chain.
Valid pair with short expiry runway
A leaf signature verifies and the candidate has the correct DN and CA flag, but the leaf has 18 days remaining under the Deployment profile. The 30-day baseline is not met, so the result requires review even though the pair is cryptographically correct. Renewal planning, rather than issuer discovery, is the next action.
References:
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, RFC Editor, May 2008.
- X509_verify_cert certificate verification, OpenSSL Documentation.
- How to verify a certificate chain using OpenSSL, Simplified Guide.