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

[Stefan Winter <stefan.winter AT restena.lu>]

Hello,

for the benefit of the mailing list:

this condition is indeed a bit out of the ordinary. It is related to a
server which has problems accepting outer identities with an empty
username part (i.e. "@restena.lu" instead of "anonymous AT restena.lu") -
and CAT happens to test with an outer username of @something by default.

These misconfigurations exist more often, but almost always the request
is rejected immediately, before the actual EAP conversation starts. That
is a condition we check for and display appropriately.

Here, the server first accepts the access request, negotiates PEAP,
starts TLS ClientHello/ServerHello exchange, and only when asked by the
client to present its server certificate, it sends a Reject instead.

We were /not/ prepared to be sent away during an ongoing TLS handshake
before any certificate is even exchanged.

I have now fixed this in code, and version 2.0.1 will conclude end-user
diagnostics correctly and attribute the failure to produce a server
certificate as an IdP error.

We are also currently fixing the UI of the administrator-side realm
checks so that they also display this error condition correctly in the
future.

Greetings,

Stefan Winter

Am 02.04.19 um 09:44 schrieb Stefan Winter:
> Hello,
> 
> I can reproduce the problem. It appears that this happens only with the
> realm "uit.no": If you run a test for "uninett.no", U.S.A., Georgetown
> University then the system will correctly identify that there is no
> infrastructure problem with this combination and will continue with
> user-interactive questions for further diagnosis.
> 
> Looking at uit.no, this falls over not only for diagnostics, but also
> inside the admin-only realm checks. The failure there is more subtle
> though: you get a result stating:
> 
> "Test partially successful: a bidirectional RADIUS conversation with
> multiple round-trips was carried out, and ended in an Access-Reject as
> planned. Some properties of the connection attempt were sub-optimal; the
> list is below."
> 
> But then there is no "below"; the list of warnings is not populated.
> 
> So, there is something special about uit.no, but a variety of special
> that we haven't encountered before.
> 
> From a first look, this would be a certificate issue (either there is
> something wrong with the certificate, or our parser misinterprets the
> potentially good certificate).
> 
> I am investigating this issue right now and hope to be able to come back
> with more concrete results soon.
> 
> Greetings,
> 
> Stefan Winter
> 
> Am 01.04.19 um 13:54 schrieb Anders Baardsgaard:
>> Hi,
>>
>> one of our researchers is currently visiting Georgetown University, USA,
>> and he's having problems with eduroam. He writes that he receives an
>> error message on Eduroam Diagnostics Site, when writing UiT.no as the
>> host institution: magicTelepath error
>>
>> I asked  Uninett for advice, and the conclusion is that something is
>> wrong with cat.eduroam.org:
>>
>> [Error] Failed to load resource: the server responded with a status of
>> 500 (Internal Server Error) (magicTelepath.php, line 0)
>>
>> https://cat.eduroam.org/diag/magicTelepath.php?realm=uit.no&lang=en&visited=0
>>
>> At this point I have left my home ground wrt. knowledge. Any advice?
>>
>>  -- Anders
>>
>> --
>>
>> Anders Baardsgaard
>>
>> Senioringeniør Infrastruktur, Grunntjenester, IT-avd
>>
>> UiT - Norges arktiske universitet
>>
>>
>> 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
> 
> 


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

Attachment: 0xC0DE6A358A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature