Docker 1.13 cli gives a warning about crypto/x509

[JettJones]

(moving from docker/for-win#422)

Expected behavior

Docker ouput should be free of warnings (unless there's something to fix)

Actual behavior

Docker 1.13.0 provides a developer warning on every run - it is reporting a library does not exist on windows. That's not something I can fix as a user.

>docker --version
time="2017-01-24T09:45:40-08:00" level=warning msg="Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows"
Docker version 1.13.0, build 49bf474

Information

• host distribution and version (Windows version, build number, etc)
  running on windows 10 pro, Version 1607 (OS Build 14292.693)

This might be an issue from Go's system cert pool: golang/go#16736
This may also be fixed if #24806 is completed.

Steps to reproduce the behavior

1. Install docker 1.13.0 on windows
2. Run docker --version (or any other command)

[denialg]

Same issue on Windows 7 Enterprise 64-bit

[thaJeztah]

ping @dmcgowan @jhowardmsft @johnstep ptal

[dmcgowan]

That is pretty obnoxious, if it is not actionable we should probably have it at INFO level. It will be fixed once we are building in 1.8 but considering it is non-critical we don't need it as a warning. Also curious why it is getting executed on every invocation rather than only when certificates are used.

[stevvooe]

@dmcgowan Warning is the right level here.

What is more disconcerting is why we are initializing the certs for the version command. Shouldn't these only get loaded if we create client?

[aaronlehmann]

version connects to the server to get the server version.

[cpuguy83]

--version does not need to contact the server since it should only be showing the client version, but it is apparently.

[aaronlehmann]

Ah, saw "version command" above and thought this was about docker version.

[xtrycatchx]

i encountered the same error. im using latest docker tool box

$ docker --version
time="2017-02-03T14:59:50+08:00" level=warning msg="Unable to use system certifi
cate pool: crypto/x509: system root pool is not available on Windows"
Docker version 1.13.0, build 49bf474

[galessandro]

I also have the same error. I recently download the latest doocker tool box. I am behind a proxy corporation

~ $ docker --version
time="2017-02-03T11:54:10-05:00" level=warning msg="Unable to use system certifi cate pool: crypto/x509: system root pool is not available on Windows"
Docker version 1.13.0, build 49bf474

~ $ docker run hello-world
time="2017-02-03T11:55:31-05:00" level=warning msg="Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows"
C:\Program Files\Docker Toolbox\docker.exe: Error response from daemon: client is newer than server (client API version: 1.24, server API version: 1.22).
See 'C:\Program Files\Docker Toolbox\docker.exe run --help'.

Any clue to fix that?

[dmcgowan]

@stevvooe seems to be part of the initialization of the client.

See https://github.com/docker/docker/blob/master/cmd/docker/docker.go#L48

Initialize creates an api client, which creates an http client, which uses the tls config. Only running the setup on commands which need the client would be tricky, but I don't think we need to load custom certs from the client anyway unless Docker Content Trust is used. It would require some refactoring to separate this out, in the meantime, I think the warning is unnecessary since the custom certs are not relevant to user and nothing can be done. In Go 1.8 this will all be irrelevant.

[stevvooe]

@dmcgowan After talking with @cyli, I think that the problem with that code is that it returns an empty pool for windows when it should actually return a nil pool. On windows, cert lookup falls back to a function and having an empty pool means we have no certs in place. Please confirm, but that should fix.

Good thing this warning was in place or no one would now that this is broken at all.

[cyli]

@stevvooe After confirming with @dmcgowan looks like in docker itself, the pool is used only if a custom cert is found: https://github.com/docker/docker/blob/master/registry/registry.go#L64. If no custom certs are found, a nil pool is used.