"tls: failed to verify certificate: x509: certificate is valid" when using certain resolvers #2801
Comments
|
Try installing and trusting http://i.pki.goog/wr2.crt and see if that fixes. dnscrypt-proxy uses the crypto/tls package for handling SSL/TLS connections. This package uses the system's certificate store on Windows. The google ca cert was created on Dec 13 09:00:00 2023 GMT so Windows 7 wouldn't know about it since it doesn't get updates or security updates. It also can't run recent versions of Firefox or Chrome, so, watch out for malware. |
|
Already tried. Without effect. I also tried various tricks with updating the full set of root certificates - without effect :( Under a very old linux in VirtualBox there are no problems :/ On smartphones with an old android, too everything is OK :/ |
|
Ah, bummer. I didn't look closely enough at the verification error message either. tls: failed to verify certificate: x509: certificate is valid for 8.8.8.8, 8.8.4.4, 2001:4860:4860::8888, 2001:4860:4860::8844, 2001:4860:4860::6464, 2001:4860:4860::64, not 8.8.4.4 The apparent server IP is included in the list of subject alt names but the ssl verification routine doesn't seem to be matching on it properly 🤔 |
|
On Win10 22H2, at least yandex is working on my side. The error message is puzzling. |
KB4474419? Or what other patches? KB4474419 I installed. No effect :( |
|
Maybe some antivirus or spyware hijacking HTTPS traffic? |
|
I don't use Win7 any more. You check it out: Got a summary by asking DeepSeek: What are the https features missing on Windows 7 SP1 compared to Windows 10? https://github.com/XTLS/go-win7/blob/build/README-eng.md#go-121 recommends KB4490628. More details: |
I also thought about it, but the problem is not in the antivirus. I turned off the antivirus and on VirtualBox (bridge) was the same
KB3033929 has already been installed:/ without effect
OK. I will install the KB4490628 and check it, after which I will inform the results. |
|
Without effect. KB4490628 and KB3033929 did not help |
|
What about other servers, without specifying |
|
@lifenjoiner, from the start Issue:
|
|
Windows 7 doesn't have the ciphers (1) that the servers want: ECDHE-RSA-AES256-GCM-SHA384 (xc030) or ECDHE-RSA-AES128-GCM-SHA256 (xc02f) (2, 3). That's why you can't even visit https://77.88.8.8/ by the IE on Windows 7. Plus, go lang had abandoned Windows 7 and claims supporting TLS 1.3 by default, which the servers prefer but Windows 7 won't have: It makes things even harder. These are why we won't support expired OS. So be it. Just use the available servers. |
There are no such problems on Linux 12-years-old :/ dnscrypt with the same config works without problems. This is crazy :(
Or use dnscrypt on VirtualBox using as a resolver :/ |
|
Ask Microsoft, Google, or the server providers for it. It isn't an issue of dnscrypt-proxy. |
SolutionCloudflare, Google and Yandex DOH work perfectly fine on Windows 7 via DNSCrypt. server_names = [
'cloudflare-doh-new',
'google-doh-new',
'yandex-doh-new',
]
[static.'cloudflare-doh-new']
stamp = 'sdns://AgcAAAAAAAAABzEuMS4xLjEgbmKg79YKBNk_L4ZLVEQnF6ZmwDjIxwVGr2MZ5PRqL3MPb25lLm9uZS5vbmUub25lCi9kbnMtcXVlcnk'
[static.'google-doh-new']
stamp = 'sdns://AgUAAAAAAAAABzguOC44LjggbmKg79YKBNk_L4ZLVEQnF6ZmwDjIxwVGr2MZ5PRqL3MKZG5zLmdvb2dsZQovZG5zLXF1ZXJ5'
[static.'yandex-doh-new']
stamp = 'sdns://AgUAAAAAAAAACTc3Ljg4LjguOCCoF6cUD2dwqtorNi96I2e3nkHPSJH1ka3xbdOglmOVkRljb21tb24uZG90LmRucy55YW5kZXgubmV0Ci9kbnMtcXVlcnk'Check. $ ver
Microsoft Windows [Version 6.1.7601]
$ dnscrypt-proxy.exe
[NOTICE] dnscrypt-proxy 2.1.8
[NOTICE] Network connectivity detected
[NOTICE] Now listening to 127.0.0.1:53 [UDP]
[NOTICE] Now listening to 127.0.0.1:53 [TCP]
[NOTICE] Source [public-resolvers] loaded
[NOTICE] Captive portals handler enabled
[NOTICE] Firefox workaround initialized
[NOTICE] [yandex-doh-new] OK (DoH) - rtt: 7ms
[NOTICE] [google-doh-new] OK (DoH) - rtt: 15ms
[NOTICE] [cloudflare-doh-new] OK (DoH) - rtt: 48ms
[NOTICE] Sorted latencies:
[NOTICE] - 7ms yandex-doh-new
[NOTICE] - 15ms google-doh-new
[NOTICE] - 48ms cloudflare-doh-new
[NOTICE] Server with the lowest initial latency: yandex-doh-new (rtt: 7ms)
[NOTICE] dnscrypt-proxy is ready - live servers: 3
$ doggo.exe wikipedia.org
NAME TYPE CLASS TTL ADDRESS NAMESERVER
wikipedia.org. A IN 2400s 185.15.59.224 127.0.0.1:53ExplanationDNSCrypt is an app written in Go. It uses not Schannel (TLS of Windows), but own crypto. Curl, Chrome and Firefox, which I use daily on Windows 7, also have own crypto and they work even with TLS 1.3 without issues. So, let's see which ciphers Go supports here and which Google DOH allows you to use. // contents of ciphers.go
package main
import (
"crypto/tls"
"fmt"
)
func main() {
fmt.Println("CipherSuites:")
suites := tls.CipherSuites()
for _, suite := range suites {
fmt.Println(suite.Name)
}
fmt.Println("InsecureCipherSuites:")
suites = tls.InsecureCipherSuites()
for _, suite := range suites {
fmt.Println(suite.Name)
}
}$ go version && go run ciphers.go
go version go1.23.6 windows/amd64
CipherSuites:
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
InsecureCipherSuites:
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
$ sslscan https://8.8.8.8:443
Preferred TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Curve 25519 DHE 253
Accepted TLSv1.3 256 bits TLS_CHACHA20_POLY1305_SHA256 Curve 25519 DHE 253
Preferred TLSv1.2 256 bits ECDHE-RSA-CHACHA20-POLY1305 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253We see overlapping values: TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. It means a Go app that uses its crypto package, even if it runs on Windows 7, can connect to Google DOH. Where is the root of the problem then? Let's use doggo, a DNSCrypt is off. $ doggo cern.ch @https://8.8.8.8/dns-query
level=ERROR msg="error in lookup" error="Post \"https://8.8.8.8/dns-query\": tls: failed to verify certificate: x509: certificate is valid for 8.8.8.8, 8.8.4.4, 2001:4860:4860::8888, 2001:4860:4860::8844, 2001:4860:4860::6464, 2001:4860:4860::64, not 8.8.8.8"
$ doggo cern.ch @https://8.8.8.8/dns-query --tls-hostname=dns.google
NAME TYPE CLASS TTL ADDRESS NAMESERVER
cern.ch. A IN 600s 188.184.77.250 https://8.8.8.8/dns-queryDNSCrypt is on. $ doggo dns.google
NAME TYPE CLASS TTL ADDRESS NAMESERVER
dns.google. A IN 2400s 8.8.4.4 127.0.0.1:53
dns.google. A IN 2400s 8.8.8.8 127.0.0.1:53
$ doggo cern.ch @https://8.8.8.8/dns-query
level=ERROR msg="error in lookup" error="Post \"https://8.8.8.8/dns-query\": tls: failed to verify certificate: x509: certificate is valid for 8.8.8.8, 8.8.4.4, 2001:4860:4860::8888, 2001:4860:4860::8844, 2001:4860:4860::6464, 2001:4860:4860::64, not 8.8.8.8"
$ doggo cern.ch @https://dns.google/dns-query
NAME TYPE CLASS TTL ADDRESS NAMESERVER
cern.ch. A IN 600s 188.184.77.250 https://dns.google/dns-queryWhat is striking about this output? Accessing Google DOH by its IP address is impossible without its domain. And if you specify its domain, then everything works. Obviously, we should check the stamps in ## google
Google DNS (anycast)
sdns://AgUAAAAAAAAABzguOC44LjggsKKKE4EwvtIbNjGjagI2607EdKSVHowYZtyvD9iPrkkHOC44LjguOAovZG5zLXF1ZXJ5
sdns://AgUAAAAAAAAABzguOC40LjQgsKKKE4EwvtIbNjGjagI2607EdKSVHowYZtyvD9iPrkkHOC44LjQuNAovZG5zLXF1ZXJ5
Oouch, no domain in the second field. We add MysteryAnd now you're probably wondering why we had to create new stamps to connect to these DOH servers, what exactly is wrong with the official ones? Perhaps the developers would please you with the answer to this question. But if I were them, I would first hurry to add (or ask the community to add) domains to all stamps related to DOH servers. |
|
I'm not a crypto expert. Go source code shows that it does use OS crypto stack on Windows. If it works, that's good for Win7 users. So that, is it IP form https domain name not supported by Win7? |
|
@sergeevabc, Thank you, this solution worked ;) But this will not help when downloading a full list of resolvers :( Only static configurations |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Output of the following commands:
./dnscrypt-proxy -version
2.1.7
./dnscrypt-proxy -check
./dnscrypt-proxy -resolve example.com
What is affected by this bug?
DNS resolving does not work when using certain resolvers
When does this occur?
When using certain resolvers. Google, Cloudflare, Yandex.
There are no problems with most of the resolvers :
Where does it happen?
Windows 7 X64 SP1, dnscrypt 2.1.7 (patched with golang - patcher) and 2.15 (the same story)
How do we replicate the issue?
The problem is reproduced on the newly installed Windows 7 X64 SP1 on Virtualbox and on the host system
Set in the settings
Expected behavior (i.e. solution)
Resolving through resolvers bypassing x509 error
The text was updated successfully, but these errors were encountered: