On 2022/05/20 00:39, Loïc Revest wrote: > ()Hello Stuart, > > Thanks for giving it also a try - I was the one bothering Tobias > earlier today with > this use case of a Windows 10 (21H2) client trying to connect to an iked > server > whose CA certificate wasn't self-signed, but signed by a root CA.
I think if it were actually signed _directly_ by a root CA then it would have worked anyway, the issue is where it's signed by an intermediate (which is the case for most, possibly all, CAs now in browser/OS root stores) > > For Windows this works provided that ISRG Root X1 is already in the > > computer trust store. It seems this is present on some but not other > > Windows installations - if you get "IKE authentication credentials > > are unacceptable" this is the likely failure. > > Windows initiates the connection as long as, as you note, the root CA is in > the computer trust store - along with the iked CA, otherwise I get the "IKE > authentication credentials are unacceptable" error you were referring to. > > On the other hand I initially (OpenBSD 7.1 release) got on iked side > (iked -dv) the following "errors": > > ikev2_pld_cert: multiple cert payloads not supported > ikev2_resp_recv: failed to parse message > > Leading to a timeout (sa_free: SA_INIT timeout) notified on both ends. > > I did try with a "consolidated" /etc/iked/ca/ca.crt (iked cert + the one > from the signing CA) as well as with a "lone" one (iked cert This definitely doesn't work without the diff. If it is connecting anyway then it is something that gets quietly fixed up on the client side. (In the case of https webservers, it is common for gui browsers to do that, whereas command-line clients typically don't - similar situation with IKEv2 clients where some handle it and others don't). > > > > > > I have connected successfully with Windows 20H2. > > I got the same "error" after having applied Tobias' updated diff. > > It's therefore likely that I did something different (wrong?) from you on > Windows and/or iked side... With this diff as-is, on the iked side, certs/hostname.example.org.crt needs to contain only the server cert, and ca/ca.crt should contain either the intermediate, or intermediate + root. On the Windows client side, if you still see the error with the above (I don't recall whether you need to restart iked or not to get it to take effect) then you _may_ need to open https://valid-isrgrootsx1.letsencrypt.org/ in MSIE or perhaps some other browser to get it to update the root store.
