After playing around for a little while I made an interesting discovery that I have not been able to find an explanation to...
FreeRadius EAP Settings has a check box "Check Client Certificate CN" ("When enabled, the Common Name of the client certificate must match the username set in 'FreeRADIUS > Users'").
When using a certificate to authenticate, it seems to me that the certificate CN would NOT be checked against the Users database. Regardless of the users I have added, I always get error messages like below when I have that check box checked:
Nov 30 17:33:15 radiusd 1388 tls: Certificate CN (K14) does not match specified value (host/K14)!
Nov 30 17:33:15 radiusd 1388 tls: TLS_accept: Error in error
Nov 30 17:33:15 radiusd 1388 (4) Login incorrect (Failed retrieving values required to evaluate condition): [host/K14/<via Auth-Type = eap>] (from client SW21 port 2 cli xx-xx-xx-xx-xx-xx) host/K14 -
So far I have not been able to figure how to effectively enable the client cert. CN check.
I wonder if this is also some stupid beginner's mistake, or is this something else?
And where does this "host/" prefix come from? At least it seems to be independent of the 802.1X authentication mode in the client (User vs. computer authentication)...
When the check box is not checked, authentication with the certificate succeeds without any problems.
FWIW, Radius debug log reveals:
(2) files: users: Matched entry host/K14 at line 2
(2) [files] = ok
...so it seems that it indeed performs the check against user database where I have an entry "host/K14".
Run acme package on FW1 (I assume it's a CARP cluster with syncing?) and let it create a certificate for both names (fw1.xxx AND fw2.xxx). When it's done, select the cert for the webui. Then login to FW2 and select it, too, as certificates get synchronized automatically (if selected) to the secondary. There choose the same certificate as WebUI cert and be done :)
Just check that you configure the acme service on fw1 to restart its own webserver after renewal AND via remote the service on fw2 (see the help for this)!
Where are you getting your cert from? Your going to have to give us more details if you want anyone to be able to figure out what your doing wrong.
For what possible reason would you want to use a wildcard cert for the webgui? How many possible fqdn/IPs could you point to the web gui?
The web gui should be accessed by limited number of users. Create as cert with your own ca, have the users that will access it trust your ca. Put in whatever SANs you want to access it by. Done - set the cert to be good for 10 years. Never have to deal with this issue again.