EAP-TLS separate client cert per ssid FR v3.0.17
Good morning, I've been using FR for a number of years, with some "approved" and some "less than approved" configuration edits, but mostly with straightforward single CA, single client cert, EAP-TLS configuration, which has been outstanding. I have other configs where I add in EAP-TTLS or do mac auth, however what I would like to try next is EAP-TLS with multiple SSIDs, where there is a single separate cert per SSID. Please note that the certs will have different issue dates, and may change per freeradius instance, so chaining client certs into a single file and trying to attack some cert property is not the preferred path, unless it is the ONLY path. It would make cert management difficult to say the least. I have reviewed documentation to the best of my ability, however a lot of the searching (including on netrad) turned up solutions that were for prior versions of FR, with results for FR2 being most popular. I also see a number of posts/responses that ask if it can be done, where the response is "yes lot of people do it" - but there is no actual instruction on how to do so. There are also snippets of earlier versions of FR3 prior the "tls-common" update, which attempting those breaks my current version, as one would expect. (As noted in subject, my FR version is 3.0.17) So far, I have tried to replicate the eap module (mods-enabled/eap -> renaming both file and module) with no success as FR complains about my copied eap modules not being compiled (cannot fine {name}.so) - which I fully understand where that is coming from as a dev myself I'm not really interested in re-writing the eap module source just to accommodate this particular forced practice, of which I'm sure Alan would agree (just getting that taken care of early in the conversation). Is there an example doc that could illustrate how to "properly" instruct the eap module to test only ClientCertA against SSID-A and only ClientCertB against ClientCertB? A test of ClientCertB attempting to associate on SSID-A must fail. I would like to retain the ability to also pre-test mac auth on some SSIDs before eap as I currently do in my default site (ie in sites-enabled/default) Currently I test against SSID and mac in my site/server: (inside authorize) if(Eap-Message) { # EAP-TLS with certificate, no u/p, no mac filter. if (Aruba-Essid-Name == "ALANSFREEWIFI") { eap } # EAP-TLS with certificate, no u/p, WITH mac filter. elsif (Aruba-Essid-Name == "ALANSPROTECTEDNETWORK") { if (Calling-Station-Id == "aabbccddeeff") { eap } } etc... and the eap module is currently stock aside from the certificate details; however in the above version, the same cert is on all clients - and that's not my optimal deployment choice. Moving forward, should this test happen in the virt-server (ie in sites-enabled/default), or does the (mods-enabled/eap) get extended to test against the ssid and mac? Kindest regards, Ted.
Hi, The easiest way is to just use inland, change whichever ssid you want to to call eg 'eap2' instead 'eap' and copy current eap module configuration file to a new eap2 configuration file and edit it so that it's known as eap2 . Then edit eap2 to provide/use new CA/cert/whatever alan On Sat, 30 Apr 2022, 15:02 thyde rndstudio.com, <thyde@rndstudio.com> wrote:
Good morning, I've been using FR for a number of years, with some "approved" and some "less than approved" configuration edits, but mostly with straightforward single CA, single client cert, EAP-TLS configuration, which has been outstanding. I have other configs where I add in EAP-TTLS or do mac auth, however what I would like to try next is EAP-TLS with multiple SSIDs, where there is a single separate cert per SSID.
Please note that the certs will have different issue dates, and may change per freeradius instance, so chaining client certs into a single file and trying to attack some cert property is not the preferred path, unless it is the ONLY path. It would make cert management difficult to say the least.
I have reviewed documentation to the best of my ability, however a lot of the searching (including on netrad) turned up solutions that were for prior versions of FR, with results for FR2 being most popular. I also see a number of posts/responses that ask if it can be done, where the response is "yes lot of people do it" - but there is no actual instruction on how to do so. There are also snippets of earlier versions of FR3 prior the "tls-common" update, which attempting those breaks my current version, as one would expect. (As noted in subject, my FR version is 3.0.17)
So far, I have tried to replicate the eap module (mods-enabled/eap -> renaming both file and module) with no success as FR complains about my copied eap modules not being compiled (cannot fine {name}.so) - which I fully understand where that is coming from as a dev myself I'm not really interested in re-writing the eap module source just to accommodate this particular forced practice, of which I'm sure Alan would agree (just getting that taken care of early in the conversation).
Is there an example doc that could illustrate how to "properly" instruct the eap module to test only ClientCertA against SSID-A and only ClientCertB against ClientCertB? A test of ClientCertB attempting to associate on SSID-A must fail.
I would like to retain the ability to also pre-test mac auth on some SSIDs before eap as I currently do in my default site (ie in sites-enabled/default) Currently I test against SSID and mac in my site/server: (inside authorize)
if(Eap-Message) {
# EAP-TLS with certificate, no u/p, no mac filter. if (Aruba-Essid-Name == "ALANSFREEWIFI") { eap } # EAP-TLS with certificate, no u/p, WITH mac filter. elsif (Aruba-Essid-Name == "ALANSPROTECTEDNETWORK") { if (Calling-Station-Id == "aabbccddeeff") { eap }
} etc...
and the eap module is currently stock aside from the certificate details; however in the above version, the same cert is on all clients - and that's not my optimal deployment choice.
Moving forward, should this test happen in the virt-server (ie in sites-enabled/default), or does the (mods-enabled/eap) get extended to test against the ssid and mac?
Kindest regards, Ted. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 30, 2022, at 4:02 PM, thyde rndstudio.com <thyde@rndstudio.com> wrote:
I've been using FR for a number of years, with some "approved" and some "less than approved" configuration edits, but mostly with straightforward single CA, single client cert, EAP-TLS configuration, which has been outstanding. I have other configs where I add in EAP-TTLS or do mac auth, however what I would like to try next is EAP-TLS with multiple SSIDs, where there is a single separate cert per SSID.
That should be relatively easy to do. Sometimes tricky, but not complicated.
Please note that the certs will have different issue dates, and may change per freeradius instance, so chaining client certs into a single file and trying to attack some cert property is not the preferred path, unless it is the ONLY path. It would make cert management difficult to say the least.
That's fine.
I have reviewed documentation to the best of my ability, however a lot of the searching (including on netrad) turned up solutions that were for prior versions of FR, with results for FR2 being most popular. I also see a number of posts/responses that ask if it can be done, where the response is "yes lot of people do it" - but there is no actual instruction on how to do so. There are also snippets of earlier versions of FR3 prior the "tls-common" update, which attempting those breaks my current version, as one would expect. (As noted in subject, my FR version is 3.0.17)
I would suggest upgrading to 3.2.0. There are a number of fixes, include for TLS 1.3.
So far, I have tried to replicate the eap module (mods-enabled/eap -> renaming both file and module) with no success as FR complains about my copied eap modules not being compiled (cannot fine {name}.so) - which I fully understand where that is coming from as a dev myself I'm not really interested in re-writing the eap module source just to accommodate this particular forced practice, of which I'm sure Alan would agree (just getting that taken care of early in the conversation).
You can't just copy the whole configuration file and rename "eap", because the server needs to know which binary (rlm_foo.so) to load. There are examples of configuring multiple instances of the modules, and documentation for that. See mods-available/README.rst. I'm not sure where else to put the documentation, TBH. Putting it in the same directory as the module configuration seems logical. Where else should it be?
Is there an example doc that could illustrate how to "properly" instruct the eap module to test only ClientCertA against SSID-A and only ClientCertB against ClientCertB? A test of ClientCertB attempting to associate on SSID-A must fail.
Create different EAP module configurations: eap eap_ssid1 { ... copy all of the "eap" configuration, and change the certificate filenames } eap eap_ssid2 { ... etc. } This says "use the rlm_eap.so" module, but this particular instance of the configuration is "eap_ssid1" or "eap_ssid2"
I would like to retain the ability to also pre-test mac auth on some SSIDs before eap as I currently do in my default site (ie in sites-enabled/default) Currently I test against SSID and mac in my site/server: (inside authorize)
if(Eap-Message) {
# EAP-TLS with certificate, no u/p, no mac filter. if (Aruba-Essid-Name == "ALANSFREEWIFI") { eap
eap_ssid1
} # EAP-TLS with certificate, no u/p, WITH mac filter. elsif (Aruba-Essid-Name == "ALANSPROTECTEDNETWORK") { if (Calling-Station-Id == "aabbccddeeff") { eap
eap_ssid2
Moving forward, should this test happen in the virt-server (ie in sites-enabled/default),
Yes.
or does the (mods-enabled/eap) get extended to test against the ssid and mac?
All of the documentations says you can't put unlang if / then / else statements into module configurations. And if you try doing it, the server won't start, and will complain that you can't put unlang statements into module configurations. Alan DeKok
participants (3)
-
Alan Buxey -
Alan DeKok -
thyde rndstudio.com