Certificate name mismatch or expiry: telling them apart

Two VPN failures look identical from a user's chair and need opposite fixes. A name mismatch says the certificate is valid but issued for something else. An expiry error says the certificate is not valid at this moment. Neither is a password problem, and resetting credentials is the most common wasted hour in both cases. Read the failing stage before you touch anything.

The error text is the diagnosis

The client tells you which check failed, even when the message is terse. A mismatch names the hostname it expected and the name it found. An expiry error mentions validity dates or a time. Those two sentences point at different parts of the certificate.

Read them at the stage where they appear. A failure during the handshake is a certificate problem; a failure after the tunnel is up is a routing or credential problem. Retaining the stage is what keeps the investigation from drifting into unrelated settings.

If the failure varies between attempts, you have a third possibility: more than one node behind the same name.

Name checks: what the client compares

The client compares the identity it was configured to expect against the names in the certificate, which live in the subjectAltName extension. A raw IP in the profile, an alias the certificate does not list, or a name that merely resolves to the same server all fail this check. Reaching the right machine is not the same as presenting the right identity.

Inspect the certificate the server actually presents rather than a file from an earlier attempt. The command below asks for the name you configured, so the answer includes the certificate a real client would see.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

A certificate from a trusted issuer can still be for another service. Keep the client's name checks enabled, because trusting a CA does not authorize every name that CA has ever signed. Disabling the check turns a configuration error into an exposure.

Expiry: whose clock is being read

Validity is a pair of timestamps, and the verifier compares them against its own clock. A device whose clock is wrong reports a valid certificate as expired or as not yet valid, and the fix is the clock rather than the certificate. A timezone display difference is not the same thing as a wrong underlying time.

Compare the certificate dates with UTC on the client before concluding anything:

openssl x509 -in cert.pem -noout -dates
date -u

If the dates really have passed, renew through the issuer. If a replacement exists but has not become valid yet, follow the supported cutover rather than moving the clock to accommodate it. Backdating a device to satisfy a certificate is a decision with consequences well beyond the tunnel.

Why fixing one exposes the other

Validation runs a sequence of checks, and the first failure stops the report. Fix the name and the client may then tell you the chain is incomplete or the certificate expired. That does not mean the first check was unnecessary. It means the chain had more than one problem, so expect the second error rather than reading it as evidence that the first fix was wrong.

Multiple nodes make this worse. A load-balanced service can present different certificates from different members, so a test that passes twice and fails once is telling you about the fleet rather than about your client. Keep the peer address and the attempt time in the diagnosis.

That detail is what turns a flaky ticket into a reproducible one.

Prove it with a fresh connection

After the repair, open a new connection rather than resuming an old one, and confirm the stage that used to fail now passes. Then confirm the tunnel actually carries traffic, because a successful handshake is not a working route.

Retain the exact error stage and the certificate details with the ticket.

That record is what stops the next person from resetting account passwords for a certificate problem. Identity and validity are separate questions, and RFC 5280 is the reference for how the second one is evaluated.