The IPsec WUI does not seem to be aware of subjectAltName in Certificate Signing Requests (CSRs) as generated certificates do contain an appropriate Common Name (CN), but not the requested SAN. This is a show-stopper when trying to set up an IPsec connection between IPFire and OpenIKED.
Apparently the root cause for this is the OpenSSL configuration @ /etc/openssl/ .
OpenSSL does not simply use the X509.v3 extensions provided in any given CSR, which is why subjectAltNames are missing in the generated certificate. After spending almost an hour on researching, passing SANs to OpenSSL seems to be possible by passing an additional configuration file. We could simply generate one of those on-the-fly, but will be limited to exactly one SAN then as we usually only have a destinations' FQDN. In my opinion, the OpenVPN CGI suffers from the same issue (Erik CC'ed). This OpenSSL bug/behaviour is, in the politest words I can describe it, pain in the ass de luxe. :-(
A solution you could implement is checking the CSR for any SANs. If those exist, you can ask openssl to copy them into the certificate. Since that will fail if there is no SAN available, the check is necessary. You should whitelist SANs only and not copy all other extensions, too.