wget tries to get certificate from wrong server

[psl]

This report is for Ubuntu 12.04.4. I observe the problem with wget, git and maybe other utilities. wget helped me to understand this problem. I guess wget is not troublemaker, but there is a problem in somepart related to DNS.

There is some problem (or change) with OpenDNS that I use and that change has impact to SSL related services. Lets, try to download a certificate with wget:

$ wget -d https://www.digicert.com/CACerts/DigiCertSHA2ExtendedValidationServerCA.crt

DEBUG output created by Wget 1.13.4 on linux-gnu.

URI encoding = `UTF-8'
--2014-04-24 13:26:04-- https://www.digicert.com/CACerts/DigiCertSHA2ExtendedValidationServerCA.crt
Resolving www.digicert.com (www.digicert.com)... ::ffff:67.215.65.132, 64.78.193.234
Caching www.digicert.com => ::ffff:67.215.65.132 64.78.193.234
Connecting to www.digicert.com (www.digicert.com)|::ffff:67.215.65.132|:443... connected.
Created socket 3.
Releasing 0x08ca17d8 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x08ca1968
certificate:
  subject: /C=US/ST=California/L=San Francisco/O=OpenDNS, Inc./CN=*.opendns.com
  issuer: /C=US/O=DigiCert Inc/CN=DigiCert Secure Server CA
ERROR: no certificate subject alternative name matches
 requested host name `www.digicert.com'.
To connect to www.digicert.com insecurely, use `--no-check-certificate'.
Closed 3/SSL 0x08ca1968

Notice, that wget tries to download certificate from IPv6 address ::ffff:67.215.65.132; I don't have IPv6 connectivity...

Let's try to get DNS details about www.digicert.com, I use OpenDNS server:

$ host -a www.digicert.com 208.67.222.222
Trying "www.digicert.com"
Using domain server:
Name: 208.67.222.222
Address: 208.67.222.222#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17002
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.digicert.com. IN ANY

;; ANSWER SECTION:
www.digicert.com. 95 IN A 64.78.193.234
www.digicert.com. 0 IN AAAA ::ffff:67.215.65.132

Received 78 bytes from 208.67.222.222#53 in 62 ms

$ host -t A www.digicert.com 208.67.222.222
Using domain server:
Name: 208.67.222.222
Address: 208.67.222.222#53
Aliases:

www.digicert.com has address 64.78.193.234

$ host -t AAAA www.digicert.com 208.67.222.222
Using domain server:
Name: 208.67.222.222
Address: 208.67.222.222#53
Aliases:

www.digicert.com has no AAAA record

From these examples, I assume that record 0 IN AAAA returned by OpenDNS server is not valid and should be ignored. For some reason, wget (and git) tries to use AAAA record to download certificate...

[psl (slansky)]

Ubuntu 14.04 works better. Under similar conditions, AAAA record is ignored and wget downloads certificate from correct server:

$ wget -d https://www.digicert.com/CACerts/DigiCertSHA2ExtendedValidationServerCA.crt

DEBUG output created by Wget 1.15 on linux-gnu.

URI encoding = ‘UTF-8’
--2014-04-24 13:54:34-- https://www.digicert.com/CACerts/DigiCertSHA2ExtendedValidationServerCA.crt
Resolving www.digicert.com (www.digicert.com)... 64.78.193.234
Caching www.digicert.com => 64.78.193.234
Connecting to www.digicert.com (www.digicert.com)|64.78.193.234|:443... connected.
Created socket 3.
Releasing 0x00000000006ff3f0 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x00000000006ff670
certificate:
  subject: /businessCategory=Private Organization/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Utah/serialNumber=5299537-0142/street=Suite 500/street=2600 West Executive Parkway/postalCode=84043/C=US/ST=Utah/L=Lehi/O=DigiCert, Inc./CN=www.digicert.com
  issuer: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
X509 certificate successfully verified and matches host www.digicert.com

---request begin---
GET /CACerts/DigiCertSHA2ExtendedValidationServerCA.crt HTTP/1.1
User-Agent: Wget/1.15 (linux-gnu)
Accept: */*
Host: www.digicert.com
Connection: Keep-Alive
...

$ host -a www.digicert.com
Trying "www.digicert.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14219
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.digicert.com. IN ANY

;; ANSWER SECTION:
www.digicert.com. 299 IN A 64.78.193.234
www.digicert.com. 0 IN AAAA ::ffff:67.215.65.132

Received 78 bytes from 127.0.1.1#53 in 27 ms

$ host -t A www.digicert.com
www.digicert.com has address 64.78.193.234

$ host -t AAAA www.digicert.com
www.digicert.com has no AAAA record

[Simon Déziel (sdeziel)]

The problem seems to be from OpenDNS. See how it also pushes a bad record for this IPv4 only domain:

# dig -t any ppa.launchpad.net

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1~precise1 <<>> -t any ppa.launchpad.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15627
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ppa.launchpad.net. IN ANY

;; ANSWER SECTION:
ppa.launchpad.net. 72 IN A 91.189.95.83
ppa.launchpad.net. 0 IN AAAA ::ffff:67.215.65.132

;; Query time: 20 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Thu Apr 24 12:04:51 EDT 2014
;; MSG SIZE rcvd: 90

The IP "::ffff:67.215.65.132" shouldn't be there at all as it's the "page not found" redirect from OpenDNS.

[Simon Déziel (sdeziel)]

You should try using a different resolver (like Google DNS, 8.8.8.8 and 8.8.4.4) or tell wget to use IPv4 only with the "-4" flag.

[psl (slansky)]

OpenDNS support reported that problem was fixed. From my point of view it was really fixed...

Technical details:

The redirection problem should now be fixed.

Some technical detail: Computers that are configured to use both IPv6 and IPv4 will perform a DNS query for both the A and AAAA records for a given domain. Our resolvers will properly return a NODATA response for the AAAA record, but we are seeing the client then perform another query for the AAAA record with the local search suffix attached. This subsequent query will result in an NXDOMAIN response, and thus customers with NXDOMAIN redirection enabled will be redirected to our NXDOMAIN page. The A record query will properly return the IP address, but some clients may have a preference for AAAA records, or may choose one of the two responses at random, and thus get redirected to our NXDOMAIN page.

This extra AAAA query is unusual behaviour for a client, but we were able to mitigate it by removing the redirection for the AAAA record requests from our DNS servers.