An open discussion list for topics related to the geteduroam service

[Darren Boss <Darren.Boss AT alliancecan.ca>]

I redeployed the portal on Debian 11.4 (Bullseye) but now I'm getting a error 
400 on the call from the Android app to /api/eap-config/. I decided to log 
the Authorization header to a custom log and was able to decode it using a 
JWT decoder. Looks fine, sub claim is my email address (using email nameid 
from Azure AD). Including the decoded JWT in case it's something obvious:

{
  "__t": "access_token",
  "iat": "1660739494",
  "sub": "Darren.Boss AT alliancecan.ca",
  "realm": "alliancecan.ca",
  "scope": "eap-metadata",
  "code_challenge_method": "S256",
  "code_challenge": "LQpjYE1ZjYAC6i9OwaU3OFYUBR9-rV-X0ohvYcXpLi4",
  "client_id": "app.eduroam.geteduroam",
  "redirect_uri": "app.eduroam.geteduroam:/",
  "exp": "1676637094"
}

jwt.io is flagging the dates as invalid but they look right to me and the iat 
matches the date of the apache log entry.

From: geteduroam-request AT lists.geant.org <geteduroam-request AT lists.geant.org> 
on behalf of Darren Boss <geteduroam AT lists.geant.org>
Sent: Tuesday, August 16, 2022 3:17 PM
To: Paul Dekkers <paul.dekkers AT surf.nl>
Cc: geteduroam AT lists.geant.org <geteduroam AT lists.geant.org>
Subject: Re: Problem with certificates generated 
 
I pulled an older Android device out of storage but the errors I'm seeing on 
the freeradius server are the same as on the newer Android 12 device. I'm not 
expecting anyone to debug my radius setup, just providing the debug output 
here in case it's relevant to the portal configuration or someone has 
encountered a similar issue:

(7) eap: Peer sent EAP Response (code 2) ID 151 length 13 
(7) eap: No EAP Start, assuming it's an on-going EAP conversation
(7)     [eap] = updated
(7)   } # authorize = updated
(7) Found Auth-Type = eap
(7) # Executing group from file /etc/raddb/sites-enabled/default
(7)   authenticate {
(7) eap: Expiring EAP session with state 0xcaea98f1c87d95e7
(7) eap: Finished EAP session with state 0xcaea98f1c87d95e7
(7) eap: Previous EAP request found for state 0xcaea98f1c87d95e7, released 
from the list
(7) eap: Peer sent packet with method EAP TLS (13)
(7) eap: Calling submodule eap_tls to process data
(7) eap_tls: Continuing EAP-TLS
(7) eap_tls: [eaptls verify] = ok
(7) eap_tls: Done initial handshake
(7) eap_tls: <<< recv TLS 1.2  [length 0002] 
(7) eap_tls: ERROR: TLS Alert read:fatal:internal error
(7) eap_tls: TLS_accept: Need to read more data: error
(7) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:14094438:SSL 
routines:ssl3_read_bytes:tlsv1 alert internal error
(7) eap_tls: TLS - In Handshake Phase
(7) eap_tls: TLS - Application data.
(7) eap_tls: ERROR: TLS failed during operation
(7) eap_tls: ERROR: [eaptls process] = fail
(7) eap: ERROR: Failed continuing EAP TLS (13) session.  EAP sub-module failed

I find debugging Radius issues quite challenging because I work with radius 
very frequently. This is all non-production so I can make sweeping changes to 
the radius configuration. I followed the guide at 
https://wiki.freeradius.org/guide/eduroam and I was also responsible for 
another organization's eduroam radius server which was and still is working 
but using EAP-PEAP with OpenLDAP. This time I'm quite determined to do 
EAP-TLS with the portal app using SAML auth to Azure AD IdP.
A very basic (but functional) eduroam configuration - FreeRADIUS
mods-available/eap eap { # The initial EAP type requested. Change this to 
peap if you're # using peap, or tls if you're using EAP-TLS. default_eap_type 
= ttls # The maximum time an EAP-Session can continue for timer_expire = 60 # 
The maximum number of ongoing EAP sessions max_sessions = ${max_requests} 
tls-config tls-common { # The public certificate that your server will 
present certificate ...
wiki.freeradius.org


 
Darren Boss (he/him)
Senior Programmer | Développeur Sénior
 
 
     343-341-2323


From: Paul Dekkers <paul.dekkers AT surf.nl>
Sent: Tuesday, August 16, 2022 12:08 PM
To: Darren Boss <Darren.Boss AT alliancecan.ca>
Cc: geteduroam AT lists.geant.org <geteduroam AT lists.geant.org>
Subject: Re: Problem with certificates generated 
 

You don't often get email from paul.dekkers AT surf.nl. Learn why this is 
important

Hi,

Ok, so I suspect the issue you're seeing that is fixable with the -legacy 
flag is only on your local system; yet we don't currently configure a 
passphrase for the .pkcs12 files that are manually downloaded so I didn't 
expect you to have that problem on manual downloaded certificates. If you 
extracted the pkcs12 payload from the .eap-config, this makes more sense.

Android 12 and Pixel 6 should just work; at least I just used Android 12 on a 
Pixel 5 a couple of times today and that worked ;-)

We need to look at generating a pkcs12 with a supported algorithm for 
end-user devices with OpenSSL 3; but I don't expect your Android phone has 
that already unless that's pushed to a very recent Android 12 update? (Feel 
free to suggest a fix ;-) The fix may actually also be to run the server on 
an OpenSSL 3 server maybe, hmm. Like Ubuntu 22.04.)

