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

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

Hello,

oh dear. This appears to be AddTrust all over again. I had hoped this
problem had withered out over time. The issue has been brought up four
or five times now and is mighty annoying.

I'm pasting below a post from 2015 with a very similar or even the exact
problem, depending on how InCommon's chain building is done from the
AddTrust External CA Root.

The core of the issue is that there is an intermediate CA certificate
which hasn't always been an intermediate. It used to be a self-signed
root, but then during some company merger was re-issued as an
intermediate under AddTrust.

Windows devices which have the self-signed variant installed fall over
if they see the identical certificate as an intermediate in their EAP
conversation.

The self-signed variant is not shipped in all Windows installs (Windows
has an updater for its trust store and this may or may not have been
dynamically added in the device you test with).

Can you take a look at the system trust store of this particular Win 10
device and see if any of the intermediates in the chain (as sent in the
EAP conversation) are registered as root CAs in the system? If so, does
removing the root variant help?

Greetings,

Stefan Winter

-------- Weitergeleitete Nachricht --------
Betreff: Re: [cat-users] problem detected with installer from
cat.eduroam.org
Datum: Wed, 21 Jan 2015 15:53:58 +0000
Von: Louis Twomey <louis.twomey AT heanet.ie>
An: cat-users AT geant.net, stefan Winter <stefan.winter AT restena.lu>

This is perhaps the same problem that I have encountered with Windows
7 and 8 machines locally.

I replaced our Radius server cert recently, both new and old certs
were from TCS, the new one is signed by "TERENA SSL CA 2". All
existing wireless supplicants handled the new cert without incident,
except for Windows 7 and 8 devices. They consistently failed on
certificate verification.

When I looked into it I discovered that the chaining on those Windows
devices was broken, they chained my cert as follows:

  USERTrust RSA Certification Authority > TERENA SSL CA 2 >
eduroam-idp.heanet.ie

That "USERTrust RSA Certification Authority" is a root cert, so as
such the chain is complete but it doesn't match the chain the client
is configured to expect, which is:

  AddTrust External CA Root > USERTrust RSA Certification Authority >
TERENA SSL CA 2 > eduroam-idp.heanet.ie

When I checked the local Windows certificate store on a problem
device, it had 2 certificates with the same name of "USERTrust RSA
Certification Authority", one is the root cert, the other is the
intermediate CA cert that TCS uses, it is choosing to chain via the
root one. Deleting or disabling the root USERTrust cert in the local
store solves the problem, the client chains correctly and server
validation succeeds.

So the issue is this extra(?) root cert, it exists on each of the 5
Windows laptops I have looked at here and they all chain to it. I
assume that either this root cert doesn't exist on *every* Windows
laptop, or perhaps is there but is not chained to on every such device
- otherwise eduroam connectivity would, I presume, be failing for any
Windows device where the home site uses a cert signed by the new TCS
chain.

Does anyone else have that root cert in the Third-Party Root
Certificates store of their Windows device I wonder?  These are the
details of the cert:

 Version:  V3
 Serial number:  01 fd 6d 30 fc a3 ca 51 a8 1b bc 64 0e 35 03 2d
 Signature algorithm:  sha384RSA
 Signature hash algorithm:  sha384
 Issuer:  USERTrust RSA Certification Authority
 Valid from:  01 February 2010 00:00:00
 Valid to:  18 January 2038 23:59:59
 Subject:  USERTrust RSA Certification Authority
 Public key:  RSA (4096 Bits)
 Subject key Identifier:  53 79 bf 5a aa 2b 4a cf 54 80 e1 d8 9b c0 9d
f2 b2 03 66 cb
 Key Usage:  Certificate Signing, Off-line CRL Signing, CRL Signing (06)
 Basic Constraints:  Subject Type=CA, Path Length Constraint=None
 Thumbprint algorithm:  sha1
 Thumbprint:  2b 8f 1b 57 33 0d bb a2 d0 7a 6c 51 f7 0e e9 0d da b9 ad 8e
 Friendly name:  USERTrust

Regards,
Louis.

On 21/01/2015 12:21, Stefan Winter wrote:
> Hi,
>
>> just two comments... Stefan, please note that Marcos is from
>> esci.upf.edu, not upf.edu (two different organizations).
>
> Okay. Sorry for being confused :-)
>
>> I explained Marcos that the SecureW2 installer is only used for
>> Win XP, and it should'nt be used by default for win 7 and 8.x
>> (if PEAP+MSCHAPv2 is selected as first option as is the case)...
>> am I right?
>>
>> Of course you could use it in further windows versions too, but
>> given the priority of methods allowed in the profile and their
>> order (1. PEAP-MSCHAPv2, 2. TTLS-MSCHAPv2, 3. TTLS+PAP), I guess
>> the installer for win 7 and win 8.1 is not based on SecureW2...
>
> Yes, with that priority, Vista and above would not trigger
> SecureW2 installation.
>
> And the built-in supplicant which is then used is of course bound
> to Microsoft's built-in TLS validation routines... which are on the
> SHA-1 sunset crusade.
>
>> Also I have to say, I checked this morning and the profile looked
>> fine to me.
>
> Maybe he is still sending the (superfluous) old TERENA intermediate
> CA and Microsoft is (unrightfully) upset about that. Or he is
> missing the second intermediate (IIRC) and the supplicants can't
> complete the chain.
>
> Stefan
>

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

Attachment: signature.asc
Description: OpenPGP digital signature