New VPN logins fail while certificates are valid: check the CRL

Certificates with months left and logins that fail immediately point at two different objects with two different clocks. The server is rejecting connections because the list of revoked certificates it consults has passed its own expiry date, not because the users' certificates went stale. Renewing a user certificate does nothing for that list.

Separating the two schedules is the whole diagnosis, and it changes what the fix has to be.

Two clocks, and only one of them is the certificate

A certificate carries a validity window. A certificate revocation list carries its own window, plus an issuer and a signature, and verifiers refuse to trust a list whose next-update time has passed. When that happens, the client presents a perfectly valid certificate and the server still drops the connection with a message about the list. Users read that message as 'the certificate expired', which sends the renewal request to the wrong place.

The two objects also have different owners: the certificate comes from the CA that issued it, while the list is generated on a schedule by whoever operates that CA. A user cannot refresh it, and reissuing certificates cannot extend it.

Read the list the service actually loads

Start from the running configuration rather than from the file you expect. The crl-verify path may be absolute, relative to the profile, or a copy baked into an image, and the verifier reads that copy. Inspect it in place with openssl crl -in /etc/openvpn/crl.pem -noout -issuer -lastupdate -nextupdate and compare the dates against the server's clock.

Then confirm that the file is really the one in use: check its signature with openssl crl -in /etc/openvpn/crl.pem -CAfile /etc/openvpn/ca.crt -noout, which reports a verification result rather than silently printing fields. A list signed by a different CA, or a stale copy left in a second directory, fails exactly like an expired one.

Regenerate from the revocation database, not from scratch

The new list has to come from the CA's current revocation database, through the approved signing process. Generating an empty list, or regenerating from an old backup of the index, quietly un-revokes every identity added since that backup. That converts a login outage into a security regression, and nobody notices because the symptom disappears.

Keep the generation step in version control with the rest of the CA tooling, so the interval and the signing key are documented rather than remembered. A runbook entry that names the command, the signer and the publication target is enough. Anyone on call can then regenerate without guessing which index file is authoritative. Store the list's serial and next-update time with the deployment record.

Deploy where the verifier looks

Copy the new list to the path the service reads, set ownership and mode so the service account can read it but others cannot, and reload or restart per the documented behaviour. If the daemon caches the list at startup, replacing the file without a reload changes nothing that the running process will notice. Confirm the timestamp the process reports after the reload.

If several services verify clients, deploy to each of them. Updating one endpoint and leaving another with the old copy produces a failure that appears only for the users who land on the second one. Keep a short list of those endpoints in the same runbook. After the rollout, check each one's reported list date rather than assuming the copy landed.

Make the next deadline visible before it passes

A longer publication interval lowers the frequency of this incident without creating a process. Pick the interval from the operator's policy, then alert on the deployed list's next-update field with enough lead time to regenerate and deploy. Alert on the deployed copy, not on the CA host, because the deployed copy is what fails.

After deployment, verify both directions: a permitted user connects, and a known revoked identity still fails. The second check is the one that catches an incomplete regeneration, and it takes one command against a test profile you keep for exactly this purpose.