Support for check_cert_subjectAltName?
Hi all, When using client certificates in EAP-TLS, the check_cert_cn option exists that allows you to check that the username matches the CN. Is there a corresponding option somewhere that will allow you to verify the User-Name against the subjectAltName instead? Regards, Graham --
Graham Leggett wrote:
When using client certificates in EAP-TLS, the check_cert_cn option exists that allows you to check that the username matches the CN. Is there a corresponding option somewhere that will allow you to verify the User-Name against the subjectAltName instead?
In the latest version of the server, see raddb/sites-available/default. Look for TLS-Cert Alan DeKok.
On 08 Jan 2012, at 5:01 PM, Alan DeKok wrote:
When using client certificates in EAP-TLS, the check_cert_cn option exists that allows you to check that the username matches the CN. Is there a corresponding option somewhere that will allow you to verify the User-Name against the subjectAltName instead?
In the latest version of the server, see raddb/sites-available/default. Look for TLS-Cert
That wasn't quite what I was after, but rather a generic way to ensure the User-Name matches either dnsName or rfc822Name in the subjectAltName, depending on whether the peer was a host or a person. Turned out the patch to implement this was simple, for freeradius-server-master: And this is the same patch, backported to v2.1.x: It adds a check_user_san option, which some googling showed past people have asked about. Regards, Graham --
Graham Leggett wrote:
That wasn't quite what I was after, but rather a generic way to ensure the User-Name matches either dnsName or rfc822Name in the subjectAltName, depending on whether the peer was a host or a person.
Turned out the patch to implement this was simple, for freeradius-server-master:
I'd prefer a patch which creates an attribute, just like the TLS-Cert-* attributes. The reason is that policies can be created by the administrator. A hard-coded check is likely more code and less flexible. Alan DeKok.
On 01/08/2012 08:28 PM, Alan DeKok wrote:
Turned out the patch to implement this was simple, for freeradius-server-master:
I'd prefer a patch which creates an attribute, just like the TLS-Cert-* attributes. The reason is that policies can be created by the administrator. A hard-coded check is likely more code and less flexible.
Isn't there a problem with that approach though? Namely, that the TLS-* attributes aren't available in the "authorize" section (because the eap module, and all the EAP methods, do their with in "authenticate"). But in post-auth, turning an accept into a reject is fraught, and bad practice? This comes up occasionally when people want to check the TLS-* attributes and act on them (as opposed to logging them). Or am I missing something? We don't use EAP-TLS so it's entirely possible.
Phil Mayers wrote:
Isn't there a problem with that approach though? Namely, that the TLS-* attributes aren't available in the "authorize" section (because the eap module, and all the EAP methods, do their with in "authenticate").
Yes.
But in post-auth, turning an accept into a reject is fraught, and bad practice?
The certs can be checked in the "authenticate" section, too.
This comes up occasionally when people want to check the TLS-* attributes and act on them (as opposed to logging them).
The rlm_eap code could be modified to look up the handler in the authorize section. If found, the certs could be added to the request. It's probably not a lot of code, and could be useful for 3.0. Alan DeKok.
participants (3)
-
Alan DeKok -
Graham Leggett -
Phil Mayers