Troubleshooting EAP-TLS with External Certificates

Thu Aug 4 23:12:42 CEST 2016

Follow up to last e-mail.  Needed to use a different cert chain and
have uploaded that to the server.  Tried to authorize again and got a
similar error, below.  It appears the output means that the handshake
failed due to a self-signed certificate in the chain.  Can someone
verify that for me?

Thank you,

Matthew

[tls] Done initial handshake
[tls] <<< TLS 1.0 Handshake [length 11fa], Certificate
--> verify error:num=19:self signed certificate in certificate chain
[tls] >>> TLS 1.0 Alert [length 0002], fatal unknown_ca
TLS Alert write:fatal:unknown CA
    TLS_accept: error in SSLv3 read client certificate B
rlm_eap: SSL error error:140890B2:SSL
routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
SSL: SSL_read failed in a system call (-1), TLS session fails.
TLS receive handshake failed during operation
[tls] eaptls_process returned 4
[eap] Handler failed in EAP/tls
[eap] Failed in EAP select
++[eap] = invalid
+} # group authenticate = invalid
Failed to authenticate the user.
Using Post-Auth-Type REJECT
# Executing group from file /etc/raddb/sites-enabled/default
+group REJECT {
[attr_filter.access_reject] expand: %{User-Name} -> Matthew West
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] = updated
+} # group REJECT = updated
Delaying reject of request 10 for 1 seconds
Going to the next request

On Wed, Aug 3, 2016 at 3:14 PM, Matthew West <matthew.t.west at gmail.com> wrote:
> Hello FreeRADIUS Users,
>
> Thank you for taking my question.  I am in the process of
> troubleshooting the EAP-TLS process using the following version of
> FreeRADIUS:
>
> radiusd: FreeRADIUS Version 2.2.6, for host x86_64-redhat-linux-gnu
>
> openssl: openssl-1.0.1e-48.el6_8.1.x86_64
>
> I've gotten successful authentication using PAP through a switch with
> a test user, so the service is available and the client switch is
> communicating correctly.  FreeRADIUS starts just fine, has the correct
> client, EAP loads, and points to the correct certs.  I also have a
> client certificate in the certificate directory.
>
> Server certificate (star.companyname.net) was issued by GoDaddy and my
> (client) certificate was issued by VeriSign.  I am pointing to the
> GoDaddy CA bundle for the server, but am not sure where to put the
> 'user' certificate chain (or does the whole chain need to be in the
> user cert)?  Am I interpreting the error correctly?  That the client
> cert appears to be self signed?
>
> radius -X OUTPUT:
> ====================
>
> ...
> radiusd: #### Loading Clients ####
>  client ***-CORP-SW1 {
>   ipaddr = 10.x.x.123
>   require_message_authenticator = no
>   secret = "xxxxxx"
>  }
> ...
>
> ...
>  Module: Instantiating module "eap" from file /etc/raddb/eap.conf
>   eap {
>   default_eap_type = "tls"
>   timer_expire = 60
>   ignore_unknown_eap_types = no
>   cisco_accounting_username_bug = no
>   max_sessions = 1024
>   }
> ...
>
> ...
>  Module: Instantiating eap-tls
>    tls {
>    rsa_key_exchange = no
>    dh_key_exchange = yes
>    rsa_key_length = 512
>    dh_key_length = 512
>    verify_depth = 0
>    CA_path = "/etc/raddb/certs"
>    pem_file_type = yes
>    private_key_file = "/etc/raddb/certs/star.XXX.net.key"
>    certificate_file = "/etc/raddb/certs/star.XXX.net.crt"
>    CA_file = "/etc/raddb/certs/gd_bundle-g2.crt"
>    dh_file = "/etc/raddb/certs/dh"
>    fragment_size = 1024
>    include_length = yes
>    check_crl = no
>    cipher_list = "DEFAULT"
>    ecdh_curve = "prime256v1"
>     cache {
>     enable = no
>     lifetime = 24
>     max_entries = 255
>     }
>     verify {
>     }
>     ocsp {
>     enable = no
>     override_cert_url = yes
>     url = "http://127.0.0.1/ocsp/"
>     use_nonce = yes
>     timeout = 0
>     softfail = no
>     }
>    }
> ...
>
> ...
> Listening on authentication address * port 1812
> Listening on accounting address * port 1813
> Listening on command file /var/run/radiusd/radiusd.sock
> Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel
> Listening on proxy address * port 1814
> Ready to process requests.
> ...
>
> When a request is made, I receive the following output:
>
> ...
> # Executing section authorize from file /etc/raddb/sites-enabled/default
> +group authorize {
> ++[preprocess] = ok
> ++[chap] = noop
> ++[mschap] = noop
> ++[digest] = noop
> [suffix] No '@' in User-Name = "Matthew West", looking up realm NULL
> [suffix] No such realm "NULL"
> ++[suffix] = noop
> [eap] EAP packet type response id 20 length 253
> [eap] No EAP Start, assuming it's an on-going EAP conversation
> ++[eap] = updated
> ++[files] = noop
> ++[expiration] = noop
> ++[logintime] = noop
> ++[pap] = noop
> +} # group authorize = updated
> Found Auth-Type = EAP
> # Executing group from file /etc/raddb/sites-enabled/default
> +group authenticate {
> [eap] Request found, released from the list
> [eap] EAP/tls
> [eap] processing type tls
> [tls] Authenticate
> [tls] processing EAP-TLS
> [tls] eaptls_verify returned 7
> [tls] Done initial handshake
> [tls] <<< TLS 1.0 Handshake [length 11fa], Certificate
> --> verify error:num=19:self signed certificate in certificate chain
> [tls] >>> TLS 1.0 Alert [length 0002], fatal unknown_ca
> TLS Alert write:fatal:unknown CA
>     TLS_accept: error in SSLv3 read client certificate B
> rlm_eap: SSL error error:140890B2:SSL
> routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
> SSL: SSL_read failed in a system call (-1), TLS session fails.
> TLS receive handshake failed during operation
> [tls] eaptls_process returned 4
> [eap] Handler failed in EAP/tls
> [eap] Failed in EAP select
> ++[eap] = invalid
> +} # group authenticate = invalid
> Failed to authenticate the user.
> Using Post-Auth-Type REJECT
> # Executing group from file /etc/raddb/sites-enabled/default
> +group REJECT {
> [attr_filter.access_reject] expand: %{User-Name} -> Matthew West
> attr_filter: Matched entry DEFAULT at line 11
> ++[attr_filter.access_reject] = updated
> +} # group REJECT = updated
> Delaying reject of request 39 for 1 seconds
> Going to the next request
> Waking up in 0.9 seconds.
> Sending delayed reject for request 39
> Sending Access-Reject of id 104 to 10.***.***.123 port 1645
> EAP-Message = 0x04140004
> Message-Authenticator = 0x00000000000000000000000000000000
> Waking up in 3.8 seconds.
> Cleaning up request 30 ID 95 with timestamp +227
> Cleaning up request 31 ID 96 with timestamp +227
> Cleaning up request 32 ID 97 with timestamp +227
> Cleaning up request 33 ID 98 with timestamp +227
> Cleaning up request 34 ID 99 with timestamp +227
> Cleaning up request 35 ID 100 with timestamp +227
> Cleaning up request 36 ID 101 with timestamp +227
> Cleaning up request 37 ID 102 with timestamp +227
> Cleaning up request 38 ID 103 with timestamp +227
> Waking up in 1.0 seconds.
> Cleaning up request 39 ID 104 with timestamp +227
> Ready to process requests.
> ...
>
> Any help appreciated.
>
> Thank You,
>
> Matthew