And here's an EAP-TLS eapol_test conf file for http://deployingradius.com/scripts/eapol_test/ :) 2015-05-28 10:29 GMT+02:00 Ben Humpert <ben@an3k.de>:
Thank you very much for your help (again :). I sorted it all out.
The Signing CA certificate has nameContraints set. It is only allowed to sign certificates with either an IP address from the three private address ranges or DNS names which end on .lan or .local However, the violation check should only applied onto CN if subjectAltName is not present and then only when either an DNS or IP address is specified but not if a random name for CN (eg. RADIUS server) is applied. With the original RADIUS server certificate (DN="/C=DE/O=Example Company/CN=RADIUS Server" and subjectAltName="DNS:radius.home.lan,IP:10.11.12.13") and eapol_test I got the same unknown certificate error in FR debug but in eapol_test I additionally got
TLS: Certificate verification failed, error 47 (permitted subtree violation) depth 0 for '/C=DE/O=Example Company/CN=RADIUS Server' CTRL-EVENT-EAP-TLS-CERT-ERROR reason=0 depth=0 subject='/C=DE/O=Example Company/CN=RADIUS Server' err='permitted subtree violation' EAP: Status notification: remote certificate verification (param=permitted subtree violation) [...] SSL: SSL3 alert: write (local SSL3 detected an error):fatal:certificate unknown EAP: Status notification: local TLS alert (param=certificate unknown) [...] OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Sadly OpenSSL doesn't send the actual error to the server but unknown certificate instead which is like "unknown error" in windows.
I then created a cert without subjectAltName but got the same error. Another new certificate with radius.home.lan as CN and still no subjectAltName and eapol_test as well as Android didn't throw an error but connected successfully.
It is actually an awesome bug in OpenSSL. I ran some tests some weeks ago with OpenSSL's s_client tool and SSL Web Server and the result was that s_client doesn't check the CN field for nameConstraints violation. While all major web browsers denied the web server certificate for CN=www.google.de (because .de was not permitted) s_client reported "Verify return code: 0 (ok)". Obviously s_client behaves differently than OpenSSL itself but in both the nameConstraints validation code is completely broken and even worse than it is in Internet Explorer (which can't handle IP addresses in subjectAltName, just like OpenSSL).
Thanks again and sorry for not directly using eapol_test. At least I now can more easily help others with cert problems ;)
Have a great day!
Ben
2015-05-27 23:30 GMT+02:00 Alan DeKok <aland@deployingradius.com>:
On May 27, 2015, at 11:13 AM, Ben Humpert <ben@an3k.de> wrote:
The client certificate is signed by the same CA (Signing CA) that also signed the server certificate. If I specify the Signing CA cert in ca_file and try to connect with Android (with the Signing CA cert specified) I get the 'unknown CA' error. If I disable ca certificate in Android I get
Errors.
Test it with eapol_test. Odds are it will work.
Then ask Android why their supplicant doesn't work.
In my raddb/certs directory I have the SigningCA.crt, the RootCA.crt, radius.crt (specified as certificate_file), radius.key (private_key_file) and ChainedCA.crt (ca_file).
That should be fine.
But vendors are well known for brutally destroying protocols so that they don't work.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html