-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
certauth: Should accept authentication to webadmin through a trusted proxy #1430
Comments
an-empty-string
added a commit
to an-empty-string/znc
that referenced
this issue
Dec 23, 2017
…#1430) These changes allow trusted proxies to set a header overriding the detected client certificate fingerprint. This allows webadmin behind a HTTPS-supporting proxy to correctly work with the certauth module.
an-empty-string
added a commit
to an-empty-string/znc
that referenced
this issue
Feb 18, 2018
…#1430) These changes allow trusted proxies to set a header overriding the detected client certificate fingerprint. This allows webadmin behind a HTTPS-supporting proxy to correctly work with the certauth module.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 asX-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: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 text was updated successfully, but these errors were encountered: