[RADIATOR] certificate problems [EXT]

[Eric W. Bates]

On 6/3/20 10:09 AM, Martin Burton wrote:
> Hi Eric,
> 
> Maybe I’m missing something here, but if the intermediate expired then I’d expect any end-user certificate signed by it to now be invalid also.
> 
> Unless InCommon used the same private key and serial number for the new intermediate (the key could potentially be reused but I wouldn’t expect a commercial CA to reuse the serial number as it’s a terrible thing to do from a security perspective) then there should no longer be a valid chain between your cert and the trusted root.

Not InCommon, but UserTrust (Comodo?) cross-signed their certs (e.g. in 
my chain you can see 5 different certs that all match {2/5 are expired, 
1/5 is self-signed})
https://crt.sh/?caid=1390

Carnagie Mellon has the best write-up I've found for this particular change:
https://www.cmu.edu/iso/service/cert-auth/addtrust.html

> In addition to Wireshark and rad_eap_test there’s also eapol_test from the linux wpa_supplicant package, although you’d have to compile that from source as the packaged version in most distributions don’t build that particular binary.  We use that as an integral part of our nagios monitoring of our Radiator services.

rad_eap_test is apparently just a wrapper for eapol_test. It supposed to 
make using eapol_test easier. But I have no clue, I'm still playing.

> Cheers,
> 
> Martin.
> 
>> On 3 Jun 2020, at 14:29, Eric W. Bates <ericx at whoi.edu> wrote:
>>
>> Thanks. I really like the Wireshark idea.
>>
>> 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
>>
>> _______________________________________________
>> radiator mailing list
>> radiator at lists.open.com.au
>> https://lists.open.com.au/mailman/listinfo/radiator
> 
> 
> 
> 


-- 
Clark 159a, MS 46
508/289-3112

-------------- 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/ace281a3/attachment.p7s>