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

[Hunter Fuller <hf0002 AT uah.edu>]

YES! It did solve the problem! Thank you so much!

I also did not realize what I was looking at, with regards to the "R"
and "I" indicators next to the certs in the CAT interface. This would
have given it away a lot sooner... so that is my mistake.

All is working well now, so thanks again!

--
Hunter Fuller
Router Jockey
VBH Annex B-5
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering

On Wed, Jul 10, 2019 at 12:47 AM Stefan Winter <stefan.winter AT restena.lu> 
wrote:
>
> Hello,
>
> sorry, I must have gotten lost in the forest of variants how to reach a
> root.
>
> I believe the correct thing to say is that the intermediate you have -
> USERTrust RSA Certification Authority - CAN be chained up to a root but
> SHOULD NOT: there is an alternative version of that CA which is itself a
> root.
>
> I found out about this only by a SSL cert observatory. It lists your
> intermediate as an intermediate just fine:
>
> https://www.tbs-certificates.co.uk/FAQ/en/USER-Trust-RSA-Certification-Authority.html
>
> but with the comment: "If you are looking for the root version of this
> certificate, you can find it here.":
>
> https://www.tbs-certificates.co.uk/FAQ/en/racine-USERTrustRSACertificationAuthority.html
>
> So, you should probably upload that latter root version of "USERTrust
> RSA Certification Authority" instead of the intermediate variant.
>
> That should work much better.
>
> But note that this is not really a CAT problem, and InCommon cert
> service support would be able to advise you on the correct use of
> InCommon cert chains much better than I can. I'm surprised that the info
> about this alternative root is not on that same wiki page.
>
> Greetings,
>
> Stefan Winter
>
>
> Am 09.07.19 um 22:10 schrieb Hunter Fuller:
> > Stefan,
> >
> > I clicked the letters "DER" next to "USERTrust Secure" and uploaded
> > only that certificate. CAT still shows the message.
> >
> > --
> > Hunter Fuller
> > Router Jockey
> > VBH Annex B-5
> > +1 256 824 5331
> >
> > Office of Information Technology
> > The University of Alabama in Huntsville
> > Network Engineering
> >
> > On Thu, Jun 13, 2019 at 1:36 AM Stefan Winter <stefan.winter AT restena.lu> 
> > wrote:
> >>
> >> Hello,
> >>
> >> sorry for the late reply.
> >>
> >> You have probably uploaded the intermediate CA, not the root one. The
> >> root CA is required while intermediates are optional.
> >>
> >> You can find the root CA on the web page I mentioned earlier:
> >>
> >> https://spaces.at.internet2.edu/display/ICCS/InCommon+Cert+Types
> >>
> >> There is a link [DER] besides the "USERTrust Secure". The root CA cert
> >> is behind that link.
> >>
> >> Greetings,
> >>
> >> Stefan Winter
> >>
> >> Am 29.05.19 um 22:41 schrieb Hunter Fuller:
> >>> Stefan,
> >>>
> >>> Thank you so much for the info. It makes perfect sense. I totally
> >>> failed to find that mailing list post myself.
> >>>
> >>> I have input those two certs, though, and CAT is showing this message:
> >>> "Information needed! CA Certificate File"
> >>> It's acting like I have no root loaded - but the only other root I
> >>> could load is the AddTrust one, which seems to be the source of our
> >>> problems.
> >>>
> >>> Where can I find the root for the recommended chain?
> >>>
> >>> --
> >>> Hunter Fuller
> >>> Router Jockey
> >>> VBH Annex B-5
> >>> +1 256 824 5331
> >>>
> >>> Office of Information Technology
> >>> The University of Alabama in Huntsville
> >>> Network Engineering
> >>>
> >>> On Tue, May 21, 2019 at 1:41 AM Stefan Winter 
> >>> <stefan.winter AT restena.lu> wrote:
> >>>>
> >>>> Hello,
> >>>>
> >>>>> I have a new Windows 10 machine that will connect to eduroam just fine
> >>>>> if I verify our cert's fingerprint manually, instead of using CAT.
> >>>>> When I install CAT, the network configuration is added, but as soon as
> >>>>> I click Connect, "Can't connect to this network" is displayed under
> >>>>> the SSID name in the menu.
> >>>>>
> >>>>> Does anyone have any tips for collecting data about why the failure is
> >>>>> happening? Since I am also one of our realm administrators, I was able
> >>>>> to look on our RADIUS server logs. The client is sending what it calls
> >>>>> a "TLS alert message" and thus the connection is rejected.
> >>>>>
> >>>>> I know I have loaded our root and intermediates correctly because the
> >>>>> CAT works fine on other OSes (iOS and Linux are the ones I have access
> >>>>> to, and have tried).
> >>>>>
> >>>>> Is there any place in Windows I can find more information about why
> >>>>> it's failing, or is there anywhere else I can check? Any pointers
> >>>>> would be appreciated.
> >>>>
> >>>> You are using an InCommon server certificate and have specified 
> >>>> AddTrust
> >>>> as the root certificate.
> >>>>
> >>>> There are Windows-internal issues with that. Please review this list 
> >>>> post:
> >>>>
> >>>> https://lists.geant.org/sympa/arc/cat-users/2018-10/msg00236.html
> >>>>
> >>>> and the InCommon wiki page detailing the expected chain to a root
> >>>> certificate:
> >>>>
> >>>> https://spaces.at.internet2.edu/display/ICCS/InCommon+Cert+Types
> >>>>
> >>>> The chain should be:
> >>>>
> >>>>     USERTrust Secure [DER]
> >>>>     InCommon RSA Server CA [DER] [PEM]
> >>>>     End-Entity Certificate
> >>>>
> >>>> The chain you use, while technically correct, isn't liked by Windows in
> >>>> some circumstances. That same wiki page links to that deprecated one as
> >>>> "Comodo's version of the chain"; the solution is to use the USERTrust
> >>>> version as outlined above.
> >>>>
> >>>> Also note that "Comodo's version of the chain" becomes entirely defunct
> >>>> in almost exactly one year from now because the root cert expires May 
> >>>> 30
> >>>> 10:48:38 2020 GMT. I.e. you have every reason to switch to the 
> >>>> alternate
> >>>> reality ASAP.
> >>>>
> >>>> Greetings,
> >>>>
> >>>> Stefan Winter
> >>>>
> >>>> --
> >>>> Stefan WINTER
> >>>> Ingenieur de Recherche
> >>>> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
> >>>> de la Recherche
> >>>> 2, avenue de l'Université
> >>>> L-4365 Esch-sur-Alzette
> >>>>
> >>>> 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
> >>> 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
> >>>
> >>
> >>
> >> --
> >> Stefan WINTER
> >> Ingenieur de Recherche
> >> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
> >> de la Recherche
> >> 2, avenue de l'Université
> >> L-4365 Esch-sur-Alzette
> >>
> >> 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
> > 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
> >
>
>
> --
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
> de la Recherche
> 2, avenue de l'Université
> L-4365 Esch-sur-Alzette
>
> 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