[RADIATOR] certificate problems [EXT]

Wed Jun 3 16:21:46 UTC 2020

On 3 Jun 2020, at 16:25, Eric W. Bates <ericx at whoi.edu<mailto:ericx at whoi.edu>> wrote:

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

Ahhhh!  They’re part of the load that got caught up in that!  We saw a symptom of that too:  jquery.com<http://jquery.com> are (or were, I handed the issue back to our first-line to follow up with them so it may have been fixed) including one of the root certs (AddTrust) that expired on the 30th in their chain.  Web browsers seemed to be happy but certain versions of curl/wget/openssl were complaining bitterly about the expired cert.

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.

Good luck.  eapol_test isn’t too bad once you’ve got your head around how to drive it.  Feel free to drop me an email if you need any help.

Cheers,
Martin.
On 3 Jun 2020, at 14:29, Eric W. Bates <ericx at whoi.edu<mailto: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<mailto:radiator at lists.open.com.au>
https://lists.open.com.au/mailman/listinfo/radiator

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

_______________________________________________
radiator mailing list
radiator at lists.open.com.au<mailto:radiator at lists.open.com.au>
https://lists.open.com.au/mailman/listinfo/radiator

-- 
 The Wellcome Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20200603/47757160/attachment-0001.html>