CA Matcher
Verify an end-entity certificate against its CA / intermediate.
Runs 100% in your browser — nothing you paste or generate ever leaves your device.
Paste an end-entity certificate and a candidate CA / intermediate. We check whether that CA directly signed the leaf.
Quick answer
CA Matcher verifies in your browser that a given CA or intermediate certificate actually signed your leaf certificate, checking both the issuer/subject names and the signature. Use it to assemble the correct chain and eliminate the missing-intermediate errors that fail on mobile and non-browser clients.
CA Matcher verifies that an end-entity (leaf) certificate was really signed by a given CA or intermediate certificate, so you can confirm a chain is correct before you install it. It runs in your browser and uploads nothing. The check is the practical answer to the most common TLS deployment fault: a missing or wrong intermediate certificate that makes clients fail to build trust even when the leaf itself is fine.
Every publicly trusted certificate forms a chain: your leaf is signed by an intermediate CA, which is signed by a root that ships in operating systems and browsers. Your server must present the leaf plus the correct intermediates. Pair the wrong intermediate, or omit it, and many clients cannot connect. This tool takes a leaf and a candidate CA or intermediate certificate and tells you whether the signature and issuer relationship actually hold, so you assemble the right bundle the first time.
Local verification, nothing uploaded
The tool parses both certificates and checks the cryptographic and naming relationship between them entirely in your browser; neither file is transmitted. Because these are public certificates rather than private keys the sensitivity is lower, but doing it locally is still faster and keeps your workflow self-contained. You can paste a leaf and an intermediate and get an immediate yes or no on whether they belong together.
How the match is checked
A certificate is validly issued by another when two things hold: the leaf's Issuer field equals the CA certificate's Subject, and the leaf's signature verifies against the CA certificate's public key. The tool checks both. Matching names alone are not enough, since anyone can copy a name; the signature verification is what proves the CA actually issued the leaf. When both pass, that CA certificate is the correct next link in your chain.
Fixing a broken chain
If the match fails, the intermediate you have is not the one that signed your leaf. CAs often have several intermediates, and picking the wrong one is easy. Download the exact intermediate bundle your CA published for your certificate, verify each link here, then concatenate leaf then intermediate(s) into the certificate file your server loads. Do not include the root; clients already trust it, and sending it wastes handshake bytes.
Why the chain matters
Desktop browsers hide chain problems by caching intermediates and fetching missing ones via the AIA URL, so a broken chain can look fine on your laptop while failing for mobile apps, API clients, and OpenSSL. Those failures are intermittent and hard to diagnose, appearing only for some users. Verifying the leaf-to-intermediate relationship here, before deploy, removes that whole class of hard-to-reproduce trust errors.
Frequently asked questions
- What does CA Matcher actually confirm?
- It confirms that a specific CA or intermediate certificate is the one that signed your leaf certificate. It checks that the leaf's Issuer matches the CA's Subject and that the leaf's signature verifies against the CA's public key. Both must hold, so a real cryptographic issuance is proven, not just a coincidental name match.
- Why does my site work in Chrome but fail elsewhere?
- Chrome and other desktop browsers cache intermediates and can fetch a missing one via the certificate's AIA URL, so they build the chain even when your server omits the intermediate. Mobile apps, command-line tools, and many libraries cannot. If those clients fail, your bundle is missing the correct intermediate, which this tool helps you identify and add.
- Should I include the root certificate in my bundle?
- No. Clients already trust the root through their built-in store, so sending it is unnecessary and only enlarges the handshake. Your server should present the leaf followed by the intermediate(s) up to, but not including, the root. Use this tool to confirm each intermediate link, then stop at the root.
- How do I order certificates in the chain file?
- Leaf first, then each intermediate in order toward the root, and no root. So the file reads: your certificate, then the intermediate that signed it, then any higher intermediate. Verify each adjacent pair with this tool. Getting the order wrong, or mixing an unrelated intermediate in, causes chain-building failures on strict clients.
- The names match but verification fails, why?
- Because a matching Issuer and Subject name is not proof of issuance; the signature must also verify against the CA's public key. If names match but the signature does not, you have a different intermediate that happens to share a name (CAs reissue intermediates with the same subject but different keys). Download the exact intermediate your CA specifies for your certificate.
- Is this the same as decoding a certificate?
- No. The SSL & CSR Decoder shows you what is inside one certificate. CA Matcher compares two certificates and verifies the signing relationship between them. Use the decoder to inspect a single file, and CA Matcher to prove that a leaf and an intermediate form a valid link in the trust chain.