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 - [email protected] Systems Administrator Enterprise Applications & Services | Technology Solutions University of Illinois - Chicago ________________________________ From: radiator <[email protected]> on behalf of Heikki Vatiainen <[email protected]> Sent: Wednesday, June 2, 2021 11:26 AM To: [email protected] <[email protected]> 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. Thanks, Heikki -- Heikki Vatiainen <[email protected]> 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 [email protected] 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
_______________________________________________ radiator mailing list [email protected] https://lists.open.com.au/mailman/listinfo/radiator
