debugging SSL self-signed cert issues

[Malcolm Herbert]

Circling back to an old thread for closure.

The issue here turned out to be EOL encoding-related.  The ZPL printer command for updating the CA cert uses raw byte count to determine file extents.

The original (working) file used CRLF line markings, my apparently broken one used just CR and the Unix tools I had been using Just Worked with either line discipline and masked the issue that I had muffed the byte count.

So - not an actual cert issue at all, but I got fixated on that given the error mrssage and what I was trying to do and Alan's hint prompted me to look again at the printer, which was apt, thanks

Regards,
Malcolm

On Tue, 23 Jul 2024, at 23:35, Alan DeKok wrote:
> On Jul 23, 2024, at 3:34 AM, Malcolm Herbert <freeradius.org at mjch.net> wrote:
>> 
>> Hi - I've had a long-running setup with freeradius 3.0.16 which I acknowledge is likely quite ancient now, but I've barely had to touch it since I set it up about 4y ago ...
>> 
>> I've been using self-signed certificate-based auth for our mobile label printers for some time without problems but after a CA certificate expiry extension (retaining the original CA key, pushing the notAfter date out) and creation of a new  server-side certificate on my radius server, the clients will now generate a bad certificate alert whenever I try using it.
>> 
>> I can replace the original server-side cert and things are ok again, so - something clearly is wrong with the new cert, but I haven't been able to pinpoint what.  The old and new server cert have the same information, barring minor differences between their SANs and relevant dates.  I've confirmed that openssl can verify both the old and new server certs against both the old and new CA certs and it seems to think everything is fine.
>> 
>> For testing purposes, half the printers have been given the updated CA cert and the others are on the same original CA cert but this side of the equation doesn't appear to change the result - printers configured with either will start having issues if I start using the new server cert.
>
>   This is almost always due to issues with old software using newer 
> certificate functionality, or newer software using older certificate 
> functionality.
>
>   i.e. software from 2000 will happily accept certificates with MD5 
> digests.  Software from 2024 will not.
>
>> I don't want to spam the list with long radiusd debug traces unless requested as I definitely think this is a cert issue of my own making, but I'm stumped as to how to get more information to isolate the underlying cause.
>> 
>> Has anyone else encountered this problem before?
>> 
>> Here's just the SSL negotiation in the working (original server cert) case:
>> ...
>> (5) eap_peap: <<< recv TLS 1.2  [length 0002]
>> (5) eap_peap: ERROR: TLS Alert read:fatal:bad certificate
>> (5) eap_peap: TLS_accept: Need to read more data: error
>> (5) eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate
>
>   That's the *printer* telling FreeRADIUS that it doesn't like the 
> server certificate.
>
>   Upgrade to 3.0.27, and these messages will become a lot clearer.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- 
Malcolm Herbert
mjch at mjch.net