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

[Jethro R Binks <jethro.binks AT strath.ac.uk>]

On Wed, 31 Oct 2018, IAM David Bantz wrote:

> How are other institutions getting around this issue? In my scan for 
> Universities' eduroam onboading documentation I saw a couple emphasize 
> strongly that Windows be fully updated / patched before running the CAT 
> installers; is that in some way related and a mitigation of this 
> problem?

In our case, and a fair few others, don't use a commercial CA at all.  It 
provides no additional benefit, and introduces the potential for problems.

Create your own self-signed CA root cert with a very long lifetime 
(20yrs?).  Use it to sign the certificate installed on the radius server 
with a moderate lifetime (5 yrs?).  Give CAT your CA cert and tell it the 
name in your radius server cert.

Having done that, you are no longer bound to the vagaries of the 
commercial certificate market and operating systems.  And re-issuing 
radius server certs when it does expire doesn't require changes to CAT, 
since your new cert will be signed by the same root it trusts, and have 
the same name (in theory, not actually done it yet!).

But, the prep and transition can be quite long and painful.

Jethro.



> 
> Thank you for ongoing insight and assistance.
> 
> David Bantz
> U Alaska
> 
> On Wed, Oct 31, 2018 at 12:02 AM Stefan Winter <stefan.winter AT restena.lu>
> wrote:
> 
> > 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
> > >
> >
> >
> To unsubscribe, send this message: 
> mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
> Or use the following link: 
> https://lists.geant.org/sympa/sigrequest/cat-users
> 

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.