Renewed VPN certificate: some clients still reject it

Half the estate reconnects after the renewal and three devices refuse, each with a warning about the gateway's identity. The renewal itself is routine. What those three devices hold is a pin to the old object, and a pin is not a CA list, a name check or a trust store entry. Compare the three mechanisms before touching any client.

One renewal, two behaviours

The clients that reconnect have a trust decision that still passes, and the ones that refuse have a requirement the new certificate does not satisfy. That difference is information, not noise. Read the failing client's message precisely. A name mismatch, an unknown issuer and a changed fingerprint are three different verdicts, and only the last one points at a pin.

Also check which profile the failing client selected. An imported copy that lives in its own store does not change when the administrator edits the original file elsewhere.

A renewal replaces the object, not just the date

A fingerprint identifies the encoded certificate contents. Renewal produces a new certificate, so the fingerprint changes even when the subject name and public key stay identical. That is expected and harmless for clients that trust a CA and verify the name. It is fatal for a client configured to accept exactly one certificate, and it is also fatal for a client whose trust store never received the new issuer.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

The second line answers a different question: whether the key pair survived. A renewal that reused the key keeps that value and changes only the certificate, which is exactly the case where an administrator is tempted to assume nothing changed. Inspect the certificate that is deployed, not the one on the build host. Comparing a file in a repository proves what was generated, not what a listener is currently presenting.

Read what the client is pinning

Some clients keep a fingerprint in their profile and compare it on every connection. Others store it in a platform trust store, and others again rely only on a CA. The repair differs in each case, so identify the mechanism first.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

The first command shows a pin in a conventional profile; the second shows the fingerprint the endpoint actually serves right now. When those two differ, you have located the failure without guessing. Do not paste the new value into every client that complains. A client rejecting on issuer grounds will keep rejecting, and you will have taught yourself that the fingerprint was the problem when it was not.

Compare the certificate each backend serves

Intermittent results usually mean more than one endpoint, and a renewal that was applied to one node leaves the others presenting the old object. Compare each backend by address rather than by the shared name.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

A pool where one node lags explains a client that connects on the second attempt and fails on the first. It also explains a monitoring check that passes while users complain. Fix the lag first. Rolling the trust configuration before every node serves the new certificate creates a window where nothing works, and rolling it afterwards leaves clients failing unpredictably.

Change trust through the managed path

Confirm the replacement through an already trusted administrative channel before accepting it anywhere. A plausible expiry date is not proof of ownership. Update the managed configuration through whatever process owns it, with any planned overlap of acceptable identities, and keep the name verification the deployment requires. A pin without a name check is a weaker design than the CA trust it replaced.

Then verify per client: connect, confirm the identity it accepted, and note the certificate version it now trusts. A warning dismissed once has a way of returning on the next renewal.