[RADIATOR] Certificate Not Trusted - InCommon?

Wed Jun 2 19:26:24 UTC 2021

I googled this TOFU design

https://en.wikipedia.org/wiki/Trust_on_first_use

https://security.stackexchange.com/questions/178909/my-school-wifi-asks-to-trust-a-certificate-on-iphones-does-this-allow-them-to

https://communications.financials.utexas.edu/news/new-wifi-certificate-starting-july-14

and it would appear that it's normal but our management wants to get rid of the prompt because there's an open (no auth) wifi pilot SSID on campus where that trust prompt never appears so they think it's a problem with our service. Is there a more official paper I can point them at to convince them that this TOFU is ok? Thanks!

---
Roberto Ullfig - rullfig at uic.edu
Systems Administrator
Enterprise Applications & Services | Technology Solutions
University of Illinois - Chicago
________________________________
From: radiator <radiator-bounces at lists.open.com.au> on behalf of Ullfig, Roberto Alfredo <rullfig at uic.edu>
Sent: Wednesday, June 2, 2021 1:37 PM
To: radiator at lists.open.com.au <radiator at lists.open.com.au>
Subject: Re: [RADIATOR] Certificate Not Trusted - InCommon?

trying to use EAPTLS_CertificateChainFile does not work - we are running 4.16 - these errors appear when a user attempts to connect:

Wed Jun  2 13:32:22 2021: ERR: TLS could not load_verify_locations , :  16422: 1 - error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library
 16422: 2 - error:25070067:DSO support routines:DSO_load:could not load the shared library
 16422: 3 - error:260B6084:engine routines:DYNAMIC_LOAD:dso not found
 16422: 4 - error:2606A074:engine routines:ENGINE_by_id:no such engine

---
Roberto Ullfig - rullfig at uic.edu
Systems Administrator
Enterprise Applications & Services | Technology Solutions
University of Illinois - Chicago

________________________________
From: radiator <radiator-bounces at lists.open.com.au> on behalf of Heikki Vatiainen <hvn at open.com.au>
Sent: Wednesday, June 2, 2021 11:26 AM
To: radiator at lists.open.com.au <radiator at lists.open.com.au>
Subject: Re: [RADIATOR] Certificate Not Trusted - InCommon?

On 2.6.2021 18.42, Ullfig, Roberto Alfredo wrote:

> Also this document:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftroubleshoot%2Fwindows-server%2Fnetworking%2Fcertificate-requirements-eap-tls-peap&data=04%7C01%7Crullfig%40uic.edu%7Cc2d346b461cb402e370708d925e34d4d%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637582480450282431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y3hMSGoZ5IMy8bpKzVXFT7QTof15NWUQLhqf8UWGyAg%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftroubleshoot%2Fwindows-server%2Fnetworking%2Fcertificate-requirements-eap-tls-peap&data=04%7C01%7Crullfig%40uic.edu%7Cca6419961a4f4471dbc008d925f59c77%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637582559532510025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GGpw0XrmSHCwxuwdR2xoOInBA1AyE19B03QHAcSMDdk%3D&reserved=0>
>
> "For wireless clients, the Subject Alternative Name (SubjectAltName)
> extension contains the server's fully qualified domain name (FQDN)."
>
> What is this referring to? Does the SAN for our cert need to match
> anything, like the server radiator is running on, etc....

When profiles are provisioned AD policies or other tools, they set the
WLAN name, expected CA certificates and the expected name in the RADIUS
server's certificate (and possible other information). It seems the name
in a profile is expected to be in SAN when TLS based EAP authentication
is done.

With HTTPS the browser knows from the URL the expected name of the web
server and the certificate name validation is based on that. With, for
example PEAP, the name is part of the profile settings, or manual
configuration. The client knows from its configuration settings this
configuration and that's what the SAN of your cert needs to match.

There's no need for the SAN to match the name of the server Radiator
runs on. If you have multiple Radius servers for redundancy purposes,
the can use the same certificate or different certificates. In the
latter case, the profile or other configuration must know about the both
names or otherwise the client devices will start prompting about uknown
or untrusted certificate.

Getting back to Trust-On-First-Use (TOFU), if you have a profile, then
there should be no TOFU triggered prompts because the trust settings are
already defined.

Thanks,
Heikki

--
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,
EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.
_______________________________________________
radiator mailing list
radiator at lists.open.com.au
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.open.com.au%2Fmailman%2Flistinfo%2Fradiator&data=04%7C01%7Crullfig%40uic.edu%7Cc2d346b461cb402e370708d925e34d4d%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637582480450282431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mdsfwcsBuNipMTJ4thg1CY4xmbwm6j%2FFKPnxMOoZ8ow%3D&reserved=0<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.open.com.au%2Fmailman%2Flistinfo%2Fradiator&data=04%7C01%7Crullfig%40uic.edu%7Cca6419961a4f4471dbc008d925f59c77%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637582559532519987%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=B8o7sKAiv8n0QgLvOIOOfQP2R7eMFKUAOVN27p3SqOE%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20210602/0225f81e/attachment-0001.html>