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