No one can answer this better than our awesome technical publication team. I've extracted this from our help file to help explain. In short- you should only need this when using TLS without a user database.
TLS is more arduous because of the need to generate and install unique client certificates, as well as a CA certificate, on all wireless clients, and a server and CA certificate on the RADIUS authentication server. With PEAP and TTLS, the supplicants only need to install the same CA certificate, which they use to validate the server certificate that the device authentication server uses. However, TLS does offer one feature that the other types of authentication do not: you can just use certificates to authenticate users and completely forego the use of a database. To do this, the users must submit the same name in their EAP-Response/Identity frames as the common name that appears in their client certificates, and you must configure the Aerohive RADIUS server to compare these two names by selecting the Check the common name in the certificate against the user for TLS authentication check box.
For an Aerohive RADIUS server to accept a client certificate, the AerohiveRADIUS server uses the private key for the issuing CA certificate to validate the digital signature on the client certificate. In addition to this check, you can configure theAerohive RADIUS server to compare the user name that appears in the EAP-Response/Identity packet—and then as one of the attributes in the RADIUS-Access-Request packet that the authenticator forwards to the authentication server—against the CN (common name) in the client certificate. When a RADIUS supplicant/EAP client (wireless client) sends an EAP-Identity/Response packet to a RADIUS authenticator/EAP server (device to which the client is associated), it includes a user name in plaintext in the Type-Data field. If this name matches the CN in the client certificate, the authentication check passes.
Using this approach, you might decide that you do not need a database of user accounts to authenticate users. Users can be authenticated by validating their client certificates and confirming that they belong to the people submitting them. Although you do not need to maintain a user database with this approach, keep in mind that you would need to maintain a CRL (certificate revocation list) to track revoked certificates. By default, checking the CN in submitted client certificates is disabled.