Retrieving Client TLS attributes for invalid/rejected requests
Hello, We're using EAP TLS and I've had no trouble pulling the TLS attributes (TLS-Client-Common-Name, etc) out of the request during normal processing. However, I'm getting several certs as revoked/expired and I'd like to get into it a little more. I could attach to debug, but I'd like to also log these failed certificates so I can chase down the users and run some reports. However, when I try to log the TLS-* attributes in Post-Auth-Type REJECT, they're empty. I'm guessing that the EAP module cleans them up on failure? I even tried to use failover to catch the invalid response as quickly as possible: eap { invalid = 1 } if (invalid) { sa_linelog_bad_cert invalid } But again all the TLS-* attributes come up blank in the linelog. I can see them in the eap_tls section, but they're gone by the time I get to linelog: (7) eap: Calling submodule eap_tls to process data (7) eap_tls: (TLS) EAP Got final fragment (827 bytes) (7) eap_tls: (TLS) EAP Done initial handshake (7) eap_tls: (TLS) Handshake state - Server SSLv3/TLS write server done (7) eap_tls: (TLS) recv TLS 1.2 Handshake, Certificate (7) eap_tls: (TLS) Creating attributes from TLS-Client-Cert-Serial certificate (7) eap_tls: (TLS) Creating attributes from server certificate (7) eap_tls: TLS-Cert-Serial := "460d875635c64859ebabee3bba64e93f" (7) eap_tls: TLS-Cert-Expiration := "390703160000Z" (7) eap_tls: TLS-Cert-Valid-Since := "190703161900Z" (7) eap_tls: TLS-Cert-Subject := "/O=Suffield Academy/CN=Suffield Academy Device Intermediate CA" (7) eap_tls: TLS-Cert-Issuer := "/O=Suffield Academy/CN=Suffield Academy Device Root CA" (7) eap_tls: TLS-Cert-Common-Name := "Suffield Academy Device Intermediate CA" (7) eap_tls: (TLS) Creating attributes from client certificate (7) eap_tls: TLS-Client-Cert-Serial := "5052ac2d40917d66343d050650939854" (7) eap_tls: TLS-Client-Cert-Expiration := "210803194948Z" (7) eap_tls: TLS-Client-Cert-Valid-Since := "210802193900Z" (7) eap_tls: TLS-Client-Cert-Subject := "/O=Suffield Academy/CN=Expired User (Fake 1234567890)" (7) eap_tls: TLS-Client-Cert-Issuer := "/O=Suffield Academy/CN=Suffield Academy Device Intermediate CA" (7) eap_tls: TLS-Client-Cert-Common-Name := "Expired User (Fake 1234567890)" (7) eap_tls: TLS-Client-Cert-Subject-Alt-Name-Email := "Expired User (Fake 1234567890)" (7) eap_tls: TLS-Client-Cert-Subject-Alt-Name-Dns := "_SA_" (7) eap_tls: TLS-Client-Cert-Subject-Alt-Name-Upn := "expired" (7) eap_tls: ERROR: SSL says error 10 : certificate has expired (7) eap_tls: (TLS) send TLS 1.2 Alert, fatal certificate_expired (7) eap_tls: ERROR: (TLS) Alert write:fatal:certificate expired (7) eap_tls: ERROR: (TLS) Server : Error in error (7) eap_tls: ERROR: (TLS) Failed reading from OpenSSL: error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed (7) eap_tls: ERROR: (TLS) System call (I/O) error (-1) (7) eap_tls: ERROR: (TLS) EAP Receive handshake failed during operation (7) eap_tls: ERROR: [eaptls process] = fail (7) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed (7) eap: Sending EAP Failure (code 4) ID 229 length 4 (7) eap: Failed in EAP select (7) [eap] = invalid (7) if (invalid) { (7) if (invalid) -> TRUE (7) if (invalid) { (7) sa_linelog_bad_cert: EXPAND %{Module-Failure-Message} for %{%{TLS-Client-Cert-Common-Name}:-No-Common-Name} %{%{TLS-Client-Cert-Subject-Alt-Name-Email}:-No-Alt-RFC822} %{%{TLS-Client-Cert-Subject-Alt-Name-Dns}:-No-Alt-DNS} (7) sa_linelog_bad_cert: --> eap_tls: SSL says error 10 : certificate has expired for No-Common-Name No-Alt-RFC822 No-Alt-DNS (7) [sa_linelog_bad_cert] = ok (7) [invalid] = invalid (7) } # if (invalid) = invalid (7) } # Auth-Type eap = invalid So, any way to retrieve invalid cert data for logging? Thanks, Jason
On Sep 13, 2021, at 4:34 PM, Jason Healy <jhealy@logn.net> wrote:
We're using EAP TLS and I've had no trouble pulling the TLS attributes (TLS-Client-Common-Name, etc) out of the request during normal processing.
However, I'm getting several certs as revoked/expired and I'd like to get into it a little more. I could attach to debug, but I'd like to also log these failed certificates so I can chase down the users and run some reports.
However, when I try to log the TLS-* attributes in Post-Auth-Type REJECT, they're empty. I'm guessing that the EAP module cleans them up on failure? I even tried to use failover to catch the invalid response as quickly as possible:
eap { invalid = 1 } if (invalid) { sa_linelog_bad_cert invalid }
When the EAP module decides that the TLS session is invalid, it tears down the entire TLS session. Including the attributes which are associated with that session. These attributes are associated with the session state list only if authentication succeeds.
But again all the TLS-* attributes come up blank in the linelog. I can see them in the eap_tls section, but they're gone by the time I get to linelog: ... So, any way to retrieve invalid cert data for logging?
Not right now. :( The certs are cached only when authentication succeeds. I'll see if I can add a flag which also caches them on authentication failure. Alan DeKok.
On 13/09/2021 22:05, Alan DeKok wrote:
On Sep 13, 2021, at 4:34 PM, Jason Healy <jhealy@logn.net> wrote:
But again all the TLS-* attributes come up blank in the linelog. I can see them in the eap_tls section, but they're gone by the time I get to linelog: ... So, any way to retrieve invalid cert data for logging?
Not right now. :( The certs are cached only when authentication succeeds.
I suspect that the attributes are also available in the check-eap-tls virtual server and could be copied out from there, but would need to check to be certain. It's possible that isn't called if validation fails beforehand. -- Matthew
Yeah, it was supposed to keep the certs even on failure. But some code paths didn't do that. I've pushed some fixes. Alan DeKok.
On Sep 13, 2021, at 5:14 PM, Alan DeKok <aland@deployingradius.com> wrote:
Yeah, it was supposed to keep the certs even on failure. But some code paths didn't do that. I've pushed some fixes.
Thank you! I see those in git; I may not be able to build a new server right now (first week of school), but I'll either grab it later or catch it in the next release. Thanks for the quick attention! Jason
participants (3)
-
Alan DeKok -
Jason Healy -
Matthew Newton