IPsec and certificates

Some quick background. I’m evaluating/testing a RouterOS setup as a replacement for our current firewall(s). One of the things it will need to do is serve our VPN clients, which are all using IPsec. All Windows computers, all authenticating with certificates tied to their TPMs, issued by our internal PKI. The old setup has been working flawlessly for years, so my challenge isn’t creating a working setup, it is translating an already working setup to the MikroTik way of doing things. IPsec being well known for it’s many different implementations each with their own little idiosyncrasies, I didn’t expect it to be completely trivial, but hopefully doable. So far, it’s gone reasonably well. I’m used to working with IPsec as routable interfaces, so policies was a bit of a rub, but that’s just getting used to thinking about it differently.
Where I did run into trouble was with the authentication, and I’m hoping someone might have insights or tips.

First, I was getting errors that it couldn’t process the cert payload from the client. No information about why though. Trying to import the public part of the client certificate to the router yielded no certificate and no errors, just silently failing both from WinBox and the terminal. By trial and error I’ve narrowed it down to the EKU extension in our certificates being marked as critical. Now to be fair, rejecting a certificate if it has a critical extension the implementation doesn’t recognise is exactly what it’s supposed to, that’s how critical should be handled. What I’m not so impressed by is the complete lack of error messages or feedback indicating what the problem was. Also the first time I’ve actually run into an implementation that doesn’t understand the EKU extension. Doubly confusing since when I left the extension in but not marked as critical, the router was reading the EKU and writing it out in the logs when the client connected. So it does understand it. But it also rejects it if marked critical, which it shouldn’t if it understands it?
Does anyone know more about this? Like a specification of acceptable extensions, EKUs, what can and can’t be marked critical? And is there some place I could have coaxed out a meaningful error message when it was refusing the certificate, either from the client or when importing it to the router? Anyone know if the certificate code in RouterOS is based on a well known library like OpenSSL or if it’s all in-house code? A while ago I was running into problems importing a certificate from NordVPN onto another router I’ve been testing at home, but that was fixed when I updated to a newer version. Basically, I get the feeling the whole certificate implementation is kind of fragile or temperamental. Anyone with a lot of experience using certificates with RouterOS willing to share their opinion?

Second, once I had a client certificate, it wouldn’t authenticate. Turns out this part is explained in the wiki, I just missed a detail. What I want to do, is specify a CA certificate under “remote-certificate” on the IPsec identity, and have it match any client using a certificate issued by that CA. Apparently that isn’t possible here. I either have to specify the exact client certificate, or leave it open and accept any certificate whose CA is in the certificate store. The latter being unacceptable the moment I add any public CA to the router.
Has anyone gotten such a setup working on RouterOS, validating certificates from a specific CA? Or accepting any CA and wildcard matching the subject or DNS SAN in the certificate? Or is this just not possible?

Lastly I’m still having trouble with the server certificate, but I suspect that’s a combination of factors. On our current firewall I’ve used both a certificate from our internal PKI, a specific hostname certificate from Buypass Go and a wildcard certificate from Let’s Encrypt as the server certificate. They’ve all worked. On the MikroTik I’ve only gotten the internal PKI issued one to work, the client rejects the others. It drops the connection after the router has accepted it, leaving an active peer and SAs behind. Which sounds like a client side issue at first, but still somehow related to the router when considering the same certificate is accepted by the client when presented by another firewall. Suspect it might be down to the ID_r, but I can’t find any “my-id” that works with the public CA certificates. Any tips on getting that to work with a Windows client?

Sorry about the long post and the rambly, ranty nature of it. Guess I’m fishing for tips, opinions from experienced RouterOS admins and leaving a little feedback for MikroTik all at once. :bulb:

Just quickly answering my own question on the very off chance anyone else has a similar problem and stumbles over this post. RouterOS doesn’t send the certificate chain automatically, it has to be specifically told to do so. Hence internal PKI server certificates were accepted by the client, since we have the internal root and intermediates preloaded on them, as opposed to public intermediates.
My setup was:

/ip ipsec identity
add auth-method=digital-signature certificate=<server-certificate> generate-policy=port-strict match-by=certificate mode-config=example peer=example policy-template-group=example remote-certificate=<client-certificate>

The intermediate has to be added to the certificate parameter:

/ip ipsec identity
add auth-method=digital-signature certificate=<server-certificate>,<server-certificate-ca> generate-policy=port-strict match-by=certificate mode-config=example peer=example policy-template-group=example remote-certificate=<client-certificate>

Ordering seems to matter, like with a chain in a PEM file, so “,” works and “,” doesn’t.
Only thanks to WinBox that I even realised the parameter takes multiple options. The help pages seem very specific about the option taking “a certificate”, singular and with a private key, so I’m not sure if this is the correct way, but it worked and the server now sends the chain as it should.