On 2021-03-04, David Newman <dnew...@networktest.com> wrote: > On 3/4/21 12:29 AM, Stuart Henderson wrote: > >> On 2021-03-04, David Newman <dnew...@networktest.com> wrote: >>> Apparently Apple iOS and iPadOS VPN clients now require a subjectAltName >>> in the client cert, not just the CN, to set up IKEv2 VPN tunnels.* The >>> subjectAltName can be the same as the CN; it just has to be present. >> >> Most IKE software has always needed this. (Web browsers also recently-ish >> started needing it too). >> >>> Questions about this: >>> >>> 1. Does the 'ikectl ca <CAname> certificate <hostname> create' command >>> support creation of X.509 certs with a subjectAltName defined in >>> addition to the CN? >>> >>> If so, what's the syntax? >> >> It does this by default. > > Thanks, I hadn't realized that, and should have grep'd the cert for > 'DNS:' before asking. > > And yet, an iOS client initiator still fails with an authentication > error on the iOS side. 'ipsecctl -sa' on the OpenBSD responder looks > fine, with a tunnel established. > > The server and client certs generated by 'ikectl sa' have alt names but > the CA cert does not. > > Does it need one? I suspect an error in iOS VPN configuration, but just > checking.
The CA cert doesn't need a subjectAlternativeName, only server certs (and client certs, if used). > One other thing about the client cert: The CN is for something like > 'iphone.networktest.com', which is an FQDN for which I have not created > a DNS record. > > Again, does it need one? This is for a road-warrior configuration that > will come in from different IP addresses, so I'm unclear what > name/address pair I'd use in the DNS. It's just an identifier and doesn't need an actual DNS record. It might be simpler to start with EAP-MSCHAPv2 then you can at least verify that the server/CA certs are working as expected, and proceed to client certs afterwards..
