[RADIATOR] Certificate Not Trusted - InCommon?

Wed Jun 2 16:09:44 UTC 2021

On 2.6.2021 18.38, Ullfig, Roberto Alfredo wrote:
> We are using these options:
> 
>                  EAPTLS_CAFile
>                  EAPTLS_CertificateFile
> 
> So we should use:
>  
> EAPTLS_CertificateChainFile
> 
> with all certs in it? There are two intermediate certs - does their 
> order matter?

I would put them in the chain order starting with the end node's 
(Radiator) certificate followed by its issuer and then issuer's issuer. 
The second intermediate CA certificate is the one that's issued by the 
root CA.

There's no need to add the root CA. It only adds data in TLS handshake 
that the client must discard.

EAPTLS_PrivateKeyFile and EAPTLS_PrivateKeyFilePassword are used the 
same as before.

After the configuration update you can capture the data with tcpdump and 
check it with Wireshark. Wirewhark can decode the TLS handshake within 
RADIUS/EAP and it will show what certificates are sent by the server. 
It's a good way to get an independent view to see what happens between 
the client and server.

Optional configuration updates
++++++++++++++++++++++++++++++

To clarify Radiator configuration with version 4.20 and later, you could 
also do this if you don't need to verify client certificates (EAP-TLS 
typically, PEAP and EAP-TTLS very seldomly used):

# EAPTLS_CAFile
# EAPTLS_CAPath
EAPTLS_NoClientCert
EAPTLS_CertificateChainFile ...
EAPTLS_PrivateKeyFile ...
# If the private key is passphrase protected:
#EAPTLS_PrivateKeyFilePassword ...

https://files.radiatorsoftware.com/radiator/ref/EAPTLS_NoClientCert.html

What the above configuration does is: send servers certificate and 
intermediate CA certficate during the handshake. Skip configuration 
parameters needed to verify client certificates.

EAPTLS_CAPath/CAFile were typically used for historical reasons. With 
the typical PEAP and EAP-TTLS (but not EAP-TLS) configurations, all 
that's needed is to make sure the server and intermediate CA 
certificates are sent correctly and turn off client certificate 
verification because client's are never expected nor requested to send 
their certififcates.

Thanks,
Heikki

> ---
> 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 10:17 AM
> *To:* radiator at lists.open.com.au <radiator at lists.open.com.au>
> *Subject:* Re: [RADIATOR] Certificate Not Trusted - InCommon?
> On 1.6.2021 18.35, Ullfig, Roberto Alfredo wrote:
> 
>> This has always been an issue for us. Whenever a user connects for the 
>> first time they get "certificate not trusted". Is this because the 
>> certificate is issued by:
>> 
>>          Issuer: C=US, ST=MI, L=Ann Arbor, O=Internet2, OU=InCommon, 
>> CN=InCommon RSA Server CA
>> 
>> So, most (maybe all) devices do not install the InCommon CA? What's the 
>> best solution for this? Should users manually install the InCommon CA 
>> first before connecting?
> 
> Martin already replied about the importance of server chain, so I'll
> just one more thing we have seen also happening:
> 
> See the document below and look for 'Trust-On-First-Use' or 'TOFU':
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wi-fi.org%2Fdownload.php%3Ffile%3D%2Fsites%2Fdefault%2Ffiles%2Fprivate%2F202012_Wi-Fi_Security_Roadmap_and_WPA3_Updates.pdf&data=04%7C01%7Crullfig%40uic.edu%7C3e368f43fccf490a0caa08d925da7800%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637582443563771759%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SWK07irLsCEDGzgAX03o3bgFETTlUh0eW3LjnB6D3rA%3D&reserved=0 
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wi-fi.org%2Fdownload.php%3Ffile%3D%2Fsites%2Fdefault%2Ffiles%2Fprivate%2F202012_Wi-Fi_Security_Roadmap_and_WPA3_Updates.pdf&data=04%7C01%7Crullfig%40uic.edu%7C3e368f43fccf490a0caa08d925da7800%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637582443563771759%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SWK07irLsCEDGzgAX03o3bgFETTlUh0eW3LjnB6D3rA%3D&reserved=0>
> 
> The devices may still prompt the user even if the certificate chain is
> correct. For example, even if the certificate chain is correct, the user
> is required to accept that the name in certificate is something that's
> expected. When this is done, the dialog doesn't re-appear until the
> certificate changes.
> 
> I think the exact wording in the dialog is different when the
> certificate chain is not complete as opposed to the case where the chain
> is good but the certificate is now yet known.
> 
> To configure Radiator to send intermediate CA certificates, use
> EAPTLS_CertificateChainFile parameter instead of
> EAPTLS_CertificateFile parameter. The difference is that
> EAPTLS_CertificateFile contains only the server's certificate. The chain
> file starts with the server's certificate followed by one or more
> intermediate CA certficates. These all need to be in PEM format.
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffiles.radiatorsoftware.com%2Fradiator%2Fref%2FEAPTLS_CertificateChainFile.html&data=04%7C01%7Crullfig%40uic.edu%7C3e368f43fccf490a0caa08d925da7800%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637582443563771759%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LUSjH0v5yXLF83vCMtVfmpvuccZ84D2QPfZ3XyHWBKs%3D&reserved=0 
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffiles.radiatorsoftware.com%2Fradiator%2Fref%2FEAPTLS_CertificateChainFile.html&data=04%7C01%7Crullfig%40uic.edu%7C3e368f43fccf490a0caa08d925da7800%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637582443563771759%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LUSjH0v5yXLF83vCMtVfmpvuccZ84D2QPfZ3XyHWBKs%3D&reserved=0>
> 
> You may already have the configuration set correctly and it's just the
> TOFU prompts the clients display, but it might be useful to check that
> the chain is correctly configured too.
> 
> 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%7C3e368f43fccf490a0caa08d925da7800%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637582443563771759%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Oz8XIAEHMj5JBC5EGY64tgMo14Mpu8qIskYY1Z847bw%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%7C3e368f43fccf490a0caa08d925da7800%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637582443563771759%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Oz8XIAEHMj5JBC5EGY64tgMo14Mpu8qIskYY1Z847bw%3D&reserved=0>

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