[RADIATOR] certificate problems

[Eric W. Bates]

For the record you can validate the certificate chain but it's a bit 
convoluted.

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 'ericx at whoi.edu' -p '[my password]' -s '[SSID]' -m 
IEEE8021X -e TTLS -2 MSCHAPV2 -A anonymous at whoi.edu -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 
"anonymous at whoi.edu" 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 ca
>>
>> so 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4188 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20200603/96afb3fd/attachment.p7s>