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 <[email protected]>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
