http-connect with MITM certificate causes domain mismatch

[HaxxonHax]

When attempting to use an HTTPS proxy with a Man-in-the-middle certificate, connections via Redsocks fail with "domain mismatch" or "no certificate subject alternative name matches". This has been tested using both a Root CA + Server pair and an Intermediate CA + Server certificate pair (along with passing the chain), as well as adding in the Proxy IP and Domains to the SAN.

Expected Behavior (succeeds from bypassing Redsocks, and using environment variables):

[vagrant@centos ~]$ https_proxy=192.168.13.11:8889 wget -dv --certificate=./wildcard.local.cert.pem --private-key=./wildcard.local.key.pem --ca-certificate=./ca-chain.pem https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.rpm
[...]
Connecting to 192.168.13.11:8889... connected.
Created socket 3.
Releasing 0x0000000000f58cc0 (new refcount 0).
Deleting unused 0x0000000000f58cc0.

---request begin---
CONNECT bin.equinox.io:443 HTTP/1.1
User-Agent: Wget/1.14 (linux-gnu)
Host: bin.equinox.io:443

---request end---
proxy responded with: [HTTP/1.1 200 Connection established

]
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x0000000000f5b6b0
certificate:
  subject: /CN=bin.equinox.io
  issuer:  /C=US/ST=Arizona/O=MyOffice, Inc./OU=MyOffice, Inc. Proxy Certificate Authority/CN=MyOffice, Inc. Intermediate CA
X509 certificate successfully verified and matches host bin.equinox.io
[...]

Actual behavior:

[vagrant@centos ~]$ wget -dv --certificate=./wildcard.local.cert.pem --private-key=./wildcard.local.key.pem --ca-certificate=./ca-chain.pem https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.rpm
[...]
--2019-12-16 21:31:52--  https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.rpm
Resolving bin.equinox.io (bin.equinox.io)... 54.164.175.20, 3.213.5.196, 54.164.7.157, ...
Caching bin.equinox.io => 54.164.175.20 3.213.5.196 54.164.7.157 52.4.202.19 3.234.122.223 34.206.134.194 50.17.165.171 34.236.27.247
Connecting to bin.equinox.io (bin.equinox.io)|54.164.175.20|:443... connected.
Created socket 3.
Releasing 0x00000000026fc470 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x00000000026fe040
certificate:
  subject: /CN=54.164.175.20
  issuer:  /C=US/ST=Arizona/O=MyOffice, Inc./OU=MyOffice, Inc. Proxy Certificate Authority/CN=MyOffice, Inc. Intermediate CA
ERROR: no certificate subject alternative name matches
	requested host name ‘bin.equinox.io’.
To connect to bin.equinox.io insecurely, use `--no-check-certificate'.
Closed 3/SSL 0x00000000026fe040

In the first behavior, the FQDN is passed to the proxy server, as seen in the access.log's first two lines; the last line is the failure of the attempt to connect via Redsocks. Note that the third line is the attempt via Redsocks, and only shows the IP of the requested site:

1576531096.500      0 192.168.13.19 TAG_NONE/200 0 CONNECT bin.equinox.io:443 - HIER_NONE/- -
1576531098.303   1763 192.168.13.19 TCP_MISS_ABORTED/200 17799058 GET https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.rpm - HIER_DIRECT/34.206.134.194 application/octet-stream
1576531912.875      0 192.168.13.19 TAG_NONE/200 0 CONNECT 54.164.175.20:443 - HIER_NONE/- -

In this specific example, the MITM Squid server is configured as an HTTPS intercept, ssl-bump, the intermediate certificate as its CA certificate, and set to automatically generate host certificates.