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

[Paul Dekkers <paul.dekkers AT surf.nl>]

Hi,

Worth sharing is that we are very close to having a geteduroam version 
available for ChromeOS. It's part of the redeveloped version for Android.

We already released it for getgovroam, we need to do some more tests and 
make some more and maybe different choices for geteduroam, but I think 
we'll try to release it soon, maybe even before the end of the year.

For ChromeOS there's two (outside of ONC) ways to install the profiles, 
and both have caveats, but I kind of like it a lot we'll be able to do 
this with geteduroam, as it appears more friendly to me compared to ONC 
or a manual config.

Regards,
Paul

P.S. I can go in a bit more detail about the challenges we still have 
for the geteduroam version, maybe I'll share in a separate post, but 
that would be a lengthy mail ;-)


On 29/11/2023 11:10, Lukas Wringer (via cat-users Mailing List) wrote:
> Hi,
>
> as Chromebooks are becomming somewhat more common I sat down to test
> some of our services if and how they work on ChromeOS for example
> eduroam.
>
> A bit of background Info:
>
> Some EAP-Methods require specific settings to be actually secure and
> are protected against fake "Rouge-APs" - For example: EAP-TTLS(PAP)
> should configure both, the Root-CA used to issue the RADIUS-Certificate
> and the (alt-)subject-match with the name of the actual RADIUS to
> match.
>
> CAT makes sure these settings are applied across all supported devices
> especially in cases like (older) Android or (modern) Apple Devices
> where these options are not exposed to the GUI.
>
> ChromeOS in this regard is confusing at best - on some devices and
> versions the required settings are actually available in the GUI on
> some they don't and one some only partially but not consistent.
>
> CAT provides an ONC-Profile that can be imported via chrome://network
> that **should** configure this values. But at least in my experience
> that is not always the case.
>
> What I have experienced so far is that if the used CA is already known
> to the system, the imported configuration will fail (which is always
> the case when using a known Trusted-CA)
>
> When using a self-signed (or not Trusted) ca-certifcate the import will
> work - if not for the other possible error when on systems that don't
> expose the corresponding values for CA-Verfication and (alt)subject-
> match.
>
> Now comes the ridiculous part - the first problem can be fixed in a
> very weird way which also solves the problem when trying to manually
> configure eduroam:
>
> CA-Certificates can be manually imported via
> chrome://settings/certificates - *but* normally only if they are _not_
> already known (it will just throw an error).
>
> But here comes the trick: if you use the tab for "Server"-certificates
> it will actually import the CA into the correct CA-Tab for roots and
> can now be configured to be trusted for websites.
>
> If an ONC-Profile is already installed it will now be fixed
> automagically and the CA can be specifically selected in manual
> configuration.
>
> The only catch - the CA can not be deleted like other manually imported
> CAs...
>
> Hopefully Googles proposed project Lacros will finaly move these
> settings out of the webbrowser into the system and fix some of this
> weirdness...
>
> Greetings, Lukas