Machine: 証明書が正しくインストールされず、常に再生成されます

詳細な要約をありがとう。 私も以前にこのような問題を見たことがあり、それを調べます。

最新のVirutalBoxを使用していますか？ すなわち5.0.6？

最新バージョンのDockerToolbox（1.8.2c）に同梱されている5.0.4を使用していました。 そのバージョンを削除し、5.0.6をインストールしたところ、同じ動作が発生しています。

OKありがとう。

@carolynvsお持ちのホストのみのネットワークを削除して（VirtualBox GUIでこれを実行できます）、再試行すると、機能しますか？

マシンを削除し、アダプターを削除して、同じ結果で再試行しました。

OKありがとう。 非常に独特な行動。 証明書に関する詳細情報をダンプするテストビルドを作成し、同意できる場合はそれを試すことをお勧めします。

もちろん！ できる限りお手伝いさせていただきます。

ブランチを作成してそれを指定したい場合は、自分でビルドできます（：heart：コンテナ化されたビルド！）。 そうすれば、これが複数回の試行を必要とする場合に、壁を越えて複数のビルドを投げる必要はありません。

これを修正する際に考慮すべきもう1つのことは、私のような一部の人々は、実際に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ダウングレードしてから発生していません。

私は今日、リリース候補でまったく同じ振る舞いを経験しました。

こんにちは@ carolynvs @ blaggacao 、フィードバックをありがとう

このバグを再現/修正しようとしています。 バグの調査に役立てるために作成したこのPR（https://github.com/docker/machine/pull/2006）を試していただけませんか

私もこれを見ているようです。 私はdigitaloceanドライバーを使用してOS Xで最新のmasterビルドを使用しているので、これは間違いなく環境とは関係ありません。 area/windows area/driver-virtualboxタグと

こんにちは@ hairyhenderson 、PR＃2006をビルドして、 docker-machine -D env default出力を教えていただけますか？

@ dgageot-機会があればやってくれます。

また、これについてもう少し考えて、_local_ビルド（つまり、コンテナーを使用せずにOS Xでmake buildを実行していることに気付きました。 go buildが過去に異なった振る舞いをした領域の1つは、証明書（特にルートCA証明書）の周りであるため、これはそれに関連している可能性があります...わかりません。

しかし、私は＃2006で再構築し、それを試してみます。 ありがとう！

@hairyhendersonそれは良い点です。 クロスコンパイルされたdocker-machineを使用してテストを実行します

@dgageotこれは、新しいマシンのdocker-machine -D env defaultからの失敗した出力https://gist.github.com/carolynvs/e2473d21c3376f1ebec2です。

＃2006をビルドし、docker-machine.exeとdocker-machine-driver-virtualbox.exeをDockerToolboxのインストールディレクトリにコピーしました。 Windows10でDockerToolbox1.8.2cを使用しています。

私は作り方を知るのに十分な能力がありません、多分私がそれを理解することができれば、私は夕方にそれを見るでしょう。

@carolynvsどうもありがとう。 私はまだ何が起こっているのか理解していませんが、あなたのログは私を助けてくれます。

@carolynvs次の出力を提供できますか：

VBoxManage list hostonlyifs
VBoxManage list dhcpservers

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を実行しても、証明書はまだ再生成されています。

これは、2回目の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今のところ
私はPRにさらにいくつかのコミットをプッシュして、より多くの情報を印刷し、試してみました。
取得した出力を更新する時間があれば、それは素晴らしいことです。

ping @nathanleclaire @ dmp42何かアイデアはありますか？

新しい出力は次のとおりです： https ：

接続の問題をデバッグする別の方法があるかどうか教えてください。 証明書を再生成する原因となっているdocker-machineが何を検出しているかはよくわかりませんが、ホストの/ var / lib / boot2dockerを調べたり、Windowsとホストの間で証明書を比較したりできます。探す。

@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.

証明書がVMに正しくコピーされていません。
または、ポート192.168.99.100:2376 VMに到達できません（ホストネットワーク構成？ファイアウォール、vpn？vmネットワーク構成？）
または、チェック方法に問題があります。

docker-machine env指定された環境変数をエクスポートしてエラーを無視すると、dockerデーモンに接続できますか？

Dockerホストにpingを実行し、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

：+1：ありがとう！ 近づいている気がします：smile：

IIRC、 /var/lib/boot2docker/tlsの証明書は、boot2docker OSの起動スクリプトによってサーバー側で生成され、現在のマシンモデルでは何にも使用されません（boot2docker-cliがこれまで証明書の設定をどのように期待していたかを示す遺物です）アップ）。

