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
[DoH][TLS Client Authentication] Reload expired client certificates #2114
Labels
feature request
New feature request
Comments
I'm not very familiar with that part of the code and I've never used that feature. Would you mind submitting a pull request to implement this? |
@jedisct1 - sure thing, I'll take a pass at implementing the "easier" fix option I called out above this week. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Output of the following commands:
What is affected by this bug?
I have a DoH client server which only uses short-lived client certificates (2 week validity) when connecting to a mutually authenticated DoH server. These certificates are renewed weekly, replacing the existing file(s). However, since
dnscrypt-proxy
does not refresh its client credentials, all DoH requests fail due to TLS errors once the client certificate has expired, provided the upstream is enforcing valid client certificates. This means that my client only has between 1-2 weeks of use before I need to restart thednscrypt-proxy
process to pick up the new certificate.When does this occur?
Upon startup,
dnscrypt-proxy
loads the client certificate into memory when building thextransport
. However, they are never updated after that. Should the certificate in memory expire, all requests which use it will fail. There are a few places where the transport is rebuilt, but none trigger on this particular error (only on "handshake failure").Where does it happen?
It happens when a DoH request is being performed while the client certificate loaded into memory has expired.
The relevant error handling will likely take place here:
dnscrypt-proxy/dnscrypt-proxy/xtransport.go
Lines 437 to 447 in c367a82
How do we replicate the issue?
dnscrypt-proxy
with this client certificate, targeting a DoH server which supports mutual authentication and enforces certificate validityExpected behavior (i.e. solution)
There are likely (at least) two ways to go about solving this issue:
Other Comments
As a stopgap, I have updated my DoH endpoints to accept expired client certificates for now, but this is obviously not the ideal end state here.
The text was updated successfully, but these errors were encountered: