On 3/4/21 12:29 AM, Stuart Henderson wrote: > On 2021-03-04, David Newman <[email protected]> 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. 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. Thanks again. dn > >> 2. Can a separate standalone CA just create the certs with the necessary >> SAN fields? > > Yes. > >> Is it as easy as just dropping the root cert, the client >> certs, and keys in these respective directories? >> >> /etc/iked/ca >> /etc/iked/certs >> /etc/iked/private >> >> If not, what else is needed? Thanks! > > You don't need anything from the client (certificates or keys) on the server, > just the CA certificate, the server certificate, and the server private key. > > This is fine if the certificates are signed directly by the CA (as would > often be the case if using your own standalone CA) but I haven't been able > to get this working for certs signed by an intermediate 'sub CA' as is > done for most commercial CAs. > >
