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

[Louis Twomey <louis.twomey AT heanet.ie>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks Stefan. Up until now I've assumed that this issue was local to
my own users, that perhaps we have an old or broken certificate store
on our Windows machine for some odd reason peculiar to us (which
sounds likely), but I wondered if Marcos was hitting the same issue as
the symptoms sound very similar.

The (new) profile installed on these Windows machines does indeed have
the new intermediate CA's bundled with it, but that didn't solve the
problem, so deleting or disabling the old root cert per machine looks
like the only reliable fix, unfortunately.

I've also just checked one of the other problem machines and it has
that old root cert in the Trusted Root Certification Authorities
store, suggesting it was bundled with the O/S. Maybe all of these
machines have been upgraded to Win 7/8, rather than being fresh
installs, perhaps Microsoft's current standard certificate store
excludes that old root cert?

Regards,
Louis.

On 21/01/2015 17:00, Stefan Winter wrote:
> 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
>> 
>> 
> 
> 

- -- 
HEAnet Limited                               
louis.twomey AT heanet.ie
5 George's Dock, IFSC, Dublin 1              Tel: +353-1-6609040
Web: http://www.heanet.ie                    Fax: +353-1-6603666
Registered in Ireland, no 275301             PGP key: C77D9256

- --- Please consider the environment before printing this e-mail ---
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlS/4I4ACgkQJBvGwcd9klbBbgCfU6GrDo07KObOJMTe3OZtKjWs
TcYAoM3F6DIwwBNBr7cwdUOcw3lA7997
=svdF
-----END PGP SIGNATURE-----