Help with configuring client certificates for peap or ttls
Vacheslav
m_zouhairy at skno.by
Fri Sep 15 08:30:58 CEST 2017
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 at test.ru <mailto:ameen at test.ru>
commonName = ameen
then I make client .pem and a file named ameen at test.ru.pem
<mailto:ameen at 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 at test.ru.pem <mailto:ameen at 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?
More information about the Freeradius-Users
mailing list