There is currently no "better way" in terms that RouterOS would build the list of certificates (chain of trust) for an ip ipsec identity item automatically like it does for the https server, but there definitely is a "better way" in terms that you can use a script to build the list.
I don't know which version of RouterOS you are running. It wasn't always like that, but already since some versions ago, RouterOS has been installing the complete chain of trust, i.e. the endpoint certificate itself, the intermediate CA certificate(s), and the root CA certificate(s).
The thing is that ISRG keeps "improving" their chain of trust, gradually introducing more root CAs, but to facilitate the slow pace of updates of operating systems, it cross-signs them using the older root CAs. So for a current endpoint RSA certificate, the complete chain of trust consists of
- the issued endpoint certificate signed by YRn intermediate CA
- the YRn intermediate CA certificate signed by Root YR CA
- the Root YR CA certificate, both self-signed and cross-signed by ISRG Root X1
- optionally, the ISRG Root X1
While the Root YR one will eventually make it to certificate stores of operating systems with active support, its cross-signing with ISRG Root X1 facilitates its treatment as a mere intermediate CA on systems that do not have it in their list of trusted CA certificates yet.
If you take a closer look at the certificate data shown by RouterOS, you'll see that the akid (authority key id) parameter of a certificate matches the skid (subject key identifier) of the certificate of the authority that has signed it. So the script builds the list (array) for the ip ipsec identity item by starting from the endpoint certificate itself ([ip service get www-ssl certificate]) and then crawling the certificate store recursively, using [/certificate find where skid=[get $current akid]] to find the next element, until it finds a certificate whose akid is empty; that one does not need to be added to the list/array as the recipient of the AUTH message must have it in its trusted root CA store.
What makes the script a tiny bit more complex is that recent versions of RouterOS also contain preinstalled certificates, and the lookup by skid (or by any other property) has to be done separately for the manually installed certificates and for the pre-installed ones.
An unpleasant moment is that the embedded ACME supplicant of RouterOS sends certificate renewal requests autonomously and removes the old endpoint certificate from the store once it installs the new one, so you have to either use a scheduler to check every minute that the first certificate in the list still exists and recreate the list if it doesn't, or be faster than RouterOS by scheduling the renewal the night before RouterOS would do it itself.
Loosely related, since you have mentioned the embedded VPN client of Windows: the strongest modp algorithm you can choose using Powershell or by editing the RAS file is modp2048, which some regulations claim not to be secure enough; to use ECP (256 or 384), the Windows VPN client requires that the endpoint certificate of the IKEv2 responder (server) was an ECDSA one. Whereas Let's Encrypt can issue an ECDSA certificate, the ACME supplicant embedded in RouterOS can only request an RSA one as of writing this. So if you want an ECDSA one, you have to run certbot in a container and use even more scripting to extract the certificate, key, and intermediate certificates from the container mounts and import them to the certificate store of RouterOS.