--On Thursday, January 31, 2008 05:42:50 PM +0100 "Reimer Karlsen-Masur,
DFN-CERT" <[EMAIL PROTECTED]> wrote:
If the "Microsoft Smartcard Logon" extendedKeyUsage *is part* of your
client certificates they might not work with Windows build-in supplicant.
This is not surprising, if that is the only EKU in the cert. In fact, in
that situation, no correct server should accept the certificate for
EAP-TLS, because the presence of any EKU means the certificate may _only_
be used for listed usages, and EAP-TLS is not smartcard-based logon. If
you want to use a certificate for both purposes, then it must have both
id-kp-ms-sc-logon and one of anyExtendedKeyUsage (2.5.29.37.0) or [sigh]
id-kp-clientAuth (1.3.6.1.5.5.7.3.2). Unfortunately, RFC2716 does not
discuss the details of certificate validation, but the rules for handling
extended key usages are the same for all uses of PKIX; for details, see
RFC3280 section 4.2.1.13. The replacement for RFC2716 is
draft-simon-emu-rfc2716bis-13.txt, which was just approved as a Proposed
Standard in the past week. It does discuss the details of certificate
validation for EAP-TLS, in section 5.3.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Carnegie Mellon University - Pittsburgh, PA
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
