Skip to Content.

geteduroam - Re: geteduroam odd behaviour on Android 10?

Subject: An open discussion list for topics related to the geteduroam service

List archive

Re: geteduroam odd behaviour on Android 10?

Chronological Thread 
  • From: Paul Dekkers <paul.dekkers AT>
  • To: Stefan Paetow <Stefan.Paetow AT>
  • Cc: "geteduroam AT" <geteduroam AT>
  • Subject: Re: geteduroam odd behaviour on Android 10?
  • Date: Tue, 8 Dec 2020 21:59:16 +0100


I just started an Android 10 phone (Samsung Galaxy S10) in the debugger to
see if I spot anything with the installation of Bath Spa University - but for
me it just seems to work. Obviously, I didn’t have a correct username and

What brand of Android 10 phone is this, do you know? Is it possible for me to
test with valid credentials?

BTW, testing with the emulator doesn’t really work well, as Android doesn’t
emulate Wi-Fi hardware properly.

Not relevant, I think, but:

I see this institution actually also sends the root certificate over the EAP
conversation - not necessary. Shouldn’t be a trigger for these issues either.

It also appears to be an EV certificate. That can also be a reason for
problems at least on ChromeOS. So unlikely to affect Android ;-)


> On 8 Dec 2020, at 21:04, Stefan Paetow <geteduroam AT> wrote:
> The entire chain is shipped with the EAP handshake (I know, not ideal), but
> the ultimate root *should* suffice.
> I refer to this part in the IdP guide (verbatim):
> "For most EAP methods, the required EAP details are
> The Certification Authority (CA) certificate(s) which signed your EAP
> server certificate
> always include the root CA (root CAs are indicated with a blue circled "R"
> besides the certificate details after upload)
> optionally include intermediate CAs (intermediate or server certificates
> are indicated with a blue circled ("I") besides the certficate after upload)
> The name of your server as specified in the Common Name (CN) of your EAP
> server certificate"
> I've done a check and yes, the CA root cert on the server and the CA root
> cert on CAT match (as per Martin), and openssl verifies the chain ok:
> [support:~] openssl verify -CAfile bspa-root.crt -untrusted bspa-interm.crt
> bspa-srv.crt
> bspa-srv.crt: OK
> So no, it's not the chain, because actual authentications would have failed.
> With Regards
> Stefan Paetow
> Federated Roaming Technical Specialist
> t: +44 (0)1235 822 125
> gpg: 0x3FCE5142
> xmpp: stefanp AT
> skype: stefan.paetow.janet
> In line with government advice, at Jisc we’re now working from home and our
> offices are currently closed. Read our statement on coronavirus
> <>.
> Jisc is a registered charity (number 1149740) and a company limited by
> guarantee which is registered in England under Company No. 5747339, VAT No.
> GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill,
> Bristol, BS2 0JA. T 0203 697 5800.
> On 08/12/2020, 15:39, "geteduroam-request AT on behalf of
> Paul Dekkers" <geteduroam-request AT on behalf of
> geteduroam AT> wrote:
> Hi,
> Ah, in that case it looks like the intermediate certificate is missing?
> This contains just the/a QuoVadis root.
> Thanks for checking on the profile, I didn’t get to that yet,
> (I doubt this profile works well in CAT?)
> Regards,
> Paul
>> On 8 Dec 2020, at 16:24, Martin Pauly <geteduroam AT> wrote:
>> Am 08.12.20 um 16:07 schrieb Stefan Paetow (via geteduroam Mailing List):
>>> The profile is correct. They use a root certificate.
>> This one?
>> ...
>> --
>> Dr. Martin Pauly Phone: +49-6421-28-23527
>> HRZ Univ. Marburg Fax: +49-6421-28-26994
>> Hans-Meerwein-Str. E-Mail: pauly AT HRZ.Uni-Marburg.DE
>> D-35032 Marburg

Archive powered by MHonArc 2.6.19.

Top of Page