Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/tls: func (c *Conn) Handshake() returns an error on Windows 7 #30985

Closed
admitrevskiy opened this issue Mar 21, 2019 · 5 comments
Closed

crypto/tls: func (c *Conn) Handshake() returns an error on Windows 7 #30985

admitrevskiy opened this issue Mar 21, 2019 · 5 comments

Comments

@admitrevskiy
Copy link

@admitrevskiy admitrevskiy commented Mar 21, 2019

What version of Go are you using (go version)?

1.12

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

Windows 7 x64

What did you do?

Hi!
func (c *Conn) Handshake() in package crypto/tls/ works perfectly on every OS except for Windows 7/Windows 2012 R2/etc. The following example demonstrates the problem:
https://github.com/admitrevskiy/tls_example
Please note that the ServerName inside tls.Config is 1.1.1.1.

What did you expect to see?

No error

What did you see instead?

Failed to connect to 1.1.1.1:853, cause: x509: certificate is valid for
 1.1.1.1, 1.0.0.1, 162.159.132.53, 2606:4700:4700::1111, 2606:4700:4700::1001, 2
606:4700:4700::64, 2606:4700:4700::6400, not 1.1.1.1
@dmitshur dmitshur changed the title crypto/tls/: func (c *Conn) Handshake() returns an error on Windows 7 crypto/tls: func (c *Conn) Handshake() returns an error on Windows 7 Apr 18, 2019
@dmitshur dmitshur added this to the Go1.13 milestone Apr 18, 2019
@dmitshur dmitshur added the OS-Windows label Apr 18, 2019
@dmitshur

This comment has been minimized.

Copy link
Member

@dmitshur dmitshur commented Apr 18, 2019

@FiloSottile

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented Apr 18, 2019

@sleevi Does Windows 7 have known issues with IP SANs?

We use the system certificate verifier on Windows, so we might not be able to do much about this.

@sleevi

This comment has been minimized.

Copy link

@sleevi sleevi commented Apr 18, 2019

@FiloSottile Indeed Windows does! The CA/B Forum even published a lovely paper about how to "do iPAddress SANs right", based in part on my rantings and unwillingness to compromise on violating 5280 ;)

@sleevi

This comment has been minimized.

Copy link

@sleevi sleevi commented Apr 18, 2019

Since it requires the server (in this case, Cloudflare) to change how they use they construct the certificate, unfortunately, this incompatibility with the Windows verifier can only be resolved by them changing how they construct certificates.

In case you reach someone at Cloudflare who can make the change, a 'compatible' certificate would thus be:

  • 1.1.1.1 in the commonName
  • 1.1.1.1 as an iPAddress SAN
  • cloudflare-dns.com as a dNSName SAN
  • *.cloudflare-dns.com as a dNSName SAN
  • one.one.one.one as a dNSName SAN

They would create an equivalent certificate for each IP address they're serving.

For IPv6, Windows will do a direct string mapping to the CN, so that means it will be somewhat client-dependent as to how they entered the host in the above example. In general, using the compressed form (as that most reflects how users will enter in the address to connect) is likely the best approach.

@FiloSottile

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented Apr 18, 2019

This is unfortunate, but not worth overriding the system verifier for I'm afraid. (For example we would still end up not trusting IP address certificates signed by custom roots.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.