Certificate and key matcher: do the two belong together?

Check before you restart

This is worth doing before the restart rather than after it.

A mismatch is not caught when the files are placed, and often not when the service starts. It surfaces at the first connection, which on a production host means the first visitor. Confirming the pair takes seconds and turns a potential outage into a file you replace at your own pace.

The same applies after any re-issue, because a re-issued certificate is a new certificate: if the request was generated fresh, it belongs to a new key and not to the one already installed.

Why the pair has to match

A certificate contains a public key, and it is useful only to whoever holds the corresponding private one.

During a connection the server proves possession of that private key. If the key it holds does not correspond to the certificate it presents, the proof cannot be produced, and the connection ends before any content is exchanged. Nothing about the certificate is wrong; nothing about the key is wrong; they simply are not two halves of the same thing.

That is why the failure looks so unlike a certificate problem. There is no browser warning about names or dates, because the exchange never reaches the point where a browser would evaluate the certificate at all. What causes it and how it presents is covered under handshake failures.

How the check works

You provide the certificate and the key, and the tool reports whether they correspond. Nothing about your key is stored, and the check needs no host, no connection, and no access to your server.

What it does not tell you is whether the certificate is the right one for your names or still valid; those are separate questions with their own answers under certificates.

FAQ