Which CA signed this certificate? Verifying the issuer chain

A certificate is only trusted because something trusted vouched for it. That vouching is a cryptographic signature from a certificate authority. When a chain looks broken, the question is usually whether a given CA certificate genuinely signed the certificate below it.

How signing works

When a CA issues your certificate, it signs the certificate's contents with its own private key. Anyone can then verify that signature using the CA's public key, which lives in the CA's own certificate. If the math checks out, the certificate was genuinely issued by that CA and has not been altered since.

This repeats up a chain: your certificate is signed by an intermediate CA, the intermediate is signed by a root CA, and the root is trusted by the browser directly. Each link is a signature that the link above can verify.

Issuer name is a hint, not proof

Every certificate names its issuer in a text field, but that field is just a label. An attacker could write any issuer name they like. Real verification is cryptographic: take the supposed CA certificate, use its public key to check the signature on the certificate in question, and see whether it validates. The names matching is a clue; the signature validating is the proof.

Why this matters in practice

The most common real problem is a missing or wrong intermediate. Your certificate is fine and the root is trusted, but the intermediate that connects them is absent from what the server sends, so clients cannot build the chain. Confirming exactly which CA certificate signed your leaf certificate tells you which intermediate you are missing.

The catch is that this should be done locally; there is no reason to upload certificates to check a signature. The CA Matcher verifies in your browser that a given CA certificate signed a certificate, with nothing transmitted. For the broader symptom of an incomplete chain, see fix SSL certificate chain errors.