EAP-TLS / OpenSSL Debug Output

[Ben Humpert]

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 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
>
>   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