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

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

Hi,

there's an odd story behind this particular intermediate CA that TCS uses.

The certificate used to be a self-signed root, with its home being the
Root CA Trust Store. At some point, the CA operators decided to re-issue
the certificate (same public key, same CN) but to sign it from a
different root, making it an intermediate, with no place at all in trust
stores.

We positively know that Mac OS / iOS machines which errorneously still
have the certificate as a self-signed root in their trust store refuse
to accept certificates which expect the same certificate as an
intermediate, even if all the crypto matches and the intermediate cert
comes in via EAP. As a particularly unlucky regression bug, the cert was
re-added at a later iOS when it was already gone earlier.

The solution for Mac / iOS (repeatedly posted on this list) is to
install the now-intermediate certificate in the end system config, i.e.
include it in your CAT setup. That way, the proper rooting to the other
root CA worked on those OSes.

I am not aware of Windows having the same issue; but I'm also not aware
of anyone (still?) having this certificate as a trusted root. It's been
a few years that the re-signing happened and the root version of the
cert is supposedly history.

You mention that the machines which have this cert as a root have it in
their Third-Party Trust Store. That would suggest it was indeed not
shipped in Windows, but "someone/something" added it at some point in
time. This could be an earlier eduroam installation dating back before
the re-signing event or something completely different.

In that case, deleting the root cert from the Third-Party trust would be
a per-machine remedy. You could also double-check if your CAT config
includes this cert in its intermediate version, and if not, see if
adding it helps those machines form their trust chain.

In any event, it is very bad luck that the TCS chain was affected by
this. In theory, re-signing a cert is possible; and in theory, both the
self-signed trust root and the intermediate (with the new root
installed) should work just fine.

In practice, many TCS setups are borked by that :-(

Sorry for not having an exact timestamp on when that re-signing
happened. I'm not a TCS customer myself and didn't have to fight with
this back in the day. I only came across it when the iOS regression
issue hit this list.

Greetings,

Stefan Winter

On 21.01.2015 16:53, Louis Twomey wrote:
> 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: signature.asc
Description: OpenPGP digital signature