Fwd: Way to configure logging to emit SSL Certificate info with a failure message?
Looking for ways to configure version 3.0.x to emit additional log data when an SSL error occurs. Specifically looking for ways to emit the SAN or even the ID of the certificate being presented to make it easier to track down badly configured clients without having to turn on debug mode. Example of log message we're seeing as too generic currently: Mon Mar 6 10:32:59 2023 : ERROR: (0) ERROR: SSL says error 23 : certificate revoked
On Mar 9, 2023, at 10:47 AM, Andy Arp <bubbaandy89@gmail.com> wrote:
Looking for ways to configure version 3.0.x to emit additional log data when an SSL error occurs. Specifically looking for ways to emit the SAN or even the ID of the certificate being presented to make it easier to track down badly configured clients without having to turn on debug mode.
Example of log message we're seeing as too generic currently:
Mon Mar 6 10:32:59 2023 : ERROR: (0) ERROR: SSL says error 23 : certificate revoked
See the debug output. The certificate fields are placed into attributes, and those attributes can be logged. Those error messages should also be placed into the TLS-Session-Information attribute, and placed into the session-state list. Alan DeKok.
Awesome, will give this a try. Did something similar recently with logging returned Airespace-Interface-Name so the process should be pretty similar. On Thu, Mar 9, 2023 at 11:00 AM Alan DeKok <aland@deployingradius.com> wrote:
On Mar 9, 2023, at 10:47 AM, Andy Arp <bubbaandy89@gmail.com> wrote:
Looking for ways to configure version 3.0.x to emit additional log data when an SSL error occurs. Specifically looking for ways to emit the SAN
or
even the ID of the certificate being presented to make it easier to track down badly configured clients without having to turn on debug mode.
Example of log message we're seeing as too generic currently:
Mon Mar 6 10:32:59 2023 : ERROR: (0) ERROR: SSL says error 23 : certificate revoked
See the debug output. The certificate fields are placed into attributes, and those attributes can be logged.
Those error messages should also be placed into the TLS-Session-Information attribute, and placed into the session-state list.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Thanks, Andy Arp
Adding to this, Where would I put the call to the linelog to emit this data if I wanted to log the data for the RADSEC TLS connection? Specifically to log details in the event of Unknown CA or missing CRL? On Thu, Mar 9, 2023 at 11:24 AM Andy Arp <bubbaandy89@gmail.com> wrote:
Awesome, will give this a try. Did something similar recently with logging returned Airespace-Interface-Name so the process should be pretty similar.
On Thu, Mar 9, 2023 at 11:00 AM Alan DeKok <aland@deployingradius.com> wrote:
On Mar 9, 2023, at 10:47 AM, Andy Arp <bubbaandy89@gmail.com> wrote:
Looking for ways to configure version 3.0.x to emit additional log data when an SSL error occurs. Specifically looking for ways to emit the
SAN or
even the ID of the certificate being presented to make it easier to track down badly configured clients without having to turn on debug mode.
Example of log message we're seeing as too generic currently:
Mon Mar 6 10:32:59 2023 : ERROR: (0) ERROR: SSL says error 23 : certificate revoked
See the debug output. The certificate fields are placed into attributes, and those attributes can be logged.
Those error messages should also be placed into the TLS-Session-Information attribute, and placed into the session-state list.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Thanks, Andy Arp
-- Thanks, Andy Arp
On Mar 9, 2023, at 12:21 PM, Andy Arp <bubbaandy89@gmail.com> wrote:
Adding to this, Where would I put the call to the linelog to emit this data if I wanted to log the data for the RADSEC TLS connection? Specifically to log details in the event of Unknown CA or missing CRL?
The short answer is to run it in debugging mode, and see which policies or virtual servers are used. Then, update those to use logging. Alan DeKok.
participants (2)
-
Alan DeKok -
Andy Arp