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

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

Hi,

thanks for the heads-up. So, did the changes actually resolve your problem?

Stefan

Am 21.02.19 um 13:55 schrieb Blair T. Sawler:
> 
> Tests run, here are the results:
> 
> DNS checks:
> Checking NAPTR existence: This realm has no NAPTR records.
> 
> Realm is STATIC with no DNS errors encountered. Congratulations!
> 
> Static connectivity tests
> All tests passed. See the appropriate tab for details.
> 
> STATIC connectivity tests
> This check sends a request for the realm through various entry points of 
> the roaming consortium infrastructure. The request will contain the 
> 'Operator-Name' attribute, and will be larger than 1500 Bytes to catch two 
> common configuration problems.
> Since we don't have actual credentials for the realm, we can't authenticate 
> successfully - so the expected outcome is to get an Access-Reject after 
> having gone through an EAP conversation.
> 
>  
> 
> Testing from: eduroamTL dk
>       Connected to wireless.unb.ca.
> elapsed time: 15009 ms.
> 
> Test successful: a bidirectional RADIUS conversation with multiple 
> round-trips was carried out, and ended in an Access-Reject as planned.
>       
> 
> Subject:
>     CN=wireless.unb.ca
> Issuer:
>     CN=RapidSSL TLS RSA CA G1,OU=www.digicert.com,O=DigiCert Inc,C=US
> Valid from:
>     Thursday, 19-Jul-2018 00:00:00 GMT
> Valid to:
>     Friday, 08-Nov-2019 12:00:00 GMT
> Serial number:
>     14894444895693116238421154690280235681 (0x7FFFFFFFFFFFFFFF)
> SHA1 fingerprint:
>     7c5fd0dc6d50e1d123b82e5f292c00e359a5cc01
> Extensions
>     authorityKeyIdentifier: 
> keyid:0C:DB:6C:82:49:0F:4A:67:0A:B8:14:EE:7A:C4:48:52:88:EB:56:38 
>     subjectKeyIdentifier: 
> BA:04:47:15:09:36:C8:B1:A8:22:B9:21:17:FC:21:EE:83:A0:7C:F8
>     subjectAltName: DNS:wireless.unb.ca
>     keyUsage: Digital Signature, Key Encipherment
>     extendedKeyUsage: TLS Web Server Authentication, TLS Web Client 
> Authentication
>     crlDistributionPoints: Full Name: 
> URI:http://cdp.rapidssl.com/RapidSSLTLSRSACAG1.crl 
>     certificatePolicies: Policy: 2.16.840.1.114412.1.2 CPS: 
> https://www.digicert.com/CPS Policy: 2.23.140.1.2.1 
>     authorityInfoAccess: OCSP - URI:http://status.rapidssl.com CA Issuers - 
> URI:http://cacerts.rapidssl.com/RapidSSLTLSRSACAG1.crt 
>     basicConstraints: CA:FALSE
>     ct_precert_scts: Signed Certificate Timestamp: Version : v1(0) Log ID : 
> A4:B9:09:90:<<<rest deleted>>>
> 
> «
> 
> Testing from: eduroamTL nl
>       Connected to wireless.unb.ca.
> elapsed time: 15011 ms.
> 
> Test successful: a bidirectional RADIUS conversation with multiple 
> round-trips was carried out, and ended in an Access-Reject as planned.
>       show server certificate details»
> 
> Also tried the live login tests with PEAP-MSCHAPv2:
> 
> PEAP-MSCHAPv2 – elapsed time: 3106 ms.
> Connected to wireless.unb.ca.
> 
> Test successful.
>       
> 
> Server certificate details:
> 
> Subject:
>     CN=wireless.unb.ca
> Issuer:
>     CN=RapidSSL TLS RSA CA G1,OU=www.digicert.com,O=DigiCert Inc,C=US
> Valid from:
>     Thursday, 19-Jul-2018 00:00:00 GMT
> Valid to:
>     Friday, 08-Nov-2019 12:00:00 GMT
> Serial number:
>     1489444489569311:<<<rest deleted>>>
> SHA1 fingerprint:
>     7c5fd0dc6d50e1d123b82:<<<rest deleted>>>
> Extensions
>     authorityKeyIdentifier: keyid:0C:DB:6C: :<<<rest deleted>>>.
> 
> -Blair
> 
> -----Original Message-----
> From: Blair T. Sawler 
> Sent: January 28, 2019 8:56 AM
> To: 'Stefan Winter' <stefan.winter AT restena.lu>; cat-users AT lists.geant.org
> Subject: RE: [[cat-users]] Android CAT Issues
> 
> I'll get them to give that a try.
> 
> Thank-you
> 
> -Blair
> 
> -----Original Message-----
> From: Stefan Winter <stefan.winter AT restena.lu>
> Sent: January 28, 2019 5:21 AM
> To: Blair T. Sawler <blair.sawler AT unb.ca>; cat-users AT lists.geant.org
> Subject: Re: [[cat-users]] Android CAT Issues
> 
> Hi,
> 
>> The analysts found a disparity between the internal and external 
>> radius servers. The profile has been updated, but we’re still having 
>> the same issues with Android not connecting. Any suggestions would be very 
>> helpful.
> 
> That looks a lot better now, indeed.
> 
> With this change in effect, can you now run the "Check Realm Reachability" 
> again and see if it has any warnings or advice regarding intermediate CAs?
> 
> Greetings,
> 
> Stefan Winter
> 
>>
>> Thanks
>>
>> -Blair
>>
>>  
>>
>> ----------------------------------------------------------------------
>> --
>>
>> *From:*Blair T. Sawler
>> *Sent:* Friday, January 18, 2019 2:21:28 PM
>> *To:* Stefan Winter; cat-users AT lists.geant.org 
>> <mailto:cat-users AT lists.geant.org>
>> *Subject:* RE: [[cat-users]] Android CAT Issues
>>
>>  
>>
>> Hi
>>
>> Thanks for the replies, I've passed it on to the network and systems 
>> teams, I'll let you know.
>>
>> -Blair
>>
>> -----Original Message-----
>> From: Stefan Winter <stefan.winter AT restena.lu 
>> <mailto:stefan.winter AT restena.lu>>
>> Sent: January 18, 2019 10:39 AM
>> To: Blair T. Sawler <blair.sawler AT unb.ca 
>> <mailto:blair.sawler AT unb.ca>>; cat-users AT lists.geant.org 
>> <mailto:cat-users AT lists.geant.org>
>> Subject: Re: [[cat-users]] Android CAT Issues
>>
>> Hello,
>>
>> my bad for giving you a canned answer without getting to the bottom of 
>> things first, sorry.
>>
>> The issue is a different one.
>>
>> In CAT, you configured the following two CAs:
>>
>> 1) root CA
>>
>> Subject: C = US, O = DigiCert Inc, OU = www.digicert.com 
>> <http://www.digicert.com>, CN = DigiCert Global Root G2
>>
>> 2) intermediate CA (irrelevant for Android installers, but anyway)
>>
>> Subject: C = US, O = DigiCert Inc, OU = www.digicert.com 
>> <http://www.digicert.com>, CN = RapidSSL TLS RSA CA G1
>>
>> However, looking at your actual EAP conversation, I see that the 
>> RADIUS server is sending the following server cert and intermediate:
>>
>> Server:
>>
>> Issuer: C = US, O = DigiCert Inc,OU = www.digicert.com 
>> <http://www.digicert.com>, CN = RapidSSL RSA CA 2018
>> Subject: wireless.unb.ca
>>
>> Intermediate:
>> Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com 
>> <http://www.digicert.com>, CN = DigiCert Global Root CA
>> Subject: C = US, O = DigiCert Inc, OU = www.digicert.com 
>> <http://www.digicert.com>, CN = RapidSSL RSA CA 2018
>>
>> As you can see, the server cert's chain is NOT ending in the root CA 
>> you configured in CAT (... Global Root *CA* vs.. Global Root *G2*).
>>
>> It is not surprising and actually intentional that Android refuses to 
>> authenticate against this (unknown, and from its POV possibly rogue) 
>> server.
>>
>> To be honest, the bigger question which startles me somewhat is: why 
>> is this NOT an issue in all the other operating systems?
>>
>> Would you happen to be aware of any special CA cross-signing going on 
>> in those CAs, which fixes this for operating systems knowing about the 
>> cross-signed variants?
>>
>> Greetings,
>>
>> Stefan Winter
>>
>> Am 18.01.19 um 14:12 schrieb Stefan Winter:
>>> Hello,
>>>
>>>> We’ve migrated our Wi-Fi at the University of New Brunswick (Canada) 
>>>> to eduroam only. We’re trying to streamline connectivity for our 
>>>> faculty/staff and students and have been promoting the eduroam CAT.
>>>> We’re having issues with the app on Android.
>>>>
>>>> If you set it up on the device, it just continually tries to connect.
>>>> Once you stop, and then go in to the wireless settings on the 
>>>> device, you can connect, if you do not validate the certificate.
>>>>
>>>> It works for all other operating systems. Has anyone else had this 
>>>> issue, and if so, were you able to resolve it?
>>>>
>>>> We are using PEAP with Pase2:MSCHAPv2.
>>>>
>>>> I’m asking on behalf of my team, so if you get too technical, I’ll 
>>>> pass on the question 😊
>>>
>>> Your server certificate is issued by an intermediate CA, which in 
>>> turn ends in a root CA.
>>>
>>> For Android, it is only possible to load root CAs onto the device, 
>>> not intermediates.
>>>
>>> The intermediate is however /required/ for certificate validation to work.
>>>
>>> The only way to make this happen is by making sure the RADIUS server 
>>> sends that intermediate certificate during the EAP exchange. If it is
>>> *only* sending the server certificate, the behaviour you describe occurs.
>>>
>>> If that's the issue, then you should have a corresponding warning in 
>>> the admin area of CAT when running the realm reachability tests. Is
>> that so?
>>>
>>> Greetings,
>>>
>>> Stefan Winter
>>>
>>
>>
>> --
>> 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
>>
>> 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
> 


-- 
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