Or am missing something and it's possible to setup different identities using digital signature as authentication on the same peer?
I would say you do miss the idea.
To
verify the authenticity of the remote peer using the certificate it provides, you need to install the certificate of the issuing authority of that peer's certificate into your certificate store. You can have many CA certificates installed in your certificate store, so that's no issue. If the issuing CA is not the root CA, you need to install the complete chain of trust from the issuing CA up to the root CA.
You don't need to indicate which CA certificate to use for a given
identity, the ID of the CA certificate is found in the own certificate provided by the remote peer. But if you want to lookup the
/ip ipsec identity row up to the remote peer's certificate, you must also have that peer's own certificate itself in your certificate store, and set it as
remote-certificate property of that row. If you lookup the
/ip ipsec identity row up to client's ID (fqdn, IP address, ...), you don't need to have the client's certificate in your certificate store as it will send it in the initial message exchange.
To
authenticate yourself to the remote peer, you need your own certificate (with a private key) signed by some CA which the remote peer trusts (and in this case I am not sure whether you need to have the complete chain of trust on your side as well). And here, you have to indicate which of your several own certificates you will use for to authenticate yourself to the remote peer by setting the
certificate property of a row.
A peer with a single particular (remote)
address can have just a single
identity row assigned to it, and only such peers may be initiators. Peers with a wider subnet in
address can only be responders, and these can have multiple
identity rows attached, from which the stack chooses based on the received ID or certificate. Which "field" will be used may differ among
identity rows attached to the same responder peer.
