EAP-TLS / OpenSSL Debug Output
ben at an3k.de
Thu May 28 11:32:15 CEST 2015
And here's an EAP-TLS eapol_test conf file for
2015-05-28 10:29 GMT+02:00 Ben Humpert <ben at 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!
> 2015-05-27 23:30 GMT+02:00 Alan DeKok <aland at deployingradius.com>:
>> On May 27, 2015, at 11:13 AM, Ben Humpert <ben at 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
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 272 bytes
Desc: not available
More information about the Freeradius-Users