It was reported [1] that wpa_supplicant does not properly check certificate subject name, which might lead to "man in the middle" attack.
Relevant part of the original report:
...

wpa_supplicant, linked against openssl performs this check:

    if (depth == 0 && match && os_strstr(buf, match) == NULL) {
        wpa_printf(MSG_WARNING, "TLS: Subject '%s' did not "
               "match with '%s'", buf, match);
        preverify_ok = 0;
        openssl_tls_fail_event(conn, err_cert, err, depth, buf,
                       "Subject mismatch",
                       TLS_FAIL_SUBJECT_MISMATCH);
    }

strstr() is vulnerable to extension attack, for instance, one would like to
match on /CN=wireless.nikhef.nl, but explicitly not match on
wireless.nikhef.nl.honestachmed.tr. There is no way to implement a secure
EAP-TTLS/PEAP configuration using public certificates this way.

When linked against GnuTLS, the problem is even worse:

      if (i == 0) {
            /* TODO: validate subject_match and altsubject_match */
        }

Now, it is current best practice to run EAP-TTLS/PEAP with public certificates,
because on Windows, this automatically pins the CN and CA from the certificate.
...

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1178263