Verify if a private key matches an SSL certificate
Key Information
Type
Size
Certificate Subject
Error
About Key Matcher
Our free Key Matcher verifies whether a private key matches an SSL certificate. Paste both the certificate and private key to instantly check if they form a valid pair. Essential for debugging SSL installation issues where the key doesn't match the certificate.
How to Use
1Paste your SSL certificate (PEM format) in the first text area.
2Paste your private key (PEM format) in the second text area.
3Click "Check Match" to verify if they correspond to the same key pair.
Use Cases
•Verify key-certificate pair before server deployment
Certificates match names in two different ways, and confusing them produces both false failures and false confidence.
1Compare against the subject alternative names, not the common name. Modern validation ignores the common name entirely, so a certificate whose only matching name is in that field will be rejected by every current browser.
2Apply wildcard matching properly. A wildcard matches exactly one label, so it covers www.example.com but not www.shop.example.com and not the bare example.com. Most surprising mismatches come from an extra label, not from a missing one.
3Report each hostname separately, since a set often contains a mix. Listing every hostname against every certificate shows immediately which one is uncovered — which is usually a single forgotten name rather than a wrong certificate.
Matching is about names, not trust. A hostname can match a certificate that chains to an unknown authority, and a certificate can be valid and match nothing; those are separate questions the trust pages answer.
Tips & Best Practices
•Always verify key match before deploying to production
•If mismatched, check if you have multiple key files and use the correct one
•Keep backups of your keys matched with their certificates
Frequently Asked Questions
The server will refuse to start with a key values mismatch, which is a much clearer error than an expired certificate but happens at the least convenient moment. It means the certificate was issued against a different key from the one on disk, almost always because a renewal generated a new key and only the certificate was deployed. Check the modulus hash of both files to confirm, then deploy the matching pair together, and take the opportunity to put a verification step in the renewal pipeline.
Paste PEM, and convert first if you have DER. Convert with the Certificate Format Converter, which produces PEM without changing the underlying certificate. The comparison itself works on the decoded certificate rather than the file bytes, so it is the encoding that has to be accepted first, not the format of the original download. A file that will not parse is usually missing its BEGIN and END markers or was truncated in transit.
Two causes cover almost every case. The certificate was reissued with a new key during renewal and only the certificate reached the server, or the wrong key file was uploaded from a directory that holds several. Compare the modulus hash of the certificate and each candidate key to identify which pair belongs together; two lines of output settle it. When it recurs, the fix is procedural: verify the pair as a deployment gate rather than discovering the mismatch at restart.
Almost always the wildcard's single-label rule. A certificate for *.example.com covers shop.example.com and www.example.com but not api.shop.example.com, because that is two labels beyond the base. It also never covers the bare example.com. Multi-level coverage needs either explicit names or a separate wildcard for that level, which is the usual reason a certificate has to be reissued.
No. Modern validation ignores the common name entirely — the change was made because authorities were issuing certificates with intended names there, which made domain validation trivially bypassable. A certificate whose SAN list does not contain your hostname will fail in every current browser regardless of what the common name says.
It covers nothing for validation purposes. Such certificates existed for a transition period and browsers reject them. If you have one, it needs reissuing rather than configuring around — there is no browser setting that makes it acceptable, and continuing to serve it produces a warning for every visitor.
No, it verifies name coverage only. A certificate can cover your hostname perfectly and still be expired, self-signed, or issued by an authority no client trusts. Those are separate checks on the trust pages. Splitting them this way is useful — name coverage and trust fail independently and are fixed in different places.
Usually that host serves a different certificate — a leftover from a previous configuration, a different load balancer target, or a name nobody updated when the certificate was renewed. Per-host reporting makes this immediately visible where a single overall verdict would only say something was wrong. Finding which host is the problem is the entire point of checking a list rather than one name.
