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

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

Hi,

well, it would have helped more if you'd also send the server
certificate - then I could see for myself which of the intermediate CAs
signed the server cert.

But anyway, I think I know where the problem lies:

TERENASSLCA.crt is signed with SHA-1, and expires in 2020. Microsoft
enforces the phase-out of SHA-1 signatures for certificates with an
expiry in 2017+ since this year. My guess is that the (old) TERENA
Intermediate CA is rejected by Microsoft's TLS implementation, and that
your server certificate is issued by that old CA still.

In effect, the server cert validation would fail.

Funny enough, you also have the new TERENA Intermediate CA which is
signed with SHA-384 - which passes validation.

An obvious solution to the problem would then be to renew your server
certificate so that it gets issued from the new intermediate CA (or if
it already was, a re-issue may still be required because server
certificates were still signed with sha1 until early 2014, see below).

You must have missed the corresponding call for action on various TERENA
mailing lists, e.g. here:
https://www.terena.org/mail-archives/tf-emc2/msg02600.html

I wasn't aware that validation also fails for EAP authentication
purposes, the Microsoft Knowledge Base article wasn't totally clear on
that. With this evidence, it seems like this is the case.

Hm, CAT 1.1 will currently warn you if your cert is still MD5 signed,
but not if it's SHA-1 signed.

Could you please really send me your server cert; and verify if a
re-issue with sha256 or sha384 signature fixes the validation issue? If
so, we can trivially add another warning for version 1.1 which would
tell you that server or intermediate certs with SHA-1 aren't good any
more...

Greetings,

Stefan Winter


On 21.01.2015 12:34, marcos gonzalez wrote:
> Hi
> 
> I did more checks. Now I discovered how I have 2 different CA
> certificates, first from last certificate (TERENASSLCA.crt), and other
> new with new certificate (TERENASSLCA2). I attach.
> 
> I don't know which are installed with official installer. The problem
> now seems to be how the certificate can't check correctly and I don't
> know how to prepare the correct CA.
> 
> Thanks
> 
> El 21/01/15 a las 12:19, Stefan Winter escribió:
>> Hi,
>>
>>> We are writing to report a problem detected with our users.
>>>
>>> We are offering the installer from cat.eduroam.org website, and since
>>> January we detected how windows 7 and 8.1 pcs connection fails, curiosly
>>> If you use mac (version 10.10) or android mobiles, you can connect.
>>> Using SecureW2 client last version you can connect in Windows clients
>>> and our national support service confirm us how client used by eduroam
>>> was GPL version. We are checking how can be possible this, but now the
>>> users can't connect and we need support to confirm the problem and
>>> repair official installer. Was anyone reporting this problems?
>> I haven't heard any report to that effect.
>>
>> Did the problem start on Jan 1? It's not impossible that Microsoft may
>> be enforcing new certificate requirements, and that your server or
>> intermediate CA certificate does not meet those new requirements.
>>
>> If you use a different version of SecureW2 that may or may not hint to a
>> problem with our version - maybe the users who try that new version
>> simply do not enable the certificate checks properly in their manual
>> configuration.
>>
>> It would be helpful if you could send me the server certificate and CA
>> certificate(s) by mail so I could take a closer look. Because I don't
>> get any certificate out of the EAP conversation for @upf.edu - maybe you
>> are using a Microsoft RADIUS server and it doesn't like my outer 
>> identity...
>>
>> Greetings,
>>
>> Stefan Winter
>>
> 


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

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