Hi, I am not seeing the XP X.509 OIDs specific for Windows on your certificate. Dont you need them? Have a look at certs/xpentensions. Regards, Rui -- Senior Sysadm ISCTE-IUL https://www.linkedin.com/pub/rui-ribeiro/16/ab8/434

Message: 2 Date: Mon, 6 Oct 2014 11:28:14 -0700 From: Martin Rowe <martin.p.rowe@gmail.com> To: freeradius-users@lists.freeradius.org Subject: Windows 8.1 Wi-Fi client handshake failure Message-ID: < CAOAjy5SRi8VDv1FYunFDfJ-UgOW7+jmnWNZxDxycA1jA2bXKvg@mail.gmail.com> Content-Type: text/plain; charset=UTF-8

Hello,

I'm having trouble getting a Windows 8.1 laptop to connect to my Wi-Fi which is using only EAP-TLS managed by FreeRADIUS. Before you ask, yes I have included serverAuth/clientAuth in the certificates and the configuration is tested to work with Linux and Android clients, so I don't think there is a problem on the server side. That is as far as Google has been able to help me, so I'm hoping someone here has had the same problem and might know a solution.

The specific issue as far as I can troubleshoot is that the client and server can't agree on a shared TLS cipher. I'm seeing these lines in my logs every time I attempt a connection:

Info: [tls] TLS_accept: before/accept initialization Info: [tls] <<< TLS 1.0 Handshake [length 0067], ClientHello Info: [tls] >>> TLS 1.0 Alert [length 0002], fatal handshake_failure Error: TLS Alert write:fatal:handshake failure Error: TLS_accept: error in SSLv3 read client hello C Error: rlm_eap: SSL error error:1408A0C1:lib(20):func(138):reason(193) Error: SSL: SSL_read failed in a system call (-1), TLS session fails.

...

From [1] it looks like the SSL errors mean:

lib(20) = ERR_LIB_SSL func(138) = SSL_F_SSL3_GET_CLIENT_HELLO reason(193) = SSL_R_NO_SHARED_CIPHER

[1] http://comments.gmane.org/gmane.comp.encryption.openssl.user/9654

But that is as far as I can get. I've tried disabling every option I can in the configs and many variations on the Windows side, but they all stop at the same point. There is no limit I have set on which TLS ciphers can be used (cipher_list in eap{tls{}} is not used, and gave the same error when set to DEFAULT).

My only other guess is there is something wrong with the certificates, but I'm not sure what might be wrong. I have copied both my root and my radius intermediate CA certificates onto the Windows client along with the client certificate and key. They are installed and the chain is valid according to the Windows Credential Manager. The server ca.pem has both the root and intermediate certificates concatenated together and that works fine with my other clients. So all I can think of is that Windows is being extra picky about something. Below is the sanitized text certificate for the server and client in the hope that the error is obvious to someone else:

......