All certificates, as you plan to use the client ones not only to authenticate them but also to identify them. Only Mikrotik’s own private key.
Indeed, it’s just the most secure way and I did not know that XCA was an application you run in your home lab - the description of the use case was “one router at home to which I connect while travelling”. That did not sound like a home lab with multiple ICAs as you describe now ![]()
Indeed, but it’s not the case any more if the MT router (or anything else) is not generating them (including the private keys) but only signing them. Anyway, it does not make any difference in your case as you do not send the private keys outside your LAN.
I don’t know any device/OS that would care whether some certifcates came in a single common file or in separate ones; in either case they store them separately in the certificate stores. Exporting multiple certificates into a single file only makes the workflow more comfortable, as in “less clicking is required”.
As far as I know, Mikrotik would not import a private key that is not protected by a passphrase, and it only supports PEM (base64) format or PKCS#12 (binary) one. If you had in mind exporting from the Mikrotik (I don’t think so so just for completeness), if you choose type=pem, you’ll get two files, .crt with the certificate being exported itself and .key with the private key to that certificate. If you choose type=pkcs12, it will export the certificate it was asked to export, its private key, and its complete chain of trust (if available) into a single file. If you do not provide the passphrase, it will omit exporting the private key in either format.
That is indeed the best way - the least amount of clicking is required.
Regarding CRL, as already said I am not an expert, so I let someone else respond.
I share your excitement about this example, it is unusually bad.