TLS: assigning certificates to username
a.cudbardb at freeradius.org
Thu May 5 17:06:41 CEST 2016
> On 5 May 2016, at 10:52, Alan DeKok <aland at deployingradius.com> wrote:
> On May 5, 2016, at 10:22 AM, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:
>> It *may* contain a CN, and that *may* be an NAI.
> Most importantly, it's under the control of the admin who's issuing the certs.
> So... 99% of people use the NAI in the common name.
and i'm 100% sure you're completely wrong :)
> Doing anything else is crazy.
That'd be why RFC 6818 gives an example of common name being the user's full name?
Standard sets of attributes have been defined in the X.500 series of
specifications [X.520]. Implementations of this specification MUST
be prepared to receive the following standard attribute types in
issuer and subject (Section 220.127.116.11) names:
* organizational unit,
* distinguished name qualifier,
* state or province name,
* common name (e.g., "Susan Housley"), and
* serial number.
and RFC 5216 (EAP-TLS) states pretty plainly that:
Where the peer identity represents a host, a subjectAltName of type
dnsName SHOULD be present in the peer certificate. Where the peer
identity represents a user and not a resource, a subjectAltName of
type rfc822Name SHOULD be used, conforming to the grammar for the
Network Access Identifier (NAI) defined in Section 2.1 of [RFC4282].
If a dnsName or rfc822Name are not available, other field types (for
example, a subjectAltName of type ipAddress or
uniformResourceIdentifier) MAY be used.
So in fact I revise my previous statement, if your cert contains an NAI in the CN part of the subject, your system administrator is an idiot.
Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Freeradius-Users