Windows 10: Error 13801, IKE authentication credentials are unacceptable

[b0d8mr4zu]

Hello, first of all thank You for the project, it saved me a lot of config testing. The IPsec/IKEv2 vpn tunel is extremely useful for Windows users that has unprivileged accounts only and still need to work from certain location/network, but the company can't provide them with a working solution remotely. Thanks again.

So Windows doesn't like the Let's Encrypt certs, that results in the Error 13801 (error number reported by rasphone.exe, the native graphical client provides only the text error).
This looks like a problem inside StrongSwan itself and the fact that Let's Encrypt changed the layout on their chain certs.

The solution in the next post.

[b0d8mr4zu]

Solution:
change the chain of two certs in the /etc/ipsec.d/cacerts/chain.pem (linked by certbot) to a single crossigned one from Let's Encrypt https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem and restart the ipsec service.

After this windows 10 (and android Strongswan) client connected without a problem.

Strongswan probably doesn't like the new format.. This can be workarounded in the setup.sh script for now.

source:
https://community.letsencrypt.org/t/strongswan-and-x3-to-r3-transition/153557/2

[sk-pub]

Solution:
change the chain of two certs in the /etc/ipsec.d/cacerts/chain.pem (linked by certbot) to a single crossigned one from Let's Encrypt https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem and restart the ipsec service.

This helped, thanks! Just removed the 'chain.pem' link and did wget https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem.

Would be nice to have a proper fix in the setup script.

[jawj]

Thanks for filing this issue, @b0d8mr4zu.

I don't think that particular Let's Encrypt forum thread draws the right conclusion here. The problem is not that strongSwan fails to send the intermediate cert chain (after all, it works just fine with the Mac client, for example).

Instead, the underlying problem seems to be a Windows 10 bug, where certificates are supposed to be lazy-loaded, but rasdial doesn't lazy load them. See this thread: https://community.letsencrypt.org/t/isrg-root-lazy-loading-problem-missing-from-random-updated-windows-10-versions/141550

The solution that's suggested does work for now, but may fail in future if and when Let's Encrypt change their signing setup again.

An alternative solution, at least for new installations, is that we just add the following line to the Windows PowerShell client setup script:

$Response = Invoke-WebRequest -UseBasicParsing -Uri https://valid-isrgrootx1.letsencrypt.org

We can ignore the contents of $Response, but this simple get request has the side effect of loading the ISRG Root X1 cert into the certificate store (you can see this in certmgr.exe under Third-Party Root Certificate Authorities > Certificates).

And once that's happened, the VPN will connect without issues once again.

The problem here, of course, is that existing Win 10 VPN client setups will need fixing (e.g. by simply visiting that URL in Edge). So I guess I might also add instructions for the alternative-cert fix to the README and/or setup script output.

[jawj]

OK — I've now added that PowerShell command to the Windows setup instructions, and also added a new script, win10fix.sh, for situations where the server-side fix is required instead.

[s0ftice]

the server-side workaround probably stopped working as lets-encrypt-r3-cross-signed.pem expired a few days ago.

[ocind]

@jawj sorry to bug you but i tried running $Response = Invoke-WebRequest -UseBasicParsing -Uri https://valid-isrgrootx1.letsencrypt.org on the Windows client but the same issue still occurs. I am not sure how to debug this. Can you give me some pointers on where to look for the logs?

This issue has started happening on 21st October only for us. It was working just fine previously...

[jawj]

@ocind What I know about logs is described at https://github.com/jawj/IKEv2-setup#troubleshooting. I'm afraid I don't use Windows much, and the web request (or just visiting that address in Edge) does fix the issue on my Windows box.