certauth: Should accept authentication to webadmin through a trusted proxy #784

New Issue

2026-10-05T04:44:10+02:00

adam commented

2026-10-05 04:44:10 +02:00

The certauth module allows users to log into ZNC's webadmin using their client certificate, if the webadmin is accessed over TLS. However, one common configuration of ZNC involves running the webadmin behind a reverse proxy such as nginx, and it is impossible to "forward" a client's certificate through the proxy to ZNC.

A workaround, which many backend servers support, is to optionally accept a client certificate in the form of an HTTP header, rather than requiring the certificate to have actually been used for the TLS negotiation. Unfortunately, certauth does not currently support this feature.

I propose that, if certauth is validating a request from a declared TrustedProxy, it check for an HTTP header such as X-Client-Fingerprint, and use that fingerprint if present rather than require a client certificate to be presented in the request. This change would make it trivial to pass through a previously verified client certificate from nginx:

ssl_verify_client optional_no_ca;
location / {
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Client-Fingerprint $ssl_client_fingerprint;
  proxy_pass https://[::1]:7878; # this is where my webadmin's listening ;)
}

Of course, if the request to ZNC did not come from a TrustedProxy, it's not safe to trust a fingerprint presented as a header, and in that case the header should be ignored.

The certauth module allows users to log into ZNC's webadmin using their client certificate, if the webadmin is accessed over TLS. However, one common configuration of ZNC involves running the webadmin behind a [reverse proxy](http://wiki.znc.in/Reverse_Proxy) such as nginx, and it is impossible to "forward" a client's certificate through the proxy to ZNC. A workaround, which many backend servers support, is to optionally accept a client certificate in the form of an HTTP header, rather than requiring the certificate to have actually been used for the TLS negotiation. Unfortunately, certauth does not currently support this feature. I propose that, if certauth is validating a request from a declared `TrustedProxy`, it check for an HTTP header such as `X-Client-Fingerprint`, and use that fingerprint if present rather than require a client certificate to be presented in the request. This change would make it trivial to pass through a previously verified client certificate from nginx: ```nginx ssl_verify_client optional_no_ca; location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Client-Fingerprint $ssl_client_fingerprint; proxy_pass https://[::1]:7878; # this is where my webadmin's listening ;) } ``` Of course, if the request to ZNC did *not* come from a `TrustedProxy`, it's not safe to trust a fingerprint presented as a header, and in that case the header should be ignored.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#784