TLS failed to verify certificate when connect via IP

[flawrist]

Dear @KobeArthurScofield,

There is a long-standing problem with any Go app that uses TLS (e.g. doggo, dnslookup, dnscrypt, etc) in Windows 7. A user cannot connect to a DoH/DoT server by IP address alone, they must specify a domain. Otherwise, they see a certificate check error.

Let me illustrate it with Cloudflare DoH server: 1.1.1.1 vs one.one.one.one.

$ ver & go version
Microsoft Windows [Version 6.1.7601]
go version go1.24.4 windows/amd64

$ git clone ... && cd ... && go build ...
 
$ doggo ntp.ix.ru --short @https://1.1.1.1/dns-query
level=ERROR msg="error in lookup" error="Post \"https://1.1.1.1/dns-query\":
tls: failed to verify certificate: x509: certificate is valid for
1.0.0.1, 1.1.1.1, 162.159.36.1, 162.159.46.1, 2606:4700:4700::1001, 2606:4700:4700::1111, 2606:4700:4700::64, 2606:4700:4700::6400,
not 1.1.1.1"

$ doggo ntp.ix.ru --short @https://one.one.one.one/dns-query
194.190.168.1

In comparison, C++ apps (popular browsers, dig…) connect to DoH by IP without issues.

$ dig -v
DiG 9.17.15

$ dig ntp.ix.ru +short +https @1.1.1.1
194.190.168.1

Could you be so kind and help me find out if this is a problem with the patched Go SDK or a problem with the upstream Go network library (TLS component) itself?

[KobeArthurScofield]

Hmmm problem that could not be found out as the test does not seems thoroughly.

Can you help out to confirm something:

1. Will the problem still occur on a newer Windows version with a patched Go? Will the patched version behave differently from the normal version?
2. Does the patched Go 1.23 version (even with patched Go 1.22, patches are given) works right on Windows 7 and newer Windows? Go team may change something internally besides the calling system API between minor Go versions.
3. dnscrypt can be compiled with Go 1.21, and for Windows 7 with SHA-2 signature update installed, Go 1.21.0-1.21.4 works okay, did it also broken when using official Go SDK?

Because the testing environment is an off-lined Windows 7 SP1 virtual machine, there may be some bugs could not be easily found out. And accessing to the DNS service of Cloudflare is not available on my side, which make the checking become harder.

[flawrist]

I have no access to Windows 10 at the moment, but I can share my thoughts.

Let's take Go SDK out of the equation and run an older compiled version of any Go app that deals with TLS. For example, Doggo 0.5.7 is officially built using Go 1.21 and works on Windows 7 right out the box. I see the same error when accessing DoH server by IP alone as in the case of compiling the latest 1.0.5 version of Doggo using the patched Go.

$ doggo_v0.5.7_official.exe ntp.ix.ru --short @https://1.1.1.1/dns-query
level=ERROR msg="error in lookup" error="Post \"https://1.1.1.1/dns-query\":
tls: failed to verify certificate: x509: certificate is valid for
1.0.0.1, 1.1.1.1, 162.159.36.1, 162.159.46.1, 2606:4700:4700::1001, 2606:4700:4700::1111, 2606:4700:4700::64, 2606:4700:4700::6400,
not 1.1.1.1"

$ doggo_v1.0.5_patched.exe ntp.ix.ru --short @https://1.1.1.1/dns-query
level=ERROR msg="error in lookup" error="Post \"https://1.1.1.1/dns-query\":
tls: failed to verify certificate: x509: certificate is valid for
1.0.0.1, 1.1.1.1, 162.159.36.1, 162.159.46.1, 2606:4700:4700::1001, 2606:4700:4700::1111, 2606:4700:4700::64, 2606:4700:4700::6400,
not 1.1.1.1"

The same is true for DNSCrypt. I tried 2.1.5 (the last version that is officially built for Windows 7) and the latest 2.1.12 (built by myself using the patched Go). They both use information about DNS resolvers from public-resolvers.md file. Some resolvers (e.g. Google DoH, Yandex DoH) list bare IPs to connect to. So I see the following error.

[ERROR] Get "https://8.8.8.8/dns-query?dns=yv4BAAABAAAAAAABAAACAAEAACkQAAAAAAAAFAAMABDQtVR-BPvh3SqsMQ2_O90_": 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
[ERROR] Get "https://77.88.8.1/dns-query?dns=yv4BAAABAAAAAAABAAACAAEAACkQAAAAAAAAFAAMABDr8pZM5yMg2LOFoTubJJaK": tls: failed to verify certificate: x509: certificate is valid for 77.88.8.1, 77.88.8.2, 77.88.8.3, 77.88.8.7, 77.88.8.8, 77.88.8.88, not 77.88.8.1

However, if I replace IPs with domains, then everything works as expected.

[NOTICE] [google-doh-domain] OK (DoH) - rtt: 79ms
[NOTICE] [yandex-doh-domain] OK (DoH) - rtt: 39ms

Personally, this leads me to the conclusion that the problem is not with the patched Go SDK, but with Go network library. But it's always helpful to get a second opinion.

[KobeArthurScofield]

Thank you for the report. It seems there could be one or more upstream libraries have problems when handling TLS with bare IPs, which does not have TLS SNI when sending out the request.

I hope I can dig something out soon.

[flawrist]

I tried to connect to the DoH server by bare IP address using apps written in other languages on Windows 7. In all cases, it worked without issues, whereas Go apps fail.

✅ C and C++

• curl
• dig

$ ver & curl -V & dig -v
Microsoft Windows [Version 6.1.7601]
curl 8.13.0
DiG 9.17.15

$ curl -s -H "accept: application/dns-json" "https://1.1.1.1/dns-query?name=cern.ch" | jq -r .Answer[].data
188.184.77.250

$ dig cern.ch +short +https @1.1.1.1
188.184.77.250

✅ Rust

• dns-over-https

$ dns-over-https -u https://1.1.1.1/dns-query
[INFO  dns_over_https] Listening for DNS requests on 127.0.0.1:53...

$ nslookup cern.ch
Server:  Local
Address:  127.0.0.1

Non-authoritative answer:
Name:    cern.ch
Addresses:  2001:1458:d00:3c::100:2f9
            188.184.77.250

✅ Python

• dnspython

$ ver & python --version
Microsoft Windows [Version 6.1.7601]
Python 3.13.2

$ cat doh.py
import httpx
import dns.message
import dns.query
import dns.rdatatype
def main():
    where = "https://1.1.1.1/dns-query"
    qname = "cern.ch"
    with httpx.Client() as client:
        q = dns.message.make_query(qname, dns.rdatatype.A)
        r = dns.query.https(q, where, session=client)
        for answer in r.answer:
            print(answer)
if __name__ == "__main__":
    main()

$ python doh.py
cern.ch. 436 IN A 188.184.77.250

[muyu1944]

hi @sergeevabc , the error in your issue is triggered in crypto.x509.Certificate.VerifyHostname, that is nothing about tls, and your error looks like "A is not in A,B,C", which means the specific operation that triggered your error is "A is not A", you can read the source code of VerifyHostname, that operation is net.IP.Equal

so, to find what happened, lets do the VerifyHostname ourselves

package main
import (
  "fmt"
  "net"
  "crypto/tls"
)

func main () {
  //convert hostname string to net.IP
  ip := net.ParseIP("77.88.8.1")
  if ip == nil {
    fmt.Println("invalid ip")
    return
  }
  //skip verify to make the tls connect
  conn, err := tls.Dial("tcp", "77.88.8.1:443", &tls.Config{InsecureSkipVerify: true})
  if err != nil {
    fmt.Printf("conn error: %v\n", err)
    return
  }
  defer conn.Close()

  //the first cert of the PeerCertificates shoud be the server cert, lets check if the hostname is in its IPAddresses
  for _, candidate := range conn.ConnectionState().PeerCertificates[0].IPAddresses {
    fmt.Printf("IPAddress: ")
    for _, cc := range candidate {
      fmt.Printf("%d ", cc)
    }
    if ip.Equal(candidate) {
      fmt.Printf(" match\n")
      break
    }
    fmt.Printf("\n")
  }
}

I have no win7 environment, so I cant do the test for you, you can adjust the code according to the situation to see what happened

[KobeArthurScofield]

The win7 Go SDK just altered the use of several old system APIs, things should also work on normal versions, as this problem also affects normal Windows.

[muyu1944]

The win7 Go SDK just altered the use of several old system APIs, things should also work on normal versions, as this problem also affects normal Windows.

I do the test on win10, everything is fine, actually I dont think this is OS related, IP.Equal is just comparison between byte arrays