machine 🚀 - 证书安装不正确，总是重新生成

谢谢详细的总结。我以前也见过这样的问题，我会研究一下。

nathanleclaire 于 2015-10-08

您使用的是最新的 VirutalBox 吗？即 5.0.6？

nathanleclaire 于 2015-10-08

我使用的是 5.0.4，它随附有最新版本的 Docker Toolbox (1.8.2c)。我刚刚删除了那个版本，安装了 5.0.6 并且我遇到了同样的行为。

carolynvs 于 2015-10-08

好，谢谢。

nathanleclaire 于 2015-10-08

@carolynvs如果您删除了您拥有的仅主机网络（可以在 VirtualBox GUI 中执行此操作）

nathanleclaire 于 2015-10-08

我删除了机器，删除了适配器并再次尝试，结果相同。

carolynvs 于 2015-10-08

好，谢谢。非常奇特的行为。我可能会制作一个测试版本，它会转储有关证书的更多信息，如果您同意，建议您尝试一下。

nathanleclaire 于 2015-10-08

当然！我很乐意尽我所能提供帮助。

如果你只想创建一个分支并指向它，我可以自己构建它（:heart: 容器化构建！）。这样，如果这需要多次尝试，您就不需要在墙上扔多个构建。

carolynvs 于 2015-10-08

在解决这个问题时可能要考虑的另一件事是，一些像我这样的人实际上将docker-machine env的内容写到一个文件中，我将为每个新的终端会话提供该文件（因为它比运行docker-machine env快一点eval d 的内容，则显然会导致问题。

所以像下面这样的行会导致问题：

Invalid certs detected; regenerating for 192.168.99.100:2376
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...

我在0.5.0-dev上遇到过这个问题，但自从降级到0.4.1后就没有遇到过。

bentruyman 于 2015-10-10

我今天在候选版本上遇到了完全相同的行为。

blaggacao 于 2015-10-19

嗨@carolynvs @blaggacao ，非常感谢您的反馈。

我正在尝试重现/修复此错误。你能试试我创建的这个 PR (https://github.com/docker/machine/pull/2006) 来帮助调查这个 bug

dgageot 于 2015-10-19

好像我也在看这个。我正在使用digitalocean驱动程序在 OS X 上使用最新的master构建，所以这绝对与环境无关。我认为area/windows和area/driver-virtualbox标签在这里无关紧要:)

hairyhenderson 于 2015-10-19

嗨@hairyhenderson ，你可以尝试构建 PR #2006 并告诉我docker-machine -D env default的输出吗？

dgageot 于 2015-10-19

@dgageot - 有机会时会做。

我也在考虑更多关于这一点，并意识到我一直在做一个 _local_ 构建（即make build在 OS X 上，不使用容器）。过去go build表现不同的领域之一是围绕证书（特别是根 CA 证书），所以这_可能_与那个有关......我不知道。

但我会用#2006 重建并尝试一下。谢谢！

hairyhenderson 于 2015-10-19

@hairyhenderson这是一个很好的观点。我将使用交叉编译的 docker-machine 运行我的测试

dgageot 于 2015-10-19

@dgageot这是来自docker-machine -D env default的全新机器的失败输出https://gist.github.com/carolynvs/e2473d21c3376f1ebec2 。

我构建了 #2006 并将 docker-machine.exe 和 docker-machine-driver-virtualbox.exe 复制到 Docker Toolbox 安装目录。我在 Windows 10 上使用 Docker Toolbox 1.8.2c。

carolynvs 于 2015-10-19

我不够精通，不知道如何构建，如果我能弄清楚的话，也许我会在晚上看看。

blaggacao 于 2015-10-19

@carolynvs 非常感谢。我仍然不明白发生了什么，但你的日志会帮助我。

dgageot 于 2015-10-19

@carolynvs您能否提供以下输出：

VBoxManage list hostonlyifs
VBoxManage list dhcpservers

dgageot 于 2015-10-19

C:\Program Files\Oracle\VirtualBox>VBoxManage list hostonlyifs
Name:            VirtualBox Host-Only Ethernet Adapter
GUID:            3729f60a-d9c3-4daa-96ca-7ce7bae4ddcc
DHCP:            Disabled
IPAddress:       192.168.56.1
NetworkMask:     255.255.255.0
IPV6Address:     fe80:0000:0000:0000:9d6d:4449:fce1:e1cb
IPV6NetworkMaskPrefixLength: 64
HardwareAddress: 0a:00:27:00:00:00
MediumType:      Ethernet
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter

Name:            VirtualBox Host-Only Ethernet Adapter #2
GUID:            99076a32-c9e5-4930-895a-a35ee45c2542
DHCP:            Disabled
IPAddress:       192.168.99.1
NetworkMask:     255.255.255.0
IPV6Address:     fe80:0000:0000:0000:118b:39e1:36b9:a336
IPV6NetworkMaskPrefixLength: 64
HardwareAddress: 0a:00:27:00:00:00
MediumType:      Ethernet
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter #2


C:\Program Files\Oracle\VirtualBox>VBoxManage list dhcpservers
NetworkName:    HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter
IP:             192.168.56.100
NetworkMask:    255.255.255.0
lowerIPAddress: 192.168.56.101
upperIPAddress: 192.168.56.254
Enabled:        Yes

NetworkName:    HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter #2
IP:             192.168.99.6
NetworkMask:    255.255.255.0
lowerIPAddress: 192.168.99.100
upperIPAddress: 192.168.99.254
Enabled:        Yes

我发现我仍然偶尔会得到双主机适配器。我刚刚删除了它们并创建了一台新机器。当我运行docker-machine env default时，证书仍在重新生成。

这是第二次 VBoxManage 命令的输出（只有 1 个主机适配器）。

C:\Program Files\Oracle\VirtualBox>VBoxManage list hostonlyifs
Name:            VirtualBox Host-Only Ethernet Adapter
GUID:            2883b47a-862d-454e-9db7-42c3789585eb
DHCP:            Disabled
IPAddress:       192.168.99.1
NetworkMask:     255.255.255.0
IPV6Address:     fe80:0000:0000:0000:90ff:fd25:e5f0:8c92
IPV6NetworkMaskPrefixLength: 64
HardwareAddress: 0a:00:27:00:00:00
MediumType:      Ethernet
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter


C:\Program Files\Oracle\VirtualBox>VBoxManage list dhcpservers
NetworkName:    HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter
IP:             192.168.99.6
NetworkMask:    255.255.255.0
lowerIPAddress: 192.168.99.100
upperIPAddress: 192.168.99.254
Enabled:        Yes

