eap_peap: ERROR: (TLS) Alert read:fatal:unknown CA

Dario Barbon dbarbon at olicom.eu
Fri Jan 5 15:09:35 UTC 2024

Hi Alan, thanks for your answer (sorry for previous bad explanation of 
the question).

My production Freeradius server is configured to perform EAP-TLS; I 
created private CA, server certificate and client certificates. All 
certificates are stored inside freeradius/certs directory. Below the 
production mods-available/eap file  :

eap {
         default_eap_type = tls
         timer_expire = 60
         ignore_unknown_eap_types = no
         cisco_accounting_username_bug = no
         max_sessions = 4096
         tls {
                 certdir = ${confdir}/certs
                 cadir = ${confdir}/certs
                 private_key_password = "mypasswordhere"
                 private_key_file = ${certdir}/server.key
                 certificate_file = ${certdir}/server.pem
                 ca_path = ${cadir}
                 ca_file = ${cadir}/ca.pem
                 dh_file = ${certdir}/dh
                 random_file = /dev/urandom
                 cipher_list = "HIGH"
                 make_cert_command = "${certdir}/bootstrap"
                 ecdh_curve = "prime256v1"
                 cache {
                         enable = no # Optionally enable
                         lifetime = 24 # hours
                         max_entries = 255
                 verify {
                         tmpdir = /tmp/radiusd
                         client = "/usr/bin/openssl verify -CAfile 
${..ca_file} %{TLS-Client-Cert-Filename}"
                 ocsp {
                         enable = no # optionally enable
                         override_cert_url = yes
                         url = ""
         ttls {
                 default_eap_type = md5
                 copy_request_to_tunnel = no
                 use_tunneled_reply = no
                 virtual_server = "inner-tunnel"

and the production virtual server file (sites-enabled/tlcamb-tag):

server {

#  Server

listen {
        ipaddr = *
        port = 1812
        type = auth

#  Authorization. First preprocess (hints and huntgroups files),

authorize {
     #  This module takes care of EAP-MSCHAPv2 authentication.
     #  It also sets the EAP-Type attribute in the request
     #  attribute list to the EAP type from the packet.
     #  The example below uses module failover to avoid querying all
     #  of the following modules if the EAP module returns "ok".
     #  Therefore, your LDAP and/or SQL servers will not be queried
     #  for the many packets that go back and forth to set up TTLS
     #  or PEAP.  The load on those servers will therefore be redu
     eap {
         ok = return


#  Authentication.
authenticate {

         # MSCHAP authentication.
     Auth-Type MS-CHAP {
     #  Allow EAP authentication.

preacct {
accounting {
     # unix
     # exec

session {

#  Post-Authentication
post-auth {

     #  Access-Reject packets are sent through the REJECT sub-section of the
     #  post-auth section.
     #  Add the ldap module name (or instance) if you have set
     #  'edir_account_policy_check = yes' in the ldap module configuration
     Post-Auth-Type REJECT {

pre-proxy {

#  When the server receives a reply to a request it proxied
#  to a home server, the request may be massaged here, in the
#  post-proxy stage.
post-proxy {

     #  If you want to have a log of replies from a home server,
     #  un-comment the following line, and the 'detail post_proxy_log'
     #  section, above.
#    post_proxy_log

     #  Uncomment the following line if you want to filter replies from
     #  remote proxies based on the rules defined in the 'attrs' file.
#    attr_filter.post-proxy

     #  If you are proxying LEAP, you MUST configure the EAP
     #  module, and you MUST list it here, in the post-proxy
     #  stage.
     #  You MUST also use the 'nostrip' option in the 'realm'
     #  configuration.  Otherwise, the User-Name attribute
     #  in the proxied request will not match the user name
     #  hidden inside of the EAP packet, and the end server will
     #  reject the EAP request.


With this configuration in place I can connect to enterprise WiFi from 
Android devices. But very often only Android 11 devices (I don't really 
know why) "losts" client certificates. The  installed certificates get 
removed from the device itself (often when the device get out of WiFi 
range for one hour or more). So, to address this problem, I'm trying to 
add MSCHAPv2 and I updated eap file adding peap directives as follows:

     peap {
         tls = tls-common
         default_eap_type = mschapv2
         virtual_server = "inner-tunnel"

and I enabled inner-tunnel virtual server (without changing nothing 
inside the default inner-tunnel file).

With the updated configuration in place I continue to successfully 
connect to WiFi using EAP-TLS while if I try MSCHAPv2 I cannot connect. 
I configured Android WiFi profile as follows:

EAP Method: PEAP
Phase 2 authentication: MSCHAPv2
CA Certificate: use system certificates
Online certificate status: do not validate
Domain: I'm using the value of the commonName field of CA config file
Identity: bob (the test user inside freeradius/users file)
Password: whatever

Please take note that the lost client certificate issue affects only 
Android 11 devices; different OS versions aren't affected.

Thanks and best regards.

Dario Barbon

Il 05/01/2024 15:08, Alan DeKok ha scritto:
> On Jan 5, 2024, at 8:57 AM, Dario Barbon <dbarbon at olicom.eu> wrote:
>> Hi all, I'm trying to configure Freeradius (version 3.2.3 on Ubuntu 22.04) to perform either EAP-TLS and EAP-PEAP MSCHAPv2. I need MSCHAPv2 as alternative configuration for Android 11 devices because we are experiencing the deletion of client certificates and I'm not understand why this issue happens.
>    I'm not sure what you mean by "deletion of client certificates".  FreeRADIUS doesn't delete certificate.  Use devices don't delete certificates.  My guess is something else is going wrong.
>> The EAP-TLS configuration works fine with self signed CA and client certs signed by our private CA (except for Android 11 devices as I said).
>    But it doesn't work with *what* kind of certificates?  You're not saying.
>    If you want to get help with something going wrong, it's usually good to explain what you were doing, and what went wrong.  It doesn't help to say "I did a bunch of things which worked, but I'm not going to explain what I did when things didn't work".
>> Below are the logs when I try to connect to Freeradius using MSCHAPv2 (I enabled "bob" user):
>> (6) eap_peap: (TLS) recv TLS 1.2 Alert, fatal unknown_ca
>> (6) eap_peap: (TLS) The client is informing us that it does not recognize the CA used to issue the server certificate.  Please update the client so that it knows about the CA.
>    That seems pretty clear.
>    This has nothing to do with client certificates.
>    Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

More information about the Freeradius-Users mailing list