Can I make strongSwan accept any certificate as long as it is only signed by a specific CA?

Using a swanctl config, is there a way to make strongSwan accept any certificate for an IKEv2 connection as long as it is signed by a specific CA? What I mean is, without having to install the public keys of all possible certs on the server, after all the certs are sent by the client in reply to a cert request sent by stongSwan.

I tried something like this:

    local {
        auth = pubkey
        certs = server.pem
        id = fqdn:strongSwan
    }
    
    remote {
        auth = pubkey
        cacerts = my_ca.pem                     
        id = fqdn:cert                                              
    }

But that doesn't seem to do the trick (and yes, the client did send cert as ID). I also tried id = %any and made the client sent the cert identifier but that makes no difference at all.

The sent certs definitely verify with the CA cert in my_ca.pem and swanctl --list-certs shows the server and the CA cert, so the files are found by strongSwan. Still I get no trusted RSA public key found for ... whatever the identifier was.

The idea is that whatever the client sends as cert is totally fine, as long as it has been signed by my_ca.pem. So a new client just needs to send a certificate signing request, gets their cert signed and can use VPN at once, without any change to the VPN config and without having to place the cert on the VPN server first.

Update 1

Here's a log excerpt (I cannot post raw logs because I must not expose IP addresses, company names or user cert details here):

charon-systemd[31259]: verifying message structure
charon-systemd[31259]: found payload of type NOTIFY
charon-systemd[31259]: found payload of type NOTIFY
charon-systemd[31259]: found payload of type NOTIFY
charon-systemd[31259]: found payload of type NOTIFY
charon-systemd[31259]: found payload of type AUTH
charon-systemd[31259]: found payload of type ID_INITIATOR
charon-systemd[31259]: found payload of type CERTIFICATE
charon-systemd[31259]: found payload of type ID_RESPONDER
charon-systemd[31259]: found payload of type SECURITY_ASSOCIATION
charon-systemd[31259]: found payload of type TS_INITIATOR
charon-systemd[31259]: found payload of type TS_RESPONDER
charon-systemd[31259]: found payload of type CONFIGURATION
charon-systemd[31259]: parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) IDr AUTH CPRQ(ADDR MASK DHCP DNS ADDR6 DHCP6 DNS6 DOMAIN) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr N(MOBIKE_SUP) ]
charon-systemd[31259]: received end entity cert "E=<user-email>, CN=<user-name>"
charon-systemd[31259]: looking for peer configs matching <serverIP>[strongSwan]..<clientIP>[cert]
charon-systemd[31259]: selected peer config 'cert'
charon-systemd[31259]: IDx' => 8 bytes @ 0x7ffa369a2970
     0: 02 00 00 00 63 65 72 74                          ....cert
charon-systemd[31259]: SK_p => 32 bytes @ 0x7ff9fc0126d0
     0: B4 36 B4 D5 CE 09 CE 98 FD 41 75 35 45 9E AD 98  .6.......Au5E...
    16: DA BF D3 EB 4C 39 C0 46 5A 23 E1 A0 EB 85 05 6B  ....L9.FZ#.....k
charon-systemd[31259]: octets = message + nonce + prf(Sk_px, IDx') => 668 bytes @ 0x7ffa1400eac0
     0: 94 83 EA 26 E3 16 36 8D 00 00 00 00 00 00 00 00
    <entire packet follows below>
charon-systemd[31259]: no trusted RSA public key found for 'cert'

<user-email> and <user-name> show the mail and name from the user cert, so the client has sent the user cert, otherwise how would strongSwan know any of that? <serverIP> and <clientIP> are also the correct IP addresses involved.

Upadate 2

I also tried to change the config to id = %any on the server side and then on the client side I send E=<user-email>, CN=<user-name> as id, which matches exactly the values as found in the certificate. But then the log says:

charon-systemd[31978]: no trusted RSA public key found for 'E=<user-email>, CN=<user>'

One thing I noticed that the user certs do not have a SAN (Subject Alternative Name). So far those certs have been used for OpenVPN connections and for SSTP connections and they worked fine for both purposes. I just really want to get rid of OpenVPN/SSTP as I consider both to be poor VPN protocols and their performance is a joke compared to the throughput I get with IPsec and strongSwan.

After a whole day of trial and error, it turns out that the user certificates indeed requires a subject alternative name (SAN), which is the user e-mail address in that case and the identifier must be %any in the configuration and the identifier the client sends must match the SAN (identifier type seems to be ignored, only the string value is relevant).

Apparently strongSwan builds a list of all local certificates configured, adds all certificates clients send to that list as well (RFC says a client can send at least up to 4 different certs) and then searches that list for any certificate whose SAN matches the sent identifier. Certificates without a SAN can never match at all and are always skipped during that search. The last part was the problem as none of our user certs has a SAN value to begin with.

strongswan seems to have the option:

left|rightca = <issuer dn> | %same

the distinguished name of a certificate authority which is required to lie in the trust path going from the
left|right participant's certificate up to the root certification authority.
%same means that the value configured for the other participant should be reused.

https://wiki.strongswan.org/projects/strongswan/wiki/connsection

I would go for strongswan config directly and abandon swanctl in that case