Freeradius and EAP_TLS Problem:

[John Dennis]

On 01/23/2013 04:32 AM, Armin Maier wrote:
> Hello!
> I have been using Windows 7, Freeradius 2.1.10 from Debian Squeeze, HP
> MSM710 WLAN controller and EAP_TLS Computer Certificate Authentication
> for a log time and worked perfect. I used Certificates created on the
> Debian server by openssl including the extensions for Client
> Authentication and Server Authentication.
> Now we want to activate port security on our physical switches and use
> the same radius server, so we installed a Windows Enterprise Root CA for
> autoenrollment of the Client and server certificates. I also created an
> RAS IAS Certificate for the Radius Server and installed them, they are
> loaded without any problems, but authentication of the Windows 7 client
> do not work anymore.
>
> I searched the internet for a compareable setup but i cannot find any
> hints for using Microsoft Enterprise CA with freeradius server, may
> everywhere else it works like a charm :) , but cannot believe it!
>
> So my first question, does someone use Microsoft Enterprise CA
> Certificates with freeradius in a working environment, and o i have to
> regard something special?
>
> Running "freeradius -X" gives me the following errors:
>
> ...
> Found Auth-Type = EAP
> # Executing group from file /etc/freeradius/sites-enabled/default
> +- entering group authenticate {...}
> [eap] Request found, released from the list
> [eap] EAP/tls
> [eap] processing type tls
> [tls] Authenticate
> [tls] processing EAP-TLS
>     TLS Length 95
> [tls] Length Included
> [tls] eaptls_verify returned 11
> [tls]     (other): before/accept initialization
> [tls]     TLS_accept: before/accept initialization
> [tls] <<< TLS 1.0 Handshake [length 005a], ClientHello
> [tls]     TLS_accept: SSLv3 read client hello A
> [tls] >>> TLS 1.0 Handshake [length 0031], ServerHello
> [tls]     TLS_accept: SSLv3 write server hello A
> [tls] >>> TLS 1.0 Handshake [length 08d7], Certificate
> [tls]     TLS_accept: SSLv3 write certificate A
> [tls] >>> TLS 1.0 Handshake [length 0062], CertificateRequest
> [tls]     TLS_accept: SSLv3 write certificate request A
> [tls]     TLS_accept: SSLv3 flush data
> [tls]     TLS_accept: Need to read more data: SSLv3 read client
> certificate A
> In SSL Handshake Phase
> In SSL Accept mode
> [tls] eaptls_process returned 13
> ++[eap] returns handled
> ...
>
>
> I updated to Debian wheezy to get a newer freeradius version, but
> nothing changed.

It's not likely related to FreeRADIUS, the FreeRADIUS server for the 
most part hands off the SSL processing to the openssl library.

> The Radius Server Certificate include the following Attribute (output of
> "openssl x509 -text -in <cert> -noout"):
>

It's not likely related to the server cert either, the debug shows the 
problem is occurring reading the client cert during the ssl handshake.

> The Client Certificates include the following Attributes:
>
> Key usage:    Digital Signature, Key Encipherment (a0)
> Enhanded Key Usage:    Client Authentication (1.3.6.1.5.5.7.3.2)
>
> The client attributes also include
> - Authority Information Access
> - CRL Distribution Points
> - Certificate Template Information
> which have very long values with special caracters like _%/=:?, may this
> be a problem?

Here is what I think is going on. First observe that openssl is 
complaining it needs to read more data from the client cert. That means 
it's confused about the contents of the client cert. It appears as if 
you had trouble dumping the contents of the client cert using the 
openssl x509 command as well. That suggests there are two possibilities. 
Recall that certs are binary encoded data (ASN.1 DER), that encoding 
includes information about the length of the data items in the binary 
data stream. The first possibility is that openssl is not decoding the 
cert correctly and is getting confused over length of items in the cert 
and what they represent. This is supported by the fact it was expecting 
more data and your attempt at dumping the cert seemed to produce 
garbage. The second possibility is that the cert itself is corrupt.

Did you upgrade your openssl library recently?

I would try using an alternate crypto implementation to dump the cleint 
cert and see if you get more reasonable output. The two other popular 
crypto implementations are NSS and GnuTLS. If those implementations 
correctly decode the cert then your problem is almost certainly your 
openssl version. If those other tools can not decode the cert then it's 
likely the cert is corrupt. Note also the problem seems to be decoding 
an cert extension and extension decoders get less testing so it wouldn't 
surprise me if there was a decoding bug.

I have the tools readily available if you don't and would like me try 
reading the cert if you send it to me privately (without the matching CA 
cert used to sign it it's of no value to me so as long as it's not a 
public CA it's a safe thing to do)


-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/