debugging SSL self-signed cert issues
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. 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: : : (1) Found Auth-Type = eap (1) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (1) authenticate { (1) eap: Expiring EAP session with state 0x8abbb4538a68ad3a (1) eap: Finished EAP session with state 0x8abbb4538a68ad3a (1) eap: Previous EAP request found for state 0x8abbb4538a68ad3a, released from the list (1) eap: Peer sent packet with method EAP PEAP (25) (1) eap: Calling submodule eap_peap to process data (1) eap_peap: Continuing EAP-TLS (1) eap_peap: Peer indicated complete TLS record size will be 296 bytes (1) eap_peap: Got complete TLS record (296 bytes) (1) eap_peap: [eaptls verify] = length included (1) eap_peap: (other): before SSL initialization (1) eap_peap: TLS_accept: before SSL initialization (1) eap_peap: TLS_accept: before SSL initialization (1) eap_peap: <<< recv UNKNOWN TLS VERSION ?0304? [length 0123] (1) eap_peap: TLS_accept: SSLv3/TLS read client hello (1) eap_peap: >>> send TLS 1.2 [length 0039] (1) eap_peap: TLS_accept: SSLv3/TLS write server hello (1) eap_peap: >>> send TLS 1.2 [length 0d2c] (1) eap_peap: TLS_accept: SSLv3/TLS write certificate (1) eap_peap: >>> send TLS 1.2 [length 01cd] (1) eap_peap: TLS_accept: SSLv3/TLS write key exchange (1) eap_peap: >>> send TLS 1.2 [length 0004] (1) eap_peap: TLS_accept: SSLv3/TLS write server done (1) eap_peap: TLS_accept: Need to read more data: SSLv3/TLS write server done (1) eap_peap: In SSL Handshake Phase (1) eap_peap: In SSL Accept mode (1) eap_peap: [eaptls process] = handled (1) eap: Sending EAP Request (code 1) ID 212 length 1004 (1) eap: EAP session adding &reply:State = 0x8abbb4538b6fad3a (1) [eap] = handled (1) } # authenticate = handled (1) Using Post-Auth-Type Challenge (1) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (1) Challenge { ... } # empty sub-section is ignored : : Here is the same again in the failed (new server cert) case: : : (5) Found Auth-Type = eap (5) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (5) authenticate { (5) eap: Expiring EAP session with state 0x5f15dbf65b3fc265 (5) eap: Finished EAP session with state 0x5f15dbf65b3fc265 (5) eap: Previous EAP request found for state 0x5f15dbf65b3fc265, released from the list (5) eap: Peer sent packet with method EAP PEAP (25) (5) eap: Calling submodule eap_peap to process data (5) eap_peap: Continuing EAP-TLS (5) eap_peap: Peer indicated complete TLS record size will be 7 bytes (5) eap_peap: Got complete TLS record (7 bytes) (5) eap_peap: [eaptls verify] = length included (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 (5) eap_peap: In SSL Handshake Phase (5) eap_peap: In SSL Accept mode (5) eap_peap: SSL Application Data (5) eap_peap: ERROR: TLS failed during operation (5) eap_peap: ERROR: [eaptls process] = fail (5) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed (5) eap: Sending EAP Failure (code 4) ID 42 length 4 (5) eap: Failed in EAP select (5) [eap] = invalid (5) } # authenticate = invalid (5) Failed to authenticate the user (5) Using Post-Auth-Type Reject (5) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (5) Post-Auth-Type REJECT { : : Regards, Malcolm -- Malcolm Herbert mjch@mjch.net
On Jul 23, 2024, at 3:34 AM, Malcolm Herbert <freeradius.org@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.
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@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@mjch.net
participants (2)
-
Alan DeKok -
Malcolm Herbert