Fri Oct 29, 2021 2:14 pm
Mikrotik needs to find tls-client usage in the certificate presented by a Windows initiator. The Mikrotik manual says that for Mikrotik acting as a responder, it is enough that tls-server usage is set in its own certificate it presents to Windows initiators. As I am not sure whether Windows won't come with more requirements in future, I generate the certificates for Mikrotik responders also with ipsec-end-system and ipsec-tunnel usages.
Plus I don't know how the Latvian localization team of Microsoft handles that, but in my language, the key usage names presented in Microsoft certificate-related tools are localized in a confusing way, replacing "ipsec" by mere "security", so you may have to investigate a bit.
Regarding confusing - if you know how it works, it's not so confusing.
The device that proves its identity to another device using a certificate must have the private key to that certificate. The proper way is to generate a certificate signing request on that device, deliver the request to the certification authority, get it signed, and deliver the signed certificate back to the requesting device. As the private key never leaves the requesting device in this case, you can send the CSR and the signed certificate using open channels without compromising the security. But creating a CSR on a Windows machine is not an easy procedure; maybe it is easier for machines in a domain.
The device that verifies other device's identity using a certificate must trust the root certification authority of the chain of trust of the certificate being presented, i.e. the certificate of that root CA must be available in the certificate store of the verifying device.
Both the responder and the initiator work in both roles - each of them authenticates itself to the other one by presenting its own certificate, and checks the other one's authenticity by checking the certificate it has got from it against the locally stored root CA's certificate.
So unless you need to use the initiator's certificate as an identifier to find an /ip ipsec identity record, you need your own certificate and private key, and the root CA certificate that has signed the other one's certificate.
If you use the initiator's certificate as an identifier, you must have a local copy of it on the Mikrotik, of course without the private key.
And if you want to be able to deny access to stolen initiator devices by revoking their certificates before they expire, you have to make the Certificate Revocation List work. I've posted on that topic here on the forum recently; since in your case, the CA is not the Mikrotik responder itself, you have to make the CRL accessible using plain http on the actual CA so that the responder could periodically download it from there.