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 - [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 10:17 AM
*To:* [email protected] <[email protected]>
*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 <[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%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 <[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://lists.open.com.au/mailman/listinfo/radiator
