Gateway Certificate Is Fine: Why IKEv2 PEAP Login Still Fails

Your VPN gateway certificate is current, the chain validates, and the IKEv2 client still refuses the login with a message about a certificate validity interval. The instinct is to reissue the gateway certificate or switch the EAP method, and both are usually wrong. The login attempt carries two separate server identities: the gateway certificate used by IKE, and the certificate presented by whatever terminates PEAP. One of them is fine, and the other is why the client stopped.

Two identities, one login attempt

The certificate in the VPN profile belongs to the IKE exchange: it proves the gateway is the peer the profile names, under the configured IKE policy. The certificate that fails here belongs to a different conversation, the TLS session PEAP opens with whatever authenticates the user, which is often a RADIUS server such as NPS rather than the gateway itself. A third check, the user credential, happens inside that session. A valid password cannot repair an expired server certificate, and a valid gateway certificate cannot vouch for the PEAP endpoint.

This layering explains why a certificate error appears in a place where the only certificate anyone configured was the gateway's. It also explains why reissuing that certificate changes nothing.

Read the log line against the stage

Find the message that names the reason and the dates. A validity-interval complaint next to a subject error means the server rejected the certificate it was given, not that the user rejected the login. Then find the stage: a strongSwan charon log shows IKE_SA .* established before the EAP exchange starts, so a certificate error after that line belongs to the EAP identity, while an error before it points at the gateway. The stage text in a Windows client connection pane tells you the same thing.

Check the client clock before touching any certificate. A device that is hours off produces the same validity error as a genuinely expired certificate. Resetting the clock is a five-second fix, and replacing a certificate that was never the problem is an outage.

Find which endpoint terminates PEAP

In a gateway-plus-RADIUS design the gateway forwards EAP and does not terminate it. strongSwan's eap-radius plugin hands the exchange to the RADIUS server, which owns the PEAP TLS session and its certificate. Correlate one failed attempt across both logs and confirm which process actually selected a certificate for that session.

For NPS the certificate has to sit in the local computer store, carry the server authentication purpose, match the name clients expect, and be readable by the service account. The Microsoft certificate requirements for NPS list those conditions. Other EAP servers have their own selection rules, so do not copy NPS specifics into a FreeRADIUS deployment or the reverse. The rule that survives either setup is that the endpoint terminating PEAP owns the certificate you are about to change.

Replace the certificate where EAP terminates

Renew or replace the certificate on the endpoint that terminates PEAP, through the supported process, keeping the server-authentication purpose and the expected name. Install the full chain where the service looks for it and grant the service access to the private key. Restart or rebind the service, because many services keep the old certificate in memory and keep presenting it. A file copied onto the machine proves nothing about which certificate the service actually presents.

Confirm the change by correlating the next attempt with the service's own log, or by inspecting the certificate the session presented. If that log still shows the old thumbprint, the restart did not take.

Do not assume the newest file in a directory is the one in use. A copy with the right name and the wrong permissions changes nothing. Judge the change by the presented identity, not by a file timestamp.

What not to do

Do not disable PEAP validation or force a weaker inner method to get past the error. That changes the policy and removes the server-authentication property that caught the expired certificate in the first place. You would trade a working check for a working connection, and the next expired certificate would arrive with nothing to announce it.

Do not treat another operating system's successful connection as proof that the certificate is acceptable. That client may use a different EAP method, a different trust store or no server validation at all, so its success says nothing about the check that failed here. Keep one deliberate negative test, such as a wrong-name certificate or an untrusted chain, failing as expected. If that test now passes, you removed a check rather than fixed a certificate. Write down which identity failed, so the next person does not start with the gateway certificate again.