carolynvs 于 2015-10-19

@carolynvs 到目前为止我不知道。
我在 PR 上推送了几次提交以打印更多信息并尝试一些事情。
如果您有时间更新获得的输出，那就太好了。

ping @nathanleclaire @dmp42知道吗？

dgageot 于 2015-10-19

这是新的输出： https :

如果有其他方法可以调试连接问题，请告诉我。我不太确定 docker-machine 正在检测是什么导致它重新生成证书，但很高兴在主机上的 /var/lib/boot2docker 中闲逛或比较 Windows 和主机之间的证书等，如果我知道的话寻找。

carolynvs 于 2015-10-19

@carolynvs那太棒了。正如您所指出的，问题出现在cert.go ：

Certs are not valid: read tcp 192.168.99.1:49755->192.168.99.100:2376: wsarecv: An established connection was aborted by the software in your host machine.

要么证书没有正确复制到虚拟机上。
或者无法在端口192.168.99.100:2376上访问 vm（主机网络配置？防火墙、vpn？vm 网络配置？）
或者我们检查的方式有问题。

如果您导出docker-machine env给出的环境变量并忽略错误，您是否能够连接到 docker 守护进程？

dgageot 于 2015-10-19

我可以 ping docker 主机并通过 ssh 进入它。当我忽略有关从docker-machine env重新生成证书的消息并手动设置变量时，我仍然无法连接到 docker 客户端。

An error occurred trying to connect: Get https://192.168.99.101:2376/v1.20/containers/json: WSARecv tcp 192.168.99.1:50072: An established connection was aborted by the software in your host machine.

在主机上的证书/var/lib/boot2docker/tls/不匹配的地方在~/.docker/machine/machines/default/ 。 /var/lib/boot2docker/中的证书与我本地机器上的相匹配。另外，在证书~/.docker/machine/certs/匹配什么是在~/.docker/machine/machines/default/ 。

我猜问题在于证书不匹配，这会阻止 docker-machine 安全地连接到 docker 守护进程，从而触发证书重新生成？

我已经验证了 docker 守护进程正在运行：

docker<strong i="18">@default2</strong>:/var/log$ ps aux | grep docker
root      2439  0.1  1.9 122904 19872 ?        Sl   13:23   0:00 /usr/local/bin/docker daemon -D -g /var/lib/docker -H unix:// -H tcp://0.0.0.0:2376 --label provider=virtualbox --tlsverify --tlscacert=/var/lib/boot2docker/ca.pem --tlscert=/var/lib/boot2docker/server.pem --tlskey=/var/lib/boot2docker/server-key.pem -s aufs

这里还有来自 boot2docker 和 docker 的日志： https ://gist.github.com/carolynvs/f7965455ebbceb85d4e6

carolynvs 于 2015-10-19

:+1: 谢谢！我觉得我们越来越近了 :smile:

blaggacao 于 2015-10-19

IIRC， /var/lib/boot2docker/tls中的证书是由 boot2docker OS 中的启动脚本在服务器端生成的，在当前机器模型中不用于任何东西（它们是 boot2docker-cli 历史上期望设置证书的遗留物向上）。

nathanleclaire 于 2015-10-20

@carolynvs @nathanleclaire我不知道。我在日志中的唯一区别是我使用的是 VBox 5.0.6 版和更新的 boot2docker。

dgageot 于 2015-10-20

@carolynvs您可以尝试使用 curl 连接到

$ openssl pkcs12 -export -in ~/.docker/machine/certs/cert.pem -inkey ~/.docker/machine/certs/key.pem -out ~/.docker/machine/certs/cert.pfx -password pass:supersecret
$ curl -v --cacert ~/.docker/machine/machines/default/ca.pem --cert ~/.docker/machine/certs/cert.pfx --pass supersecret https://192.168.99.100:2376/version

