[RADIATOR] Certificate Not Trusted - InCommon?
hvn at open.com.au
Wed Jun 2 16:26:36 UTC 2021
On 2.6.2021 18.42, Ullfig, Roberto Alfredo wrote:
> Also this document:
> "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
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
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.
More information about the radiator