rad_eap_test is a little easier. And it does have a flag to show certificate info; but unfortunately it only provides info about the certificate chain's leaf node (no info about other certs in the chain). Not clear that it validates the chain (it might; but the chain is already fixed and there is no "YES VALIDATION" message of any sort).
To see a copy of the whole chain, you can feed rad_eap_test the '-N' option and it does not delete the temporary work files (eapol_test only has an option to write the chain out to a file); so you can see what eapol_test wrote. Then you can validate it yourself. [sigh]
So a working test command for TTLS tunneling:./rad_eap_test -c -t 10 -H '[server host name]' -P '1812' -S '[RADIUS client PSK]' -u '[email protected]' -p '[my password]' -s '[SSID]' -m IEEE8021X -e TTLS -2 MSCHAPV2 -A [email protected] -T -b -N
[phew] And then way down at the bottom of the output:Leaving temporary files in /tmp/rad_eap_test.vh2dio Configuration: /tmp/rad_eap_test.vh2dio/tmp-1208.conf
Output: /tmp/rad_eap_test.vh2dio/tmp-1208.out
RADIUS certiticate: /tmp/rad_eap_test.vh2dio/RADIUS_cert.pem
you get your copy of the "certiticate."
Some of the knobs may only be necessary for us.
- The Radiator handler we use needs to see the attribute
Called-Station-Id in the format of '[MAC]:[SSID]' and the -T gives you
that.
- The same handler (for the outer anonymous auth) expects to see
"[email protected]" in order to match the realm "whoi.edu"
So I still have a phone refusing to connect (I think Martin is probably correct about the phone's list of trusted roots). But now I can prove: "it's not the network..."
On 6/3/20 9:11 AM, Heikki Vatiainen wrote:
On 3.6.2020 15.44, Eric W. Bates wrote:We use certificates signed by InCommon and over the weekend several older intermediate certificates expired; so I updated the chain file.Now I'm getting:Tue Jun 2 22:21:17 2020 630517: DEBUG: EAP result: 1, EAP TTLS Handshake unsuccessful: 2861: 1 - error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown caso from "unknown ca" I have to assume I screwed up the chain.It also could be that client profile does not trust the new root CA or it's not present in client's CA certificate storage.Is there a way similar to "openssl s_client" to pull the certificate chain from Radiator? I just want to confirm what cert chain is being offered.Wireshark could also work here. If you capture RADIUS with TLS backed EAP, such as PEAP, wireshark can reconstruct TLS handshake from the capture.Edit: just noticed that you're looking at rad_eap_test. Please let us know how it goes.Thanks, Heikki
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ radiator mailing list [email protected] https://lists.open.com.au/mailman/listinfo/radiator
