[RADIATOR] Certificate Not Trusted - InCommon?

Ullfig, Roberto Alfredo rullfig at uic.edu
Wed Jun 2 18:37:51 UTC 2021

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
> "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.


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,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.
radiator mailing list
radiator at lists.open.com.au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20210602/1a161e2d/attachment.html>

More information about the radiator mailing list