Skip to Content.
Sympa Menu

cat-users - Re: [[cat-users]] "Internal error" while connecting via "geteduroam" on Android 11

cat-users AT lists.geant.org

Subject: The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

List archive

Re: [[cat-users]] "Internal error" while connecting via "geteduroam" on Android 11


Chronological Thread 
  • From: Paul Dekkers <paul.dekkers AT surf.nl>
  • To: Arthur Petrosyan <arthur AT sci.am>
  • Cc: cat-users AT lists.geant.org
  • Subject: Re: [[cat-users]] "Internal error" while connecting via "geteduroam" on Android 11
  • Date: Tue, 5 Oct 2021 22:33:27 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=surf.nl; dmarc=pass action=none header.from=surf.nl; dkim=pass header.d=surf.nl; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Qv8AR9n2SyvKIkQWSGPPVKE+W3K++7lpqrChyfksDfI=; b=bf6/43iLayvmBa5KGrc2mbAZwfaL8zrYWlEkf93QwADbMCf0cpldPnoWtj/tDzUx6Zxfl7TkpyWdvjAjHGSy/78A29L5QuCjKoMn2y+eUqza4KHpXmN8GEp24ls7Tt4qtbq80qQfBdSaiCyJ8ofUlfVunrYrEweVXBP6SD+9QBurqKXk7cvDxB24czlnPAsr95Psy71RTmrJndqiyrMfJGI6QI09tDDpfYPkZBj9lX8YDYXty4T5eGHMwEg4SAqxeJUs/wTQYfIneALn9QnBzfn/fh4oSFlj2vrSWYY4GyiX2S06+QIdmTtU75lWBPs72c3Z1wu76j01EVZX+jGpzA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dKU5u7xhYjf+fcT5m4Mzm5AksjpHVDrycYulJOA3+CVxq9MPuJVcVONHj3a+eM1nZNt/urbaZ4GptfssgQsZUvBB3TvGluCpNq3AwxCRLcRV1Sy/nAXqmSpGjJM+FutPqk8SfH70jq1zi59c+5fokbJda1wPUwYGZKPzIHoMK7K6xQjOSe/8WvoigQPlLWX/5Adfm4xuhE+6ZydBcSL+uy83glYwu7wW3orcuYImGEx+zBjoBcgiGDd//9h3HlDAKtLqZs+e2JKe/r1m4kNzJdrCWNycZcgtBcgkstRWg0qEElN2H4yTcWWMSqOSFUoOAFjdBUCzLuXp4JiOJ4POiw==
  • Authentication-results: sci.am; dkim=none (message not signed) header.d=none;sci.am; dmarc=none action=none header.from=surf.nl;

Hi,

These certificates from FreeRADIUS are really examples, used for testing; I wouldn't use them in production. And one thing that is indeed missing is attributes we common find in other certificates. And you shouldn't use a CA for the server indeed, without server purpose.

The EAP server certificate considerations page also lists these requirements, like the SubjectAltName:DNS AND the Extended Key Usage, and CA:FALSE. This page indeed lists a few advantages of a "small special purpose CA", but there also disadvantages, and maybe even more so in 2021. A few I think I mentioned, like the risk for man-in-the-middle attacks by this particular CA if it's installed. But also OS vendors treat server certificates differently. One example is Android, where it's now more trivial to configure the client correctly if you are using a public CA.

You cannot alter an existing certificate; you can replace it. If it has similar properties, and depending on the way the clients are configured (like with CAT), you can actually keep the trust on the FQDN. But, in your case, I think you need to swap out to a different CA. Or use this CA to create the actual certificate. But the FreeRADIUS scripts won't help you, that's playing a lot with openssl I think.

Regards,
Paul


On 05/10/2021 18:12, Arthur Petrosyan wrote:
87d983bd-3bd2-6067-f202-71717fab51e5 AT sci.am">

Hi All !

We use the freeradius-provided "cert" folder to generate self-signed cert.
And it worked/works with "eduroam CAT".

The page we took into consideration when making a decision was:
https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations

Here we read:
"certificates from a commercial CA are as valid for EAP authentications as are self-made certificates or certificates from a small, special-purpose CA."
So we found self-made ones more fitting our situation for now.
I thought many are using them. Am I wrong?
If yes I would be happy to get more info to maybe improve our approach.

Regarding "subjectAltName DNS:" entry I didn't find any example in freeradius "cert" folder to confugure that.

Can anyone using freeradius's "cert" self-signed certificates share example of configuring "subjectAltName DNS:" entry there?

Is it possible to add that entry to the existing certificate ?
What will such change mean to current users of realm and their end-user device configuration?

Thanks in advance for all, who might assist us.
Arthur Petrosyan


2021-10-01 17:16, Paul Dekkers пишет:
73806c12-31ff-5337-7472-19c518d86ffd AT surf.nl">
Hi,

Op 01-10-2021 om 13:27 schreef Arthur Petrosyan:
Hi all,

On my "Poco X3" smartphone with "Android 11RKQ1.200826.002"
I can connect to eduroam by downloading the profile for "Fundamental
Scientific Library NAS RA" from "cat.eduroam.org"
and installing it using "eduroam CAT" app from Google playstore.
But when I try to connect using "geteduroam" app, it don't work, and the
freeradius logs show the following:

Fri Oct  1 14:49:54 2021 : ERROR: (6750) eap_ttls: ERROR: TLS Alert
read:fatal:internal error
Fri Oct  1 14:49:54 2021 : Auth: (6750) Login incorrect (eap_ttls: TLS
Alert read:fatal:internal error): [***@flib.sci.am] (from client ***
port 0 cli 10-3F-44-FA-80-D7)

I tried to connect with the same account using "geteduroam" on Windows
and it worked without problem, so I guess the issue is specific for
Android.
I remember several discussions here in the list regarding Android issues
with "geteduroam", but not sure if it's related to this.

Can it be related specifically to our CAT profile (we use only TTLS/PAP
there)?
Is there a fix for it ?

I would be very thankful for help !
You seem to be using a private CA (in fact, there is no CA the entire
certificate is self signed). One issue is likely that you have no
subjectAltName DNS: entry with your hostname, and the geteduroam
installer expects that.

By the looks of it, it also doesn't have the server auth purpose, and is
a CA by the constraints flag - that may not be a problem.

You probably noticed the warning about the certificate on Windows when
installing a private CA? Keep in mind your CA needs proper protection.
That's a bit more challenging if this is also your server certificate,
in that you cannot store it offline but it's always online.

A private CA is risky in the sense that it can be abused to sign
certificates for other purposes, other websites too. For instance for
google.com, and thus IF your CA is abused, it can be used for a
man-in-the-middle for any normally by SSL protected traffic.
Using a certificate from a public CA is a bit more on the safer side in
this case, and they tick all the boxes from what is expected in a
certificate.

Regards,
Paul
To unsubscribe, send this message: mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
Or use the following link: https://lists.geant.org/sympa/sigrequest/cat-users
To unsubscribe, send this message: mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
Or use the following link: https://lists.geant.org/sympa/sigrequest/cat-users



Archive powered by MHonArc 2.6.19.

Top of Page