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
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows Unfortunate
Milestone

Comments

@admitrevskiy
Copy link

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 the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 18, 2019
@dmitshur dmitshur added this to the Go1.13 milestone Apr 18, 2019
@dmitshur
Copy link
Contributor

/cc @FiloSottile

@FiloSottile
Copy link
Contributor

@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
Copy link

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
Copy link

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
Copy link
Contributor

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 subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows Unfortunate
Projects
None yet
Development

No branches or pull requests

5 participants