If you want to rule things out, I can give you a test-account at a demo 
instance (running Debian) so you can test if it happens there or is something 
related to your local letswifi-ca deployment? (Send me a private mail if you 
want to try that.)

Regards,
Paul


On 16/08/2022 18:01, Darren Boss wrote:
On the Rocky 8.6 vm:
OpenSSL 1.1.1k  FIPS 25 Mar 2021

On my local system (Fedora 36) where I'm running openssl to inspect the 
certs/keys:
OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)

Android version is 12 on a Pixel 6

 
Darren Boss (he/him)
Senior Programmer | Développeur Sénior
 
 
     343-341-2323


From: Paul Dekkers <paul.dekkers AT surf.nl>
Sent: Tuesday, August 16, 2022 11:56 AM
To: Darren Boss <Darren.Boss AT alliancecan.ca>
Cc: geteduroam AT lists.geant.org <geteduroam AT lists.geant.org>
Subject: Re: Problem with certificates generated 
 

You don't often get email from paul.dekkers AT surf.nl. Learn why this is 
important

Hi,

What version of OpenSSL does your Rocky server run, and what version of 
Android are you testing with?

Regards,
Paul


On 16/08/2022 17:12, Darren Boss (via geteduroam Mailing List) wrote:
I've been able to setup the portal app without too much trouble but while 
testing with Android it wasn't working and I started looking closely at the 
assets downloaded manually from the portal. The PKCS12 button generates a 
file that when I try inspecting with openssl, shows this error:
Error outputting keys and certificates
401C6D75A67F0000:error:0308010C:digital envelope 
routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:349:Global
 default library context, Algorithm (RC2-40-CBC : 0), Properties ()

When using the -legacy flag, I can convert the format and even get my profile 
working with a Linux laptop and our appropriately configured freeradius 
server.

The certs in the mobileconfig are using this cipher as well if I copy out the 
base64 encoded string, decode, and inspect with openssl from the command line.

The vm running the portal app is running Rocky 8.6 and PHP 7.4 from the Rocky 
repos. Is the error I see in the manual downloads unusual? Any tips for doing 
further debugging or thoughts about what I'm seeing? I'm thinking of 
deploying on a Debian based vm just to see if the behavior is different.

Darren Boss (he/him)
 
Senior Developer | Développeur Senior


 
darren.boss AT alliancecan.ca
 
343-341-2323
 
0000-0001-7588-9500 
alliancecan.ca