@ carolynvs @ nathanleclaireその時は

@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ああ、はい、これは私のマシンでは問題のようです（Git

$ 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

これが問題のように思われるので、私は証明書をいじくり回し続けます。 たぶん、別のマシンで試してみて、それがWindows10のものかどうかを確認してください。

@carolynvsお疲れ様でした！ 明日の朝（パリ時間）に確認します

こんにちは@carolynvs 、 ca.pemでもこのコマンドを試しましたか？

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

-----BEGIN CERTIFICATE-----で始まり、 -----END CERTIFICATE-----終わることを正しく確認できますか。 前後はありません。

@carolynvs何が起こっているのかわからないことを認めなければなりません。 漠然と関係しているように見えるこのPRを試しましたか。

この中間の要約を確認してもかまわない場合は、黙ってこれに頭を悩ませることができます。

• 証明書はコピーされますが、読み取ることができませんか？

確かに、あなたはすでにチェックしました： http ：
他の人の参考のために置いておきます。

生成されたpfxファイルの代わりに--certと--keyを使用して別の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 / machine / 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"}

だから私は2つの疑わしいものを見ます：

1. DOCKER_CERT_PATHは、.docker / machine / machine /の代わりに.docker / machine / certsを使用しています
2. Validateは、cert.pemとkey.pemの代わりにserver.pemとserver-key.pemを使用しています。 各証明書の目的はわかりませんが、正しくないようです。

本当に役立つはずの@carolynvsに感謝します。 報告されたすべてを要約する前に、 https：//github.com/docker/machine/pull/2006の最新バージョンを試してみて

これが使用している証明書です

ホストURL = 192.168.99.102：2376
CA CERT PATH = C：\ Users \ caro8994.docker \ machine \ certsca.pem
SERVER CERT PATH = C：\ Users \ caro8994.docker \ machine \ machines \ bugtest \ server.pem
サーバーキーパス= C：\ Users \ caro8994.docker \ machine \ machines \ bugtest \ server-key.pem

これは私自身のデバッグ情報によるものであり、すべてのプラグインをビルドしているため、ビルドに長い時間がかかるPRではありません。 ：スマイル：

OK、今は混乱しているので、要約してみます。

あなたはそれを確認できますか：

• ~/.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は、 DOCKER_CERT_PATH="~/.docker/machine/certs"ではなくDOCKER_CERT_PATH="~/.docker/machine"をエクスポートします。

よろしくお願いします！

@carolynvs FTR、

ブレインダンプでごめんなさい！

• 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デーモンに接続しようとしています。 これはとても怪しいようです。

OK。 @nathanleclaireと@ehazlettに電話して救助しましょう。 あなたはそれを釘付けにしたと思いますが、今、私はプロジェクトに慣れていないので、なぜこれほど多くの重複した証明書があり、なぜ正しい証明書を使用しないのか理解できません。

ビルドのヒントをありがとう！

以下は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

閉じた/再び開いたノイズでごめんなさい。 私は手探りしました

Oivey。 @carolynvs @dgageot皆さんは、これを追いかけ続けるためのチャンピオンです。 キャロリンの疑惑は正しいと思います。 DOCKER_CERT_PATHが正しく設定されていないと、デーモンとの通信が正しく機能しません。 libmachine変更で誤って導入したパスの問題のようです。 私はこれを調査し、これまでのところあなたの発見をいじくり回し続けます。

では、犯人への玄関口はこの線でしょうか？
https://github.com/docker/machine/blob/8aa1572e0dcd75762a7627e1056ef104317f44b9/libmachine/persist/filestore.go#L155

@blaggacao可能性の領域では間違いなく強く、そのコードは少しもろくなりがちで、過去に問題がありました。

@carolynvsが確認したように、これがWindowsと
私にとって、それは明らかに.docker\machine\certsパスを構築します。

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明らかに、Macの@carolynvsと同じ動作はありません。 だから、何か怪しいものがあります。

ええ、証明書はプロビジョニングビットの間にそのマシンのディレクトリにコピーされます。

@dgageot混乱をお詫びします。 私のMacはdocker-machine0.4.1を実行しています。 マスターにマージされる修正をテストしているので、WindowsマシンでのみPRビルドを実行しています。

今すぐMacでビルドして再実行できます。

再開します：

• 差分は/machine/certsと/machine/machines/certs違いを示していません
• 問題を解決するためのcarlynvsの回避策を再現できません。

Windowsで（bashで）DOCKER_CERT_PATHを手動で設定する場合は、UNIXスタイルのパスを使用する必要があります。 たとえば、 export DOCKER_CERT_PATH="~./docker/machine/machines/oca"です。

私の（不安定な）マシンでは、証明書が/ machine / certsと/ machine / machine / certsの間で一致することを確認できます。

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

2番目と3番目のものは/machines/ocaとoca:~/.docker間で異なります

証明書@blaggacaoにVM

私はちょうど気づきました、それは間違ったものでした...

~/.dockerに対してチェックしました/var/lib/boot2dockerに対してもう一度チェックします

私はdefinitleyがそれを確認することができます

• /machines/ocaとoca:/var/lib/boot2docker/の証明書は同じです
  （3つのフィールドすべてでdos2unixを実行しますca.pem 、 server.pem 、 sever-key.pemでoca ）

さらに、このタイムアウトエラーが発生します： https ：
--native-sshフラグを付けて実行するかどうかにかかわらず、 envを実行するたびに

ええ、 @ blaggacaoは、VMに割り当てられたホストのみのIPがコンピューターから到達できないようにも見えます。 ping $(docker-machine ip vmname)できますか？

いいえ、どちらも機能しません...「リクエストがタイムアウトしました」

docker-machine ssh vmname機能します

ええ、 sshはlocalhost通過します。 しかし、割り当てられたホストにVM IPのみを接続することはできないようです。そのため、 envが正しく機能するとは思われません。 VPNまたはプロキシを使用していますか？

私が知っていることではありませんが、タスクマネージャを再確認しただけです... UPDATEが1つを検出し、終了しました

閉じても何も変わりませんが、これは別の問題だと思います...

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

これは、両方の問題の間の関係のようなにおいがします。 私の考えを解釈できますか？

リモート掘削： https ：

私はもう自分の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コマンドが機能しなかったのに、数時間後には機能した理由を説明します。

こっちも一緒：

$ 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です

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

更新：修正

ここに記載されているように： https ：

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

別のエラーが発生しました（一度に1ステップ:)

私はこれがそれだと思います、残りは私のvirtualboxです。

夕食を食べて、証明書が有効ですべてがうまくいくと思うとき、5時間後にもう一度確認します。 ：スマイル：

悪いニュースですが、VMを再起動するたびにこれを行う必要があります。

：smile：あなたは根本的な原因にぶつかったと思います！ ありがとう！

：拍手：：拍手：：拍手：：拍手：：拍手：：拍手：：拍手：

@carolynvs私が投稿した修正はあなたのために機能しましたか？

証明書が有効になるまで5時間待った後、docker-machineenvが機能することを確認したかっただけです。 将来の日付の証明書を取得する理由はわかりませんが、問題を更新して、現在わかっている本当の根本原因を反映する必要があるかもしれません。

私の場合、証明書は問題ではありませんでしたが、boot2dockerの時間設定... githubプロファイルでわかるように、あなたはシカゴ出身です。これはボゴタと同様のタイムゾーンです。おそらく、boot2dockerがタイムゾーンで正しく設定されていません。 ..。。

回避策を使用して時刻を同期した後でも、これらの証明書を使用して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のいずれかに、変更をすぐに元に戻す何かがあります。

これは、回避策を適用した後の昨日の動作状態です。

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で表された私の現地時間に対応します

私のsymtopmsのいくつかのヒント： https ：//forums.virtualbox.org/viewtopic.php？f = 3＆t = 60558＃p281836

timeは、10分後に凍結されます： docker<strong i="18">@oca</strong>:~$ time BusyBox v1.23.1 (2015-02-22 15:53:49 UTC) multi-call binary.

私の場合、 dateが正しい日付を示しているので、私の場合は回避策の固定日であると想定しているため、問題が発生します。

上記のREでのcc @ tianon @SvenDowideit PTAL：boot2dockerの時刻/日付の問題^^

私が見つけたいくつかのコードは、タイムスタンプの問題に寄与している可能性があります。

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

しかし、以前は常に正常に機能していました。

@carolynvs @blaggacaoまだこれらの問題に

私にとっては、参照されている回避策の後で機能しています。 これは、次に、一部のboot2docker時間パラメーターが正しく設定されていないことを示しています。 通常は、マシンの作成直後の限られた時間枠でのみ発生します。 （おそらく一部のタイムゾーンでのみ）。

これもまた、証明書のタイムスタンプが正しいことを意味します。

rcでPCを再起動した直後に、これに再び遭遇しましたが、5.0に更新した後はすべてが機能しているようです。 おそらく今のところこれを閉じることができます。 とにかく、奇妙な振る舞いに気づいたらすぐに再開します。

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

私もこの問題を抱えています。 閉じないでください。

@damonticこれは、ここで説明している問題とは異なる問題のように見えます。

DigitalOceanで群れを設定しようとしていますが、同じエラーが発生します。

KVストア、スウォームマスター、およびノー​​ドを作成するinit-do.shファイル：

 # 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.

これを実行する前に、マシン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プロビジョニングが失敗した場合、作成されたインスタンスは「無効」になります。 それらを削除して、最初からやり直してみてください。

@nathanleclaireマシンを削除し（「docker-machine rm consul demo0 demo1」で十分ですか、それとも手動で他のものを削除する必要がありますか？）、セットアップファイルで再実行すると、同じ証明書の問題が発生します（DigitalOceanで作成する場合）。 奇妙なことに、「領事」マシンには問題はありませんが、群れのマシン（demo0、demo1）にのみ問題があります。

ただし、VirtualBox（5.0.10）でスウォームを作成すると、正常に機能します。

AWSドライバーを使用しているときにこれが表示されます

私はいくつかのテストを（実際にはたくさん）行いましたが、VMを削除して（群れを使って）再作成した後も、同じ問題が発生します。

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

これは私にも定期的に起こっています。 Docker v1.9.1

ここでも紺碧のドライバーで同じ問題が発生します。 新しい紺碧のマシンを作成するたびに、次のエラーで失敗します。

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 0.6.0でこの問題が発生していますか？

はい、0.5.5以降です。 私はこれを0.5.6と0.6.0でテストしました。

マック10.10.5のawsドライバー（常に）を使用した0.6.0の私も同じです。 仮想ボックスドライバでは発生しません。

docker-machine 0.6.0を使用して--engine-opt="cluster-advertise=eth1:2376"を--engine-opt="cluster-advertise=eth0:2376"に変更した後、修正されました（docker-machine 0.5.4は引き続き失敗します）

私のマシンで同じ問題と戦っていると思います。 私はubuntu14.04を使用しています
docker-machineバージョン0.5.5、ビルド02c4254
RHEL7.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）に接続
• 証明書の検証場所を正常に設定しました。
• CAfile：/home/eraigosa/.docker/machine/certs/ca.pem
  CApath：/ etc / ssl / certs
• SSLv3、TLSハンドシェイク、クライアントhello（1）：
• SSLv3、TLSハンドシェイク、サーバーhello（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変更暗号、クライアントhello（1）：
• SSLv3、TLSハンドシェイク、終了（20）：
• SSLv3、TLSアラート、サーバーhello（2）：
• エラー：14094412 ：SSLルーチン：SSL3_READ_BYTES ：sslv3アラートの不正な証明書
• 接続を閉じる0
  curl：（35）エラー：14094412 ：SSLルーチン：SSL3_READ_BYTES ：sslv3アラートの不正な証明書

@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 ！ boot2dockerでこれを修正できるかどうかを確認する作業を行います。

@tianon @ legal90 FYI ^^

@carolynvsうわー：恐ろしい：。 prltoolsdプロセスは、Parallels Desktop以外の他の仮想化システムでは開始されないため、非常に奇妙に見えます。 デーモンは、 /usr/bin/prlvmcheckが0の終了コードを返した場合にのみ起動します。これは、ParallelsVMにいることを意味します。

この問題をVirtualboxVMで再現しましたか？ 使用しているBoot2Dockerのバージョンは何ですか？

PSまた、 prltoolsdが唯一の理由であると仮定した場合、DockerMachineのバージョンは意味をなさないはずです。 ただし、上記の他のコメント（リンク）は、問題がマシン0.5.5以降でのみ発生することを示しています

@ legal90それはもっと理にかなっています。 私の環境は少し不安定ですが、以前は問題なく機能していました。

1. Parallelsを実行しているMacを使用しています。
2. Parallels内で、Windowsを実行してから、最新のDockerツールボックスをインストールします。 これを行うのは、Dockerのドキュメントとチュートリアルを作成し、Mac、Linux、およびWindowsユーザーをターゲットにする必要があるためです。

これは、 prltoolsdがDockerホストクロックを管理しようとしている理由を説明しています。 Parallels内にネストされていることを認識している必要があります。 これは、システムクロックが現地時間に設定されているのに、UTCであると考えている理由も説明していますか？

それが私がこのバグを開く原因となった根本的な問題です。 中部標準時午前10時（-6）に新しいDockerマシンを作成します。 新しいマシンのシステムクロック（ date ）は、UTCが午前10時であると見なしているため、証明書のタイムスタンプは「将来」です。 hwclockは正しい時刻を報告します。

boot2docker Dockerfileを見ると、 /etc/timezoneがUTCに設定されており、 /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も存在しません。 古いISOを使用していないことを確認するために、最新のDockerfileから独自のboot2dockerを作成しました。 /etc/localtimeファイルが欠落していることが、誤った時間の問題の原因になっているのではないかと思いますか？

@carolynvsああ、今私はそれを手に入れました。

これは、prltoolsdがDockerホストクロックを管理しようとしている理由を説明しています。 Parallels内にネストされていることを認識している必要があります。

ええ、それが問題の根源です。 prltoolsdは、ParallelsVMにネストされたVirtualboxVMで実行されます。 私はこれを再現し、Parallelsの責任者に報告しました。 修正され次第お知らせします。

これは、システムクロックが現地時間に設定されているのに、UTCであると考えている理由も説明していますか？

コミットするのは難しいですが、Parallels Desktop（およびそのゲストツール）の既知の問題です。 当初はここで報告されました： https ：
PD 11では、 prlctlユーティリティの追加オプションによって回避されましたが、実際にはWindowsでVirtualbox VMを実行しているため、まれなケースでは役に立ちません。

申し訳ありませんが、現時点で提案できる唯一の解決策は、起動時にVMでprltoolsdが実行されないようにすることです。 カスタムBoot2DockerISOビルドを使用する場合は、パラレル関連の行をDockerfileから削除します： //github.com/boot2docker/boot2docker/blob/master/rootfs/rootfs/bootscript.sh#L101

prltoolsdがどのように機能するかについての追加情報をありがとう！ 私はあなたが提案するように行い、私のセットアップ用のカスタムISOを作成します。 ：ビール：

これで問題が解決するので、この問題を閉じますが、他の人が問題にぶつかっているように見えるので、それはあなたに任せます（おそらく別の理由で！）。

私たちはそれを効果的に解決されたものとして扱うことができると思います。 新しい問題が発見された場合は、再開できます。

この非常に長い問題の報告とトリアージに貢献してくれた皆さんに感謝します！

WindowsでDockerToolbox1.10.3を使用しています。 再起動するまでは正常に機能していましたが、現在も同じ問題が発生しています。 私もDockerにあまり詳しくないので、誰かが修正方法を教えてもらえますか？

@mtrtm docker-machine regenerate-certs -fは機能しませんか？

はい、docker-machine regenerate-certs-fはそうします。 また、Dockerクイックスタートターミナルを起動するたびにそれを行うようです

+1
私は主にRedhatサーバーでdockerを使用していますが、すべて正常に動作します。 私は専門家ではありませんが、自分が何をしているのかは知っています。 ただし、virtualboxを備えたWindowsでは、DockerVMが再起動するたびに証明書を再生成する必要があります。 私はツールボックス1.11.1を使用しています

+1

Macbook2009年後半
2,26 GHz Intel Core 2 Duo
Mac OS Sierra 10.12
Dockerトールボックス1.2.1
VirtualBox 5.0.26

$ docker-machine ls
名前アクティブなドライバーの状態URLスウォームドッカーエラー
vbox-test-virtualbox実行中tcp：//192.168.99.100 ：2376不明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マシン証明書を再生成しますか？ 警告：これは元に戻せません。 （y / n）：y
TLS証明書の再生成
SSHが利用可能になるのを待っています...
プロビジョナーの検出...
証明書をローカルマシンディレクトリにコピーしています...
証明書をリモートマシンにコピーしています...
リモートデーモンでDocker構成を設定しています...

$ docker-machine env vbox-test
TLS接続のチェックエラー：証明書のチェックおよび/または再生成エラー：ホスト "192.168.99.100:2376"の証明書の検証中にエラーが発生しました：x509：証明書の有効期限が切れているか、まだ有効ではありません
'docker-machine regenerate-certs [name]'を使用してそれらの再生成を試みることができます。
これにより、Dockerデーモンが再起動し、コンテナーの実行が停止することに注意してください。

これは、2016-10-30にダウンロードされたDocker Tookit（Windows 10 Homeにインストールされている）のデフォルトインストールで発生しました。 実行後にエラーは消えました：

docker-machine regenerate-certs

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証明書の再生成（含む） クライアント証明書（ docker-machine regenerate-certs -f --client-certs ）で修正されました。