Peace, I have free radius 3.0.14 and I managed to authenticate using peap and ttls using the self signed server certificate. I tried to push it further with requiring client certificates but that didn't work. I get the following message in the radius log: ERROR: (20) eap_peap: ERROR: TLS Alert write:fatal:handshake failure Wed Sep 13 15:56:33 2017 : Error: tls: TLS_accept: Error in error Wed Sep 13 15:56:33 2017 : Auth: (20) Login incorrect (eap_peap: TLS Alert write:fatal:handshake failure): [ameen/<via Auth-Type = eap>] (from client cisco switch port 50247 cli C3-6F-2F-15-82-3B) I ducked ducked the internet for the mentioned error and on how to install client certificates for windows but I couldn't find a solution. I imagine I correctly imported the server certificate but am unsure about the client certificate. I generated the client certificates by editing client.cnf as follows: [ ca ] default_ca = CA_default [ CA_default ] dir = ./ certs = $dir crl_dir = $dir/crl database = $dir/index.txt new_certs_dir = $dir certificate = $dir/ca.pem serial = $dir/serial crl = $dir/crl.pem private_key = $dir/ca.key RANDFILE = $dir/.rand name_opt = ca_default cert_opt = ca_default default_days = 1826 default_crl_days = 30 default_md = sha256 preserve = no policy = policy_match [ policy_match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy_anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] prompt = no distinguished_name = client default_bits = 2048 input_password = ameen output_password = ameen [client] countryName = RU stateOrProvinceName = Samara localityName = place organizationName = comp emailAddress = ameen@test.ru <mailto:ameen@test.ru> commonName = ameen then I make client .pem and a file named ameen@test.ru.pem <mailto:ameen@test.ru.pem> is generated. For the next certificate I just change the email and common name and make client.pem again. I tried to import the client certificate in windows using mmc, then adding the snap-in certificates and importing ameen@test.ru.pem <mailto:ameen@test.ru.pem> to the trusted root center certificate. I also tried double clicking on client.p12 and letting it install automatically but that installed in the private folder. I tried to double click again and import to the trusted root center certificate but that does the same thing as the pem file and installs the ameen certificate. I then checked peap in windows and selected to validate certificate and chose the ca, server and client certificate and chose mschapv2 as authentication, unchecked use windows logon credentials and saved the username and password in extra parameters. The username was saved in mysql using daloradius and it worked fine until I required using client certificate. Here is the eap configuration: eap { default_eap_type = peap timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = ${max_requests} md5 { } tls-config tls-common { private_key_password = ameen private_key_file = ${certdir}/server.pem certificate_file = ${certdir}/server.pem ca_file = ${cadir}/ca.pem # auto_chain = yes # psk_identity = "test" # psk_hexphrase = "036363823" dh_file = ${certdir}/dh random_file = /dev/urandom # fragment_size = 1024 # include_length = yes # check_crl = yes # Check if intermediate CAs have been revoked. # check_all_crl = yes ca_path = ${cadir} # check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd" # check_cert_cn = %{User-Name} cipher_list = "DEFAULT" cipher_server_preference = no # disable_tlsv1_2 = no ecdh_curve = "prime256v1" cache { enable = no lifetime = 24 # hours #name = "EAP module" #persist_dir = "${logdir}/tlscache" } ## EAP-TLS # # As of Version 3.0, the TLS configuration for TLS-based # EAP types is above in the "tls-config" section. # tls { # Point to the common TLS configuration tls = tls-common # # As part of checking a client certificate, the EAP-TLS # sets some attributes such as TLS-Client-Cert-CN. This # virtual server has access to these attributes, and can # be used to accept or reject the request. # # virtual_server = check-eap-tls } ## EAP-TTLS # # The TTLS module implements the EAP-TTLS protocol, # which can be described as EAP inside of Diameter, # inside of TLS, inside of EAP, inside of RADIUS... # # Surprisingly, it works quite well. # ttls { # Which tls-config section the TLS negotiation parameters # are in - see EAP-TLS above for an explanation. # # In the case that an old configuration from FreeRADIUS # v2.x is being used, all the options of the tls-config # section may also appear instead in the 'tls' section # above. If that is done, the tls= option here (and in # tls above) MUST be commented out. # tls = tls-common # The tunneled EAP session needs a default EAP type # which is separate from the one for the non-tunneled # EAP module. Inside of the TTLS tunnel, we recommend # using EAP-MD5. If the request does not contain an # EAP conversation, then this configuration entry is # ignored. # default_eap_type = mschapv2 # The tunneled authentication request does not usually # contain useful attributes like 'Calling-Station-Id', # etc. These attributes are outside of the tunnel, # and normally unavailable to the tunneled # authentication request. # # By setting this configuration entry to 'yes', # any attribute which is NOT in the tunneled # authentication request, but which IS available # outside of the tunnel, is copied to the tunneled # request. # # allowed values: {no, yes} # copy_request_to_tunnel = no # # As of version 3.0.5, this configuration item # is deprecated. Instead, you should use # # update outer.session-state { # ... # # } # # This will cache attributes for the final Access-Accept. # # The reply attributes sent to the NAS are usually # based on the name of the user 'outside' of the # tunnel (usually 'anonymous'). If you want to send # the reply attributes based on the user name inside # of the tunnel, then set this configuration entry to # 'yes', and the reply to the NAS will be taken from # the reply to the tunneled request. # # allowed values: {no, yes} # use_tunneled_reply = no # # The inner tunneled request can be sent # through a virtual server constructed # specifically for this purpose. # # If this entry is commented out, the inner # tunneled request will be sent through # the virtual server that processed the # outer requests. # virtual_server = "inner-tunnel" # This has the same meaning, and overwrites, the # same field in the "tls" configuration, above. # The default value here is "yes". # # include_length = yes # # Unlike EAP-TLS, EAP-TTLS does not require a client # certificate. However, you can require one by setting the # following option. You can also override this option by # setting # # EAP-TLS-Require-Client-Cert = Yes # # in the control items for a request. # require_client_cert = yes } ## EAP-PEAP peap { tls = tls-common default_eap_type = mschapv2 copy_request_to_tunnel = no use_tunneled_reply = no # proxy_tunneled_request_as_eap = yes virtual_server = "inner-tunnel" # soh = yes # soh_virtual_server = "soh-server" require_client_cert = yes } Is any more information needed and what am I doing wrong?