Hello everybody,
I wanted to get ready to use a routerboard device as a STA in a 3rd party WiFi network that requires clients to authentify themselves to the infrastructure using certificates.
So the logical first step was to create my own AP with mode=dynamic-keys authentication-types=wpa2-eap unicast-ciphers=aes-ccm group-ciphers=aes-ccm eap-methods=eap-tls tls-mode=verify-certificate tls-certificate=server-test in its security profile and try to connect the STA to it.
As I was getting wireless,info 74:4D:28:12:37:BA@wlan2: disconnected, 802.1x authentication failed at both the STA and the AP, I've decided to simplify the task by setting tls-mode to dont-verify-certificate, which means that the AP presents its own certificate to the STA, but doesn't request a certificate from the STA. The result was the same - 802.1x authentication failed logged at both the AP and the STA.
So I've created a new AP certificate with both the common-name and subject-alt-name=DNS: matching the ssid of the interface, but still the same outcome.
Out of desperation (it should work with CAPsMAN too, shouldn't it), I've used the /system identity name value of the AP as the certificate's common-name and subject-alt-name=DNS:, still the same outcome.
All the certificates (the three different ones for the AP and the one for the STA) have been signed by the same CA, both the AP and the STA have that CA's certificate installed. The AP certificates have both tls-server and tls-client in the key-usage list.
If I set tls-mode=no-certificates, it works fine.
So my question, which neither the documentation nor the log answers, is - what are the requirements of the RouterOS acting as STA (and also of RouterOS acting as an AP for the later stage) on the contents of the other party's certificate? Or maybe the cipher suites used by contemporary RouterOS versions when generating the certificate are not the same ones required by those same versions of RouterOS to verify the certificate when acting as a STA?
There is a topic at Serverfault by forum user @LinuxEngineer which deals with this subject, except that it doesn't use Mikrotik as a STA. Microsoft states that the AP certificate for this purpose must have the AP's FQDN as the subject-alt-name but I have problems to understand how the STA can verify any relationship of the FQDN to the AP during initial authentification of the STA to the network while it has no IP connectivity yet.
Windows 10 are happy with the CA certificate and the server certificate provided by the AP even though its CN and SAN do not match the SSID, and it is enough for them to connect to such AP if the CA is installed in their Trusted Root CAs certificate store. It even doesn't matter that the Client Hello sent by Windows indicates TLS 1.2 whereas the AP's messages are TLS 1.0. So it's the TLS client in the Mikrotik STA that is picky.
Tested with dont-verify-certificate so far, i.e. STA certificate wasn't required.