Hello Stuart, Le ven. 20 mai 2022 à 16:31, Stuart Henderson <s...@spacehopper.org> a écrit :
> 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) iked CA was indeed directly signed by a root CA, but I did forget to mention that the latter was a self-signed CA. Sorry for the oversight. Therefore the "chain of trust" on my setup is : self-signed root CA > iked "intermediate" CA > certs > 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. I did re-create a whole new set of CAs/certs on a fresh OpenBSD 7.1 -release and ran into the same issue: timeout on Win10 side since iked dropped the connection attempt due to a seemingly lack of multiple provided certs support: > > ikev2_pld_cert: multiple cert payloads not supported > > ikev2_resp_recv: failed to parse message According to Tobias who helped me dig the issue on IRC, this behavior comes from iked being stricter than what the corresponding RFC describes. More precisely, the RFC commands the IKE daemon to accept up to 4 chained certificates, while iked drops the connection attempt if there is more than one CA provided. The ikev2_pld_cert() in ikev2_pld.c is the one "dropping the ball", as it returns -1 in case multiple certs are involved. Tobias provided me with a provisional diff to circumvent the issue: Index: ikev2_pld.c =================================================================== RCS file: /cvs/src/sbin/iked/ikev2_pld.c,v retrieving revision 1.123 diff -u -p -r1.123 ikev2_pld.c --- ikev2_pld.c 14 Mar 2022 12:58:55 -0000 1.123 +++ ikev2_pld.c 23 May 2022 20:25:50 -0000 @@ -827,9 +827,9 @@ ikev2_pld_cert(struct iked *env, struct certid = &msg->msg_parent->msg_cert; if (certid->id_type) { - log_info("%s: multiple cert payloads not supported", + log_debug("%s: multiple cert payloads, ignoring", SPI_SA(sa, __func__)); - return (-1); + return (0); } if ((certid->id_buf = ibuf_new(buf, len)) == NULL) { This patch, applied on top of Tobias' previous one (and a freshly checked out OpenIKED 7.1 codebase) made it finally work: iked -dvv : [...] ca_reload: loaded ca file ca.crt ca_reload: loaded crl file ca.crl ca_reload: <iked "intermediate" CA> ca_reload: <self-signed "root" CA> [...] spi=0xc36581638596ad32: sa_state: INIT -> SA_INIT [...] spi=0xc36581638596ad32: ikev2_pld_cert: multiple cert payloads, ignoring [...] spi=0xc36581638596ad32: sa_state: SA_INIT -> AUTH_REQUEST policy_lookup: peerid <the peer whose certificate was actually signed by iked "intermediate" CA> spi=0xc36581638596ad32: sa_state: AUTH_REQUEST -> AUTH_SUCCESS sa_stateflags: 0x002d -> 0x003d cert,certreq,auth,authvalid,sa (required 0x003b cert,certvalid,auth,authvalid,sa) ikev2_dispatch_cert: peer certificate is valid sa_stateflags: 0x003d -> 0x003f cert,certvalid,certreq,auth,authvalid,sa (required 0x003b cert,certvalid,auth,authvalid,sa) sa_stateok: VALID flags 0x003b, require 0x003b cert,certvalid,auth,authvalid,sa spi=0xc36581638596ad32: sa_state: AUTH_SUCCESS -> VALID [...] As shown in this partial log, the ca.crt file contains both the "root" and the "intermediate" CA certs. On Windows 10 (21H2), the trust store contains both CAs certs as well, along of course with the client certificate, signed by the intermediate CA. I'll let Tobias comment on the fate of the two patches which made it happen, and will run some additional testing in coming days to see if I come upon some regressions. Loïc
