FR 3.0.21 on Debian Buster delivering strange cert+chain?

[Alan DeKok]

> On Jul 17, 2020, at 11:56 AM, Martin Pauly <pauly at hrz.uni-marburg.de> wrote:
> 
> Am 15.07.20 um 17:13 schrieb Alan DeKok:
>>   FreeRADIUS uses OpenSSL to implement all certificate handling.  By switching versions of OpenSSL, you change the behaviour of certificate handling.
> yes. I was able to narrow things down a bit.
> 
> 1.  Static openssl verify works
> openssl verify -verbose -x509_strict -CAfile /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem -untrusted chain-telesec-global-root-ca2-without-rootcert.pem -verify_hostname radius.staff.uni-marburg.de  cert-radius.staff.uni-marburg.de-telesec-root.pem
> cert-radius.staff.uni-marburg.de-telesec-root.pem: OK
> 
> 2. I fed the certs to openssl s_server and, on localhost used
>  openssl s_client -verify_hostname radius.staff.uni-marburg.de -x509_strict  -CAfile /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem -connect :8008
> ==> OK, as expected (and every minor change breaks it)
> 
> 3. eapol_test succeeds when I use EAP-TTLS/PAP

  IIRC, PEAP enables TLS compression by default (i.e. requires it), and TTLS doesn't.  That might be the difference here.

> 4. I called eapol_test against my working server (which carries the same cert) and against localhost for comparison
>   AFAICT, relevant diffs show from line 403 in both files (size of RADIUS packets) or 421 (size of EAP requests)
>   Files are attached for easier handling (some attachments seem to make it to the list) but are appended inline regardless
>   (password was a real one at the time of test, but changed after).
> 
> From my (pretty naive) point of view, it looks like the 11 Bytes missing from the EAP-Request-PEAP might spoil the game.

  It is suspicious.

  But OpenSSL does... all kinds of magic.  TLS packet sizes depend on all kinds of things, so it's not *too* surprising that there are differences.  But a difference which then leads to an error is more suspicious.

> I might even have hit a rare corner case, e.g. Sven Hartge is using exactly the same combination of FR and libssl1.1 without problems.
> (It's the buster-backports packages now. If needed, I will also try those from networkradius.com.)

  Sure.

  I suggest looking at the packet traces with wireshark.  It does a good job of piecing the packets together.  It lets you get deeper into the TLS data than FreeRADIUS does.  You may even be able to see that the certificates being exchanged are wrong?

  Alan DeKok.