*   Trying 192.168.99.100...
* Connected to 192.168.99.100 (192.168.99.100) port 2376 (#0)
* WARNING: SSL: Certificate type not set, assuming PKCS#12 format.
* Client certificate: dgageot
* WARNING: using IP address, SNI is being disabled by the OS.
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: default
* Server certificate: dgageot
> GET /version HTTP/1.1
> Host: 192.168.99.100:2376
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Server: Docker/1.8.3 (linux)
< Date: Tue, 20 Oct 2015 14:47:14 GMT
< Content-Length: 192
<
{"Version":"1.8.3","ApiVersion":"1.20","GitCommit":"f4bf5c7","GoVersion":"go1.4.2","Os":"linux","Arch":"amd64","KernelVersion":"4.1.10-boot2docker","BuildTime":"Mon Oct 12 18:01:15 UTC 2015"}
* Connection #0 to host 192.168.99.100 left intact

FTR，这是我用来使它工作的教程： http :

dgageot 于 2015-10-20

@dgageot哦，是的，这似乎是我机器上的问题（使用来自 Git for Windows 的 curl/openssl，因此所有命令都相同）。

$ openssl pkcs12 -export -in ~/.docker/machine/certs/cert.pem -inkey ~/.docker/machine/certs/key.pem -out ~/.docker/machine/certs/cert.pfx -password pass:supersecret
Loading 'screen' into random state - done

caro8994<strong i="7">@CAROLYNVANS87E4</strong> MINGW64 ~
$ docker-machine ip default
192.168.99.100

caro8994<strong i="8">@CAROLYNVANS87E4</strong> MINGW64 ~
$ curl -v --cacert ~/.docker/machine/machines/default/ca.pem --cert ~/.docker/machine/certs/cert.pfx --pass supersecret https://192.168.99.100:2376/version
* timeout on name lookup is not supported
*   Trying 192.168.99.100...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to 192.168.99.100 (192.168.99.100) port 2376 (#0)
* ALPN, offering http/1.1
* could not load PEM client certificate, OpenSSL error error:0906D06C:PEM routines:PEM_read_bio:no start line, (no key found, wrong pass phrase, or wrong file format?)
* Closing connection 0
curl: (58) could not load PEM client certificate, OpenSSL error error:0906D06C:PEM routines:PEM_read_bio:no start line, (no key found, wrong pass phrase, or wrong file format?)

我使用vi -b path/to/cert检查了 ~/.docker/machine/certs 中的所有证书，并验证它有 unix 行结尾。我还使用以下命令来尝试检查 openssl 是否能够读取它们。

$ openssl x509 -in .docker/machine/certs/cert.pem -inform PEM -text -noout

我会继续研究证书，因为这似乎是问题所在。也许在另一台机器上尝试一下，看看它是否只是 Windows 10 的东西。

carolynvs 于 2015-10-20

@carolynvs 干得好！我明天早上检查一下（巴黎时间）

dgageot 于 2015-10-20

嗨@carolynvs ，您是否也在ca.pem上尝试过这个命令？

openssl x509 -in ~/.docker/machine/machines/default/ca.pem -inform PEM -text -noout

你可以检查它正确地开始-----BEGIN CERTIFICATE-----和有端-----END CERTIFICATE----- 。之前和之后都没有。

dgageot 于 2015-10-21

@carolynvs我必须承认我不知道发生了什么。你有没有试过这个似乎模糊相关的公关。

dgageot 于 2015-10-21

如果你不介意确认这个中间总结，那么我可以默默地花脑子：

证书被复制，但无法读取？

我确定，您已经检查过： http :
我把它供其他人参考。

blaggacao 于 2015-10-21

我只是使用 --cert 和 --key 而不是生成的 pfx 文件尝试了一个不同的 curl 命令，它能够连接。

$ curl --cacert ~/.docker/machine/machines/bugtest/ca.pem --cert ~/.docker/machine/machines/bugtest/cert.pem --key ~/.docker/machine/machines/bugtest/key.pem https://$(docker-machine ip bugtest):2376/version
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   192  100   192    0     0   1761      0 --:--:-- --:--:-- --:--:--  1761{"Version":"1.8.3","ApiVersion":"1.20","GitCommit":"f4bf5c7","GoVersion":"go1.4.2","Os":"linux","Arch":"amd64","KernelVersion":"4.1.10-boot2docker","BuildTime":"Mon Oct 12 18:01:15 UTC 2015"}

更仔细地查看docker-machine env的输出，我发现它正在导出我认为不好的证书路径。在我的 Mac 上，这指向 .docker/machines/machine/而在下面的输出中，它指向 .docker/machine/certs。

$ docker-machine env bugtest
Certs are not valid: remote error: bad certificate
Invalid certs detected; regenerating for 192.168.99.102:2376
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.102:2376"
export DOCKER_CERT_PATH="C:\Users\caro8994\.docker\machine\certs"
export DOCKER_MACHINE_NAME="bugtest"
# Run this command to configure your shell:
# eval "$(C:\Program Files\Docker Toolbox\docker-machine.exe env bugtest)"

手动设置环境变量后，将证书路径更改为我认为应该是的，我可以连接到docker客户端。

也许当 docker-machine 正在测试它是否可以连接时，它使用了错误的证书？

我在验证证书时添加了一些调试信息，然后尝试首先使用 docker-machine 正在使用的内容然后我认为应该使用的内容进行手动连接。

caro8994<strong i="16">@CAROLYNVANS87E4</strong> MINGW64 ~
$ docker-machine env bugtest
HOST URL=192.168.99.102:2376
CA CERT PATH=C:\Users\caro8994\.docker\machine\certs\ca.pem
SERVER CERT PATH=C:\Users\caro8994\.docker\machine\machines\bugtest\server.pem
SERVER KEY PATH=C:\Users\caro8994\.docker\machine\machines\bugtest\server-key.pem
Certs are not valid: read tcp 192.168.99.1:50658->192.168.99.102:2376: wsarecv: An established connection was aborted by the software in your host machine.
Invalid certs detected; regenerating for 192.168.99.102:2376
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.102:2376"
export DOCKER_CERT_PATH="C:\Users\caro8994\.docker\machine\certs"
export DOCKER_MACHINE_NAME="bugtest"
# Run this command to configure your shell:
# eval "$(C:\Program Files\Docker Toolbox\docker-machine.exe env bugtest)"

caro8994<strong i="17">@CAROLYNVANS87E4</strong> MINGW64 ~
$ curl --cacert ~/.docker/machine/certs/ca.pem --cert ~/.docker/machine/machines/bugtest/server.pem --key ~/.docker/machine/machines/bugtest/server-key.pem https://$(docker-machine ip bugtest):2376/version
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (35) error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate

caro8994<strong i="18">@CAROLYNVANS87E4</strong> MINGW64 ~
$ curl --cacert ~/.docker/machine/certs/ca.pem --cert ~/.docker/machine/machines/bugtest/cert.pem --key ~/.docker/machine/machines/bugtest/key.pem https://$(docker-machine ip bugtest):2376/version
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   192  100   192    0     0    472      0 --:--:-- --:--:-- --:--:--   472{"Version":"1.8.3","ApiVersion":"1.20","GitCommit":"f4bf5c7","GoVersion":"go1.4.2","Os":"linux", "Arch":"amd64","KernelVersion":"4.1.10-boot2docker","BuildTime":"Mon Oct 12 18:01:15 UTC 2015"}

所以我看到了两个可疑的事情：

DOCKER_CERT_PATH 使用 .docker/machine/certs 而不是 .docker/machine/machines/
验证使用 server.pem 和 server-key.pem 而不是 cert.pem 和 key.pem。我不知道每个证书的用途，但这似乎不对。

carolynvs 于 2015-10-21

非常感谢@carolynvs ，这真的https://github.com/docker/machine/pull/2006它应该打印用于验证的证书。那应该有帮助

dgageot 于 2015-10-21

这是它正在使用的证书

主机 URL=192.168.99.102:2376
CA CERT PATH=C:\Users\caro8994.docker\machine\certsca.pem
服务器证书路径=C:\Users\caro8994.docker\machine\machines\bugtest\server.pem
服务器密钥路径=C:\Users\caro8994.docker\machine\machines\bugtest\server-key.pem

那是来自我自己的调试信息，而不是现在需要很长时间才能构建的 PR，因为它正在构建所有插件。：微笑：

carolynvs 于 2015-10-21

好的，现在我很困惑，所以我会尝试回顾一下。

您能否确认：

~/.docker/machine/certs/ca.pem与~/.docker/machine/machines/bugtest/ca.pem
~/.docker/machine/certs/cert.pem与~/.docker/machine/machines/bugtest/cert.pem
~/.docker/machine/certs/key.pem与~/.docker/machine/machines/bugtest/key.pem
您设法使docker cli 到达服务器。您当时使用了DOCKER_CERT_PATH哪个值？
在您的 Mac 上， docker-machine env bugtest打印 export DOCKER_CERT_PATH="~/.docker/machine"而不是DOCKER_CERT_PATH="~/.docker/machine/certs"

再次感谢支持！

dgageot 于 2015-10-21

@carolynvs FTR，仅交叉构建

dgageot 于 2015-10-21

对不起脑残！

ca.pem、cert.pem 和 key.pm 在~/.docker/machine/certs和~/.docker/machine/machines/bugtest
当我将DOCKER_CERT_PATH为~.docker/machine/machines/bugtest时，docker 客户端工作
在我的 mac（有效）上docker-machine env设置DOCKER_CERT_PATH="~/.docker/machine/machines/bugtest" 。在 Windows 10（没有）上，相同的命令导致DOCKER_CERT_PATH="~/.docker/machine/certs"

这是在我的大脑转储中，但可能已经丢失了。当 docker-machine 验证证书时，它会尝试使用 server.pem 和 server-key.pem 连接到 docker 守护进程。这看起来超级可疑。

carolynvs 于 2015-10-21

好的。让我们致电@nathanleclaire和@ehazlett来救援。我想你已经搞定了，但是现在，我对这个项目太陌生了，无法理解为什么我们有这么多重复的证书以及为什么我们不使用正确的证书。

dgageot 于 2015-10-21

感谢您的构建提示！

以下是最新版本的 PR #2006 的相关输出，这里是完整的输出： https :

Reading CA certificate from C:\Users\caro8994\.docker\machine\certs\ca.pem
Reading server certificate from C:\Users\caro8994\.docker\machine\machines\bugtest\server.pem
Reading server key from C:\Users\caro8994\.docker\machine\machines\bugtest\server-key.pem

carolynvs 于 2015-10-21

很抱歉关闭/重新打开的噪音。我摸索着

dgageot 于 2015-10-21

哎哟。 @carolynvs @dgageot你们都是继续追逐这一目标的冠军。我认为 Carolyn 的怀疑是正确的：如果DOCKER_CERT_PATH没有正确设置，那么与守护进程的通信将无法正常工作。听起来这可能是我在libmachine更改中无意中引入的路径的问题。到目前为止，我将继续对此进行调查并仔细研究您的发现。

nathanleclaire 于 2015-10-21

那么，通往罪魁祸首的大门可能是这条线吗？
https://github.com/docker/machine/blob/8aa1572e0dcd75762a7627e1056ef104317f44b9/libmachine/persist/filestore.go#L155

blaggacao 于 2015-10-21

@blaggacao在可能性领域绝对是强 - 该代码往往有点脆弱并且过去一直存在问题。

nathanleclaire 于 2015-10-21

我不明白这在 windows 和 mac os 上有什么不同，尽管@carolynvs证实了这一点。
对我来说，它清楚地构建了.docker\machine\certs路径。

blaggacao 于 2015-10-21

diff .docker/machine/certs/ca.pem .docker/machine/machines/oca/ca.pem
diff .docker/machine/certs/cert.pem .docker/machine/machines/oca/cert.pem
diff .docker/machine/certs/key.pem .docker/machine/machines/oca/key.pem

保持沉默。

blaggacao 于 2015-10-21

@blaggacao显然，我的行为与 mac 上的@carolynvs不同。所以有一些可疑的东西。

dgageot 于 2015-10-21

是的，在配置位期间，证书会被复制到该机器的目录中。

nathanleclaire 于 2015-10-21

@dgageot为混淆道歉。我的 mac 正在运行 docker-machine 0.4.1。我只在我的 Windows 机器上运行 PR 版本，因为我一直在那里测试修复程序，因为它们已合并到 master 中。

我现在可以在我的 mac 上进行构建并再次运行。

carolynvs 于 2015-10-21

我继续：

差异未显示/machine/certs和/machine/machines/certs之间的差异
我无法重现 carlynvs workarround 来解决问题。

blaggacao 于 2015-10-21

在 Windows 上（在 bash 中）手动设置 DOCKER_CERT_PATH 时，您应该使用 UNIX 样式路径。例如， export DOCKER_CERT_PATH="~./docker/machine/machines/oca" 。

我可以确认在我的（不稳定的）机器上，证书在 /machine/certs 和 /machine/machines/certs 之间匹配。

carolynvs 于 2015-10-21

我可以通过手动复制来确认，因为 scp 不起作用：

diff ca.pem.local       ca.pem.vm       FALSE
diff server.pem.local   server.pem.vm   TRUE
diff key.pam.local      key.pem.vm      TRUE

第二个和第三个在/machines/oca和oca:~/.docker

blaggacao 于 2015-10-21

您使用虚拟机中的哪些路径来获取证书@blaggacao ？

nathanleclaire 于 2015-10-21

我才意识到，这是错误的...

我检查了~/.docker我将再次检查/var/lib/boot2docker

blaggacao 于 2015-10-21

我可以确定地确认

/machines/oca和oca:/var/lib/boot2docker/中的证书是相同的
（I运行dos2unix上的所有3个fiels ca.pem ， server.pem ， sever-key.pem上oca ）

blaggacao 于 2015-10-21

我还收到此超时错误： https :
每次我使用--native-ssh标志运行env

blaggacao 于 2015-10-21

是的， @blaggacao看起来您的计算机上也无法访问分配给 VM 的仅主机 IP。你能ping $(docker-machine ip vmname)吗？

nathanleclaire 于 2015-10-21

不，也不起作用......“请求超时”

blaggacao 于 2015-10-21

docker-machine ssh vmname虽然有效

blaggacao 于 2015-10-21

是的， ssh穿过localhost 。但似乎您无法仅联系分配的主机 VM IP，因此我不希望env能够正常运行。您是否使用任何 VPN 或代理？

nathanleclaire 于 2015-10-21

不，我会知道，只是仔细检查了任务管理器...更新检测到一个，关闭

blaggacao 于 2015-10-21

关闭不会改变任何事情，但这是另一个问题，我认为......

blaggacao 于 2015-10-21

https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/commands/config.go#L88

带我去

https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L177

因为我没有得到任何： https :

剩下的唯一候选人是：
https://github.com/docker/machine/blob/56f457c2ef6e306fb1815b6b125f98c85a6e92ec/libmachine/cert/cert.go#L198 -L205

blaggacao 于 2015-10-21

这闻起来像是两个问题之间的联系。你能解释一下我的思路吗？

blaggacao 于 2015-10-21

远程挖掘： https :

blaggacao 于 2015-10-22

我不再信任我的 Windows 环境，所以我重新开始并重建 Windows，然后使用 #2006。

在 docker.log 文件中，我看到了这个错误

2015/10/21 17:06:23 http: TLS handshake error from 192.168.99.1:50386: tls: failed to verify client's certificate: x509: certificate has expired or is not yet valid

所以我检查了证书的日期

$ openssl x509 -in server.pem -noout -dates
notBefore=Oct 21 22:00:00 2015 GMT
notAfter=Oct  5 22:00:00 2018 GMT

问题可能是证书是未来的日期吗？这将解释为什么我的 curl 命令最初不起作用，但几个小时后它们起作用了。

carolynvs 于 2015-10-22

同样在这里：

$ openssl x509 -in .docker/machine/machines/oca/server.pem -noout -dates
notBefore=Oct 21 22:00:00 2015 GMT
notAfter=Oct  5 22:00:00 2018 GMT

在我的时区（波哥大/美洲）大约需要 5 个小时，但它显示的是 GMT（UTC）。波哥大是 UTC-5

blaggacao 于 2015-10-22

docker<strong i="5">@oca</strong>:~$ time
BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.

blaggacao 于 2015-10-22

更新：修复

如此处所述： https :

docker-machine ssh vmname
sudo ntpclient -s -h pool.ntp.org

给我一个不同的错误（一次一个步骤:)

blaggacao 于 2015-10-22

我想就是这样，剩下的就是我的虚拟机。

blaggacao 于 2015-10-22

当我怀疑我的证书将有效并且一切正常时，我将吃晚饭并在 5 小时后回来查看。：微笑：

carolynvs 于 2015-10-22

坏消息，我必须在每次虚拟机重启时都这样做。

blaggacao 于 2015-10-22

:smile: 我猜你找到了根本原因！谢谢！

blaggacao 于 2015-10-22

:clap::clap::clap::clap::clap::clap::clap:

blaggacao 于 2015-10-22

@carolynvs是否为您发布了我发布的修复程序？

blaggacao 于 2015-10-22

我只是想确认在等待 5 个小时直到证书有效后，docker-machine env 工作正常。不知道为什么我会得到未来过时的证书，但现在我们知道，也许应该更新问题以反映真正的根本原因。

carolynvs 于 2015-10-22

在我的情况下，问题不是证书，而是 boot2docker 上的时间设置......正如我在你的 github 个人资料中看到的，你来自芝加哥，这与波哥大的时区相似，也许 boot2docker 在我们的时区设置错误...

blaggacao 于 2015-10-22

使用您的解决方法同步时间后，在使用这些证书连接到我的 docker 主机时，我仍然收到相同的错误（证书已过期或尚未生效）。

在我的 Mac 上，这是我在制作一个新盒子并检查其时间后看到的。

docker<strong i="7">@bugtest</strong>:~$ time
BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.

docker<strong i="8">@bugtest</strong>:~$ hwclock
Thu Oct 22 15:54:29 2015  0.000000 seconds

docker<strong i="9">@bugtest</strong>:~$ date
Thu Oct 22 15:54:06 UTC 2015

docker<strong i="10">@bugtest</strong>:~$ openssl x509 -in /var/lib/boot2docker/server.pem -noout -dates
notBefore=Oct 22 15:48:00 2015 GMT
notAfter=Oct  6 15:48:00 2018 GMT

以下是 Windows 上新主机上的相同命令：

docker<strong i="14">@bugtest</strong>:~$ time
BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.

docker<strong i="15">@bugtest</strong>:~$ hwclock
Thu Oct 22 15:58:56 2015  0.000000 seconds

docker<strong i="16">@bugtest</strong>:~$ date
Thu Oct 22 10:58:58 UTC 2015

docker<strong i="17">@bugtest</strong>:~$ openssl x509 -in /var/lib/boot2docker/server.pem -noout -dates
notBefore=Oct 22 15:45:00 2015 GMT
notAfter=Oct  6 15:45:00 2018 GMT

日期显示我的本地时间，但认为它是 UTC，我不知道如何更新它以匹配 hwclock。我试过手动更改日期，但有一些关于 busybox 或 virtualbox 的东西会立即撤消任何更改。

carolynvs 于 2015-10-22

应用解决方法后，这是昨天的工作状态：

docker<strong i="6">@oca</strong>:~$ time
BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.
docker<strong i="7">@oca</strong>:~$ hwclock
Thu Oct 22 10:10:46 2015  0.000000 seconds
docker<strong i="8">@oca</strong>:~$ date
Thu Oct 22 16:28:19 UTC 2015
docker<strong i="9">@oca</strong>:~$
docker<strong i="10">@oca</strong>:~$ openssl x509 -in /var/lib/boot2docker/server.pem -noout -dates
notBefore=Oct 21 22:32:00 2015 GMT
notAfter=Oct  5 22:32:00 2018 GMT

在这里， date对应于以 UTC 表示的本地时间

我的症状的一些提示： https ://forums.virtualbox.org/viewtopic.php =3& t

time被冻结，10 分钟后： docker<strong i="18">@oca</strong>:~$ time BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.

由于date在我的情况下显示正确的日期，我假设在我的情况下解决方法固定日期，因此问题。

blaggacao 于 2015-10-22

cc @tianon @SvenDowideit PTAL 在上面的回复：boot2docker 时间/日期问题 ^^

nathanleclaire 于 2015-10-22

我发现的一些代码可能会导致时间戳问题：

https://github.com/docker/machine/blob/master/libmachine/cert/cert.go#L53 -L56

但它之前一直运行良好。

nathanleclaire 于 2015-11-03

@carolynvs @blaggacao你还遇到过这些问题吗？

nathanleclaire 于 2015-11-03

对我来说，它在引用的解决方法之后工作。这反过来表明，某些 boot2docker 时间参数设置不正确。通常，它只会在机器创建后的有限时间范围内发生。（可能仅在某些时区）。

这再次意味着，证书时间戳将是正确的。

blaggacao 于 2015-11-03

刚刚在我的 rc 上重新启动电脑后，我确实再次偶然发现了这个问题，但是在更新到 5.0 之后，一切似乎都正常了。我们现在可能可以关闭它。无论如何，一旦我注意到奇怪的行为，我就会重新打开它。

blaggacao 于 2015-11-05

https://gist.github.com/damontic/bd60b6a18cacf635dc9c

我也有这个问题。不要关闭它。

damontic 于 2015-11-13

@damontic这看起来与这里讨论的问题不同。

nathanleclaire 于 2015-11-13

我正在尝试在 DigitalOcean 上设置一个群，但我遇到了同样的错误。

init-do.sh 文件，用于创建 KV 存储、swarm master 和节点：

 # KV Store
docker-machine create \
--driver digitalocean \
--digitalocean-access-token ${TOKEN} \
--digitalocean-region "lon1" \
--digitalocean-size "1gb" \
consul
eval "$(docker-machine env consul)"
docker run -d -p "8500:8500" -h "consul" progrium/consul -server -bootstrap

sleep 5

# Swarm master
docker-machine create \
--driver digitalocean \
--digitalocean-access-token ${TOKEN} \
--digitalocean-region "lon1" \
--digitalocean-size "1gb" \
--swarm --swarm-image="swarm" --swarm-master \
--swarm-discovery="consul://$(docker-machine ip consul):8500" \
--engine-opt="cluster-store=consul://$(docker-machine ip consul):8500" \
--engine-opt="cluster-advertise=eth1:2376" \
demo0

sleep 5

# Swarm node
docker-machine create \
--driver digitalocean \
--digitalocean-access-token ${TOKEN} \
--digitalocean-region "lon1" \
--digitalocean-size "1gb" \
--swarm --swarm-image="swarm:1.0.0-rc2" \
--swarm-discovery="consul://$(docker-machine ip consul):8500" \
--engine-opt="cluster-store=consul://$(docker-machine ip consul):8500" \
--engine-opt="cluster-advertise=eth1:2376" \
demo1

我得到的日志/错误

$> ./init-do.sh
Running pre-create checks...
Creating machine...
(consul) OUT | Creating SSH key...
(consul) OUT | Creating Digital Ocean droplet...
(consul) OUT | Waiting for IP address to be assigned to the Droplet... 
Waiting for machine to be running, this may take a few minutes... 
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning created instance...
Copying certs to the local machine directory... 
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
To see how to connect Docker to this machine, run: docker-machine env consul
Unable to find image 'progrium/consul:latest' locally
latest: Pulling from progrium/consul
3b4d28ce80e4: Pull complete
...
d9125e9e799b: Pull complete
Digest: sha256:8cc8023462905929df9a79ff67ee435a36848ce7a10f18d6d0faba9306b97274
Status: Downloaded newer image for progrium/consul:latest
ab964fd70394d34f8d1de5c76246490b5857adaffbc1c02235bdc53663c33b37
Running pre-create checks...
Creating machine...
(demo0) OUT | Creating SSH key...
(demo0) OUT | Creating Digital Ocean droplet...
(demo0) OUT | Waiting for IP address to be assigned to the Droplet...
Waiting for machine to be running, this may take a few minutes... 
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning created instance...
Copying certs to the local machine directory... 
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Error creating machine: Error running provisioning: Unable to verify the Docker daemon is listening:        Maximum number of retries (5) exceeded
Running pre-create checks...
Creating machine...
(demo1) OUT | Creating SSH key...
(demo1) OUT | Creating Digital Ocean droplet...
(demo1) OUT | Waiting for IP address to be assigned to the Droplet...  
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning created instance...
Error creating machine: Error running provisioning: Something went wrong running an SSH command!
command : sudo apt-get update
err     : exit status 100
output  : Ign http://mirrors.digitalocean.com trusty InRelease
Get:1 http://mirrors.digitalocean.com trusty-updates InRelease [64.4 kB]
Hit http://mirrors.digitalocean.com trusty Release.gpg
Hit http://mirrors.digitalocean.com trusty Release
Get:2 http://mirrors.digitalocean.com trusty-updates/main Sources [244 kB]
Get:3 http://mirrors.digitalocean.com trusty-updates/universe Sources [144 kB]
Get:4 http://mirrors.digitalocean.com trusty-updates/main amd64 Packages [652 kB]
Get:5 http://mirrors.digitalocean.com trusty-updates/universe amd64 Packages [331 kB] 
Get:6 http://mirrors.digitalocean.com trusty-updates/main i386 Packages [631 kB]
Get:7 http://mirrors.digitalocean.com trusty-updates/universe i386 Packages [332 kB]
Get:8 http://mirrors.digitalocean.com trusty-updates/main Translation-en [319 kB]
Get:9 http://security.ubuntu.com trusty-security InRelease [64.4 kB]
Get:10 http://mirrors.digitalocean.com trusty-updates/universe Translation-en [173 kB]
Hit http://mirrors.digitalocean.com trusty/main Sources
Hit http://mirrors.digitalocean.com trusty/universe Sources
Hit http://mirrors.digitalocean.com trusty/main amd64 Packages
Hit http://mirrors.digitalocean.com trusty/universe amd64 Packages
Hit http://mirrors.digitalocean.com trusty/main i386 Packages
Hit http://mirrors.digitalocean.com trusty/universe i386 Packages
Hit http://mirrors.digitalocean.com trusty/main Translation-en
Hit http://mirrors.digitalocean.com trusty/universe Translation-en
Ign http://mirrors.digitalocean.com trusty/main Translation-en_US
Ign http://mirrors.digitalocean.com trusty/universe Translation-en_US
Get:11 http://security.ubuntu.com trusty-security/main Sources [99.2 kB]
Get:12 http://security.ubuntu.com trusty-security/universe Sources [32.5 kB]
Get:13 http://security.ubuntu.com trusty-security/main amd64 Packages [370 kB]
Get:14 http://security.ubuntu.com trusty-security/universe amd64 Packages [122 kB]
Get:15 http://security.ubuntu.com trusty-security/main i386 Packages [350 kB]
Get:16 http://security.ubuntu.com trusty-security/universe i386 Packages [123 kB]   
Get:17 http://security.ubuntu.com trusty-security/main Translation-en [200 kB]
Get:18 http://security.ubuntu.com trusty-security/universe Translation-en [69.6 kB]
Fetched 4,323 kB in 4s (925 kB/s) 
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/universe/i18n/Translation-en    Hash Sum mismatch

E: Some index files failed to download. They have been ignored, or old ones used instead.

在运行这个之前，我更新到 Machine 0.5.1

$ docker-machine -v
docker-machine version 0.5.1 (7e8e38e)

我可以转到机器“consul”的上下文，但不能转到“demo0”或“demo1”

$ docker-machine env consul
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://178.62.93.196:2376"
export DOCKER_CERT_PATH="/Users/luc/.docker/machine/machines/consul"
export DOCKER_MACHINE_NAME="consul"
# Run this command to configure your shell:
# eval "$(/usr/local/bin/docker-machine env consul)"

$ docker-machine env    demo0
Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error   validating certificates for host "46.101.74.179:2376": dial tcp 46.101.74.179:2376: getsockopt: connection  refused
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

$ docker-machine env demo1
Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error  validating certificates for host "46.101.17.195:2376": open   /Users/luc/.docker/machine/machines/demo1/server.pem: no such file or directory
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

lucj 于 2015-11-18

@lucj如果配置失败，创建的实例将是“无效的”。尝试删除它们并从头开始。

nathanleclaire 于 2015-11-18

@nathanleclaire我刚刚删除了机器（'docker-machine rm consul demo0 demo1' 足够了，还是我应该手动删除一些其他东西？）并使用安装文件重新运行，我遇到了相同的证书问题（在 DigitalOcean 上创建时）。奇怪的是'consul'机器没有问题，但只有swarm机器（demo0，demo1）有问题。

在 VirtualBox (5.0.10) 上创建集群时，它工作正常。

lucj 于 2015-11-18

我在使用 aws 驱动程序时看到了这个

dzlab 于 2015-11-25

我已经做了几个测试（实际上很多），在删除 VM 并重新创建它们（使用一个群）之后，我仍然遇到同样的问题。

lucj 于 2015-11-25

在 MacOSX 10.10.5 上使用 docker 工具箱从 1.8 版升级到 1.9.1 版后，我现在遇到了这个问题

Error running connection boilerplate: Error checking and/or regenerating the certs: There was an error validating certificates for host "192.168.99.100:2376": dial tcp 192.168.99.100:2376: getsockopt: connection refused
You can attempt to regenerate them using 'docker-machine regenerate-certs name'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

command failed; 1

dlgoodchild 于 2015-12-09

这也定期发生在我身上。码头工人 v1.9.1

spieden 于 2015-12-30

azure 驱动程序也有同样的问题。每次我们创建一个新的 azure 机器时，它都会失败并显示错误：

Error creating machine: Error checking the host: Error checking and/or regenerating the certs: There was an error validating certificates for host "testcargo2-prefapp-in.cloudapp.net:2376": tls: DialWithDialer timed out
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'

运行docker-machine regenerate-certs ，证书验证工作正常。

在 docker-machine v0.5.5 中没有问题，并且创建一个 docker 主机工作正常：

Running pre-create checks...
Creating machine...
(testcargo3-prefapp-in) Creating Azure machine...
Waiting for machine to be running, this may take a few minutes...
Machine is running, waiting for SSH to be available...
Detecting operating system of created instance...
Detecting the provisioner...
Provisioning with ubuntu(upstart)...
Installing Docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect Docker to this machine, run: docker-machine env

alambike 于 2016-02-12

@alambike您在 0.6.0 中遇到了这个问题吗？

nathanleclaire 于 2016-02-13

是的，从 0.5.5 开始。我用 0.5.6 和 0.6.0 对此进行了测试。

alambike 于 2016-02-13

对我来说在 0.6.0 上与 mac 10.10.5 上的 aws 驱动程序（不断）相同。虚拟盒驱动程序不会发生。

helinwang 于 2016-02-14

使用 docker-machine 0.6.0 将--engine-opt="cluster-advertise=eth1:2376"更改--engine-opt="cluster-advertise=eth0:2376"修复（docker-machine 0.5.4 仍然失败）

helinwang 于 2016-02-14

我想我正在我的机器上解决同样的问题。我正在使用 ubuntu 14.04
docker-machine 版本 0.5.5，构建 02c4254
在 RHEL 7.1 上运行主机
服务器版本：1.10.2-cs1-rc3

在机器上尝试了所有建议的时间，这是我从 curl 得到的输出

curl -v --cacert ~/.docker/machine/certs/ca.pem --cert ~/.docker/machine/machines/$NODE_NAME/cert.pem --key ~/.docker/machine/machines/$NODE_NAME /key.pem https://$(docker-machine ip $NODE_NAME):2376/version

在 DNS 缓存中找不到主机名
正在尝试 16.85.3.140...
连接到 16.85.3.140 (16.85.3.140) 端口 2376 (#0)
成功设置证书验证位置：
CA文件：/home/eraigosa/.docker/machine/certs/ca.pem
CApath：/etc/ssl/certs
SSLv3、TLS 握手、客户端问候 (1)：
SSLv3、TLS 握手、服务器问候（2）：
SSLv3、TLS 握手、CERT (11)：
SSLv3、TLS 握手、服务器密钥交换 (12)：
SSLv3、TLS 握手、请求 CERT (13)：
SSLv3、TLS 握手、服务器完成（14）：
SSLv3、TLS 握手、CERT (11)：
SSLv3、TLS 握手、客户端密钥交换 (16)：
SSLv3、TLS 握手、CERT 验证 (15)：
SSLv3、TLS 更改密码、客户端问候 (1)：
SSLv3，TLS 握手，完成 (20)：
SSLv3、TLS 警报、服务器问候 (2)：
错误：14094412 ：SSL例程：SSL3_READ_BYTES ：sslv3 警告证书错误
关闭连接 0
curl: (35)错误:14094412 :SSL例程:SSL3_READ_BYTES :sslv3 警报错误证书

wenlock 于 2016-02-25

@nathanleclaire我找到了罪魁祸首！ boot2docker 中的 prltoolsd不断错误地设置我的日期/时区。

$ date
<the current local time with the timezone set to UTC>

$ date -s '<the correct time in UTC>'
<prints the correct time>

$ date
<the date/time is now broken again>

$ /usr/local/etc/init.d/prltoolsd stop

$ date -s '<the correct time in UTC>'
<prints the correct time>

$ date
<prints the correct time and stays put>

停止prltoolsd并重置日期后，我的所有 docker-machine 命令都按预期工作，并且我的证书不会重新生成。

我仍然不知道为什么在制造新机器后将时区设置为 UTC 而将时间设置为本地时间，所以这只是一种解决方法，而不是修复方法。

carolynvs 于 2016-03-11

❤1

不错@carolynvs ！我们将努力查看是否可以在 boot2docker 中修复此问题。

@tianon @legal90仅供参考 ^^

nathanleclaire 于 2016-03-11

@carolynvs哇：可怕：。它看起来真的很奇怪，因为prltoolsd进程不应该在除 Parallels Desktop 之外的任何其他虚拟化系统上启动。只有当/usr/bin/prlvmcheck返回 0 退出代码时，守护程序才会启动，这意味着我们在 Parallels VM 中。

您是否在 Virtualbox VM 上重现了此问题？您使用的是什么 Boot2Docker 版本？

Ps 另外，如果我们假设prltoolsd是唯一的原因，那么 Docker Machine 版本应该没有意义。但是，上面的其他评论（链接）表明该问题仅出现在 Machine 0.5.5+ 中

legal90 于 2016-03-12

@legal90这更有意义。我的环境有点不稳定，但过去确实可以正常工作：

我在运行 Parallels 的 Mac 上。
在 Parallels 中，我运行 Windows，然后是最新的 docker 工具箱安装。我这样做是因为我为 Docker 编写文档和教程，并且需要针对 Mac、Linux 和 Windows 用户。

这解释了为什么prltoolsd试图管理我的 docker 主机时钟。它必须在 Parallels 中嵌套。这是否也解释了为什么系统时钟设置为本地时间但认为它是 UTC？

这是导致我打开此错误的根本问题。我在 CST (-6) 上午 10 点创建了一台新的 docker 机器。新机器上的系统时钟 ( date ) 认为现在是 UTC 上午 10 点，因此证书上的时间戳是“未来”。 hwclock报告正确的时间。

查看 boot2docker Dockerfile，我注意到它正在将/etc/timezone为 UTC，并且_should_ 也将/etc/localtime为 UTC。

见https://github.com/boot2docker/boot2docker/blob/master/Dockerfile#L311

RUN echo 'UTC' > $ROOTFS/etc/timezone \
    && cp -L /usr/share/zoneinfo/UTC $ROOTFS/etc/localtime

但是在我的 docker 机器主机上，没有安装 tzdata 包，所以/usr/share/zoneinfo不存在， /etc/localtime也不存在。我已经从最新的 Dockerfile 构建了我自己的 boot2docker，只是为了验证我没有使用旧的 iso。我想知道缺少/etc/localtime文件是否会导致不正确的时间问题？

carolynvs 于 2016-03-14

@carolynvs啊，现在我明白了。

这解释了为什么 prltoolsd 试图管理我的 docker 主机时钟。它必须在 Parallels 中嵌套。

是的，这就是问题的根源。 prltoolsd在嵌套在 Parallels VM 中的 Virtualbox VM 中运行。我已复制此内容并向 Parallels 的负责人报告。一修好我会第一时间通知你。

这是否也解释了为什么系统时钟设置为本地时间但认为它是 UTC？

嗯，很难提交，但这是 Parallels Desktop（及其访客工具）的一个已知问题。它最初在这里报告： https :
它在 PD 11 中通过prlctl实用程序的附加选项解决

很抱歉，但目前我可以建议您的唯一解决方案是防止prltoolsd在启动时在您的 VM 中运行。如果您使用自定义 Boot2Docker ISO 构建，您可以从 Dockerfile 中删除与并行相关的行并重建 ISO。或者注释掉这一行： https :

legal90 于 2016-03-14

感谢您提供有关 prltoolsd 如何工作的额外信息！我会按照你的建议去做，并为我的设置制作一个自定义的iso。：啤酒：

我会关闭这个问题，因为这解决了我的问题，但我会把它留给你，因为其他人似乎正在击中它（尽管可能出于不同的原因！）。

carolynvs 于 2016-03-14

我认为我们可以将其视为有效解决；如果发现任何新问题，我们可以重新开放。

感谢大家为报告和分类这个极其漫长的问题所做的贡献！

nathanleclaire 于 2016-03-14

我在 Windows 上使用 DockerToolbox 1.10.3。在我重新启动之前它工作正常，我现在遇到了同样的问题。我对 Docker 也不太熟悉，所以有人可以告诉我修复是什么吗？

mtrtm 于 2016-03-22

@mtrtm docker-machine regenerate-certs -f不起作用吗？

nathanleclaire 于 2016-03-22

是的， docker-machine regenerate-certs -f 可以。每次启动 Docker Quickstart Terminal 时似乎也这样做

mtrtm 于 2016-03-25

+1
我主要在 Redhat 服务器上使用 docker，一切正常。我不是专家，但我知道我在做什么。但是，在带有 virtualbox 的 Windows 上，每次 docker VM 重新启动时，我都需要重新生成证书。我在工具箱 1.11.1

virtualmackem 于 2016-05-10

👍1

+1

2009 年末的 Macbook
2,26 GHz 英特尔酷睿 2 双核
Mac OS Sierra 10.12
Docker 收费箱 1.2.1
虚拟盒 5.0.26

$ docker-machine ls
名称活动驱动程序状态 URL SWARM Docker 错误
vbox-test - virtualbox Running tcp://192.168.99.100 :2376 Unknown 无法查询 docker 版本：获取https://192.168.99.100 :2376/v1.15/version: x509: 证书已过期或尚未有效

$ docker-machine env vbox-test
检查 TLS 连接时出错：检查和/或重新生成证书时出错：验证主机“192.168.99.100:2376”的证书时出错：x509：证书已过期或尚未有效
您可以尝试使用“docker-machine regenerate-certs [name]”来重新生成它们。
请注意，这将触发 Docker 守护进程重启，这将停止运行容器。

$ docker-machine regenerate-certs vbox-test
重新生成 TLS 机器证书？警告：这是不可逆的。（是/否）：是
重新生成 TLS 证书
正在等待 SSH 可用...
正在检测供应商...
正在将证书复制到本地机器目录...
正在将证书复制到远程机器...
在远程守护进程上设置 Docker 配置...

$ docker-machine env vbox-test
检查 TLS 连接时出错：检查和/或重新生成证书时出错：验证主机“192.168.99.100:2376”的证书时出错：x509：证书已过期或尚未有效
您可以尝试使用“docker-machine regenerate-certs [name]”来重新生成它们。
请注意，这将触发 Docker 守护进程重启，这将停止运行容器。

leandropincini 于 2016-09-29

我在 2016 年 10 月 30 日下载的 Docker 工具包（安装在 Windows 10 Home 上）的默认安装中安装了这个。运行后错误消失：

docker-machine regenerate-certs

hholst80 于 2016-10-30

在 macOS 上遇到此问题。 docker-machine env抱怨：

$ docker-machine env docker1
Error checking TLS connection: Error checking and/or regenerating the certs: There was an error validating certificates for host "192.168.99.100:2376": x509: certificate has expired or is not yet valid
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which might stop running containers.

重新生成证书（即使使用-f ）也无济于事。 docker-machine ssh docker1 date显示正确的日期和时间。

有任何想法吗？

paddor 于 2018-03-04

@paddor重新生成证书，包括。客户端证书（ docker-machine regenerate-certs -f --client-certs ）为我修复了它。

wkruse 于 2018-08-18

👍2

Machine: 证书安装不正确，总是重新生成

最有用的评论

所有115条评论

相关问题