You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When in this error state, no resolutions through Google can take place.
FIX 1: Turn off authentication
The problem goes away when using the following configuration setting:
tls_authentication: GETDNS_AUTHENTICATION_NONE
The default value is GETDNS_AUTHENTICATION_REQUIRED and I'd prefer a solution that allows me to keep this authentication mechanism turned on.
FIX 2: Manually obtain a public key
I can temporarily solve the problem via the following steps:
Navigate to the DNS server in question with my browser. e.g. https://8.8.4.4
Examine the certificate and export its public key
Convert the public key from hex-encoded to base64-encoded using this site.
Paste the base64-encoded string into the tls_pubkey_pinset.value field corresponding to the Google server in question in the stubby.yml file.
Restart Stubby
This works for a time, maybe for a month tops, and then needs to be repeated. Perhaps Google changes their public key periodically? I don't have the technical expertise to say one way or the other.
Question
What's a reliable way to keep Stubby authentication turned on without having to manually maintain and update these public key values in the stubby.yml file?
The text was updated successfully, but these errors were encountered:
Hi there - this issue here is with trying to use public key pinsets with Google who don't support them. You will see that the default Stubby config file does not contain pins for the Google resolvers, and they are not specified here: https://dnsprivacy.org/public_resolvers/
or on the Google DoT service site either.
Having stable public keys is an option for resolver operators but not a requirement (the details are in RFC 8310) , since many typically rotate their keys due to security policy. For those operators just use the tls_auth_name which will provide reliable authentication via the certificate chain installed on your device.
Thanks, Sara. I'm using a version of Stubby that's quite old and I could've sworn that the default yml file that came packaged with the software had those pinset values stuck in there. It's not the sort of thing I would've added on my own.
It worked for over a year and then a few months back, just stopped.
Thanks for the explanation. I'll follow the advice you provided.
Error Description
I started getting the following error when using Google as an upstream server:
[16:22:36.958590] STUBBY: 8.8.4.4 : Verify failed : TLS - *Failure* - Pinset validation failure
The Stubby.yml configuration file points to Google as follows:
When in this error state, no resolutions through Google can take place.
FIX 1: Turn off authentication
The problem goes away when using the following configuration setting:
tls_authentication: GETDNS_AUTHENTICATION_NONE
The default value is
GETDNS_AUTHENTICATION_REQUIRED
and I'd prefer a solution that allows me to keep this authentication mechanism turned on.FIX 2: Manually obtain a public key
I can temporarily solve the problem via the following steps:
tls_pubkey_pinset.value
field corresponding to the Google server in question in the stubby.yml file.This works for a time, maybe for a month tops, and then needs to be repeated. Perhaps Google changes their public key periodically? I don't have the technical expertise to say one way or the other.
Question
What's a reliable way to keep Stubby authentication turned on without having to manually maintain and update these public key values in the stubby.yml file?
The text was updated successfully, but these errors were encountered: