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

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

Hello,

> Maybe we misunderstood each other, let me clarify...
> 
> The certificate that's presented when connecting on an apple device is not 
> a "bogus" certificate.
> Rather, it's the "intermediate" certificate in the chain.
> While on a PC, the top level root certificate is correctly presented.
> 
> In the attached screenshot, you'll see that the highlighted (2nd in line) 
> certificate is presented on OSX.
> While connecting on a PC, the top certificate (1st in line) is the one 
> being presented to the user.
> 
> With that in mind, any idea what may be causing this issue?

I don't understand: the screenshot shows the chain with root,
intermediate and server cert properly in a row. The only mildly strange
point about it is that the middle one is selected by default.

I do see an issue: the intermediate CA is the "old" instance of TERENA
TCS. That CA signed its certificates with SHA-1 and many client OSes do
not accept such certificates any more.

Maybe OS X thinks it knows that the server cert isn't good anymore, and
suggests to manually trust the intermediate instead? And that's why it's
highlighting the intermediate?

You should really get a certificate with proper SHA-256 signature from
the new iteration of TCS, and see if this works better. This is a
DigiCert root CA.

Yes, this means you'll have to roll out new profiles with a new root CA.
There is going to be significant amount of pain ahead for you. If it
helps: you would have needed to do that in the near future anyway,
because your server cert with the old service will expire at some point
anyway...

Sorry for the bad news, and no, this was not an April's fool. :-(

Greetings,

Stefan Winter

> 
> / Marcus
> 
> 
> 
> 
> 
> 
> Den 2016-04-01 15:11 skrev "Stefan Winter" 
> <stefan.winter AT restena.lu>
>  följande:
> 
>> Hello,
>>
>>> The problem occurs when the user tries to authenticate on an apple device.
>>> For some reason, the user is presented with a different certificate (not
>>> the one in the profile) for the authentication server.
>>> Thereby the identity of the authentication server can't be verified.
>>
>> If your devices get to see a bogus certificate then that's really not
>> CAT's fault. In fact, the main purpose of the CAT profiles is to ensure
>> that the device *won't* connect in presence of such a bogus cert. An
>> alert message is absolutely intentional then.
>>
>> You should investigate where this incorrect certificate comes from.
>> Maybe someone is setting up a rogue access point - and then you should
>> be happy that proper CAT profiles prevented this from working for the
>> attacker.
>>
>>> Have you guys updated CAT recently?, ´cause it seems that the latest CAT
>>> is incompatible with OSX and iOS.
>>
>> There were no changes in the last few months.
>>
>> 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


-- 
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: 0x8A39DC66.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature