docker-composeリリース候補を使おうとしても同じことが起こっていると思います...

$ docker-compose ps
SSL error: hostname '192.168.59.103' doesn't match 'boot2docker'

しかし、 figは正常に機能します...

$ fig -f docker-compose.yml ps
Name   Command   State   Ports
------------------------------

私はOSXを使用しており、Goクライアントのバージョンがgo1.3.3であることを除いて、 @ gkostyanikovと同じバージョンをすべて実行しています。私のpython / opensslもHomebrew経由でインストールされます。それと関係があるのでしょうか？

編集：実際には、Homebrewはopensslをリンクしていないように見えるので、デフォルトのOSXバージョンであるOpenSSL 0.9.8za 5 Jun 2014を使用しています。

adambiggs 2015年01月27日

問題はHomebrewpythonでした。

docker-composeは、homebrew python / opensslをアンインストールし、 easy_install docker-composerを使用してpipをインストールし、システムpythonを使用してdocker-composerを再インストールした後に機能するようになりました。

adambiggs 2015年01月28日

@adambiggsあなたのソリューションは機能します！ありがとう！

gkostyanikov 2015年01月28日

これは私にとってもうまくいきました。私は真新しいMacを使用していて、自作のpythonでセットアップしています。 figがdockerと通信するときにこのエラーが発生しました。 @adambiggsのアドバイスに従い、私のブロッカーを

keekdageek 2015年01月28日

これは私にも起こっています。そして、私はシステムのpythonを使いたくないのですが、誰か別の回避策がありますか？

zkanda 2015年01月30日

バイナリを使ってみましたか？同じ問題が発生しますか？

aanand 2015年01月30日

いいえ、バイナリは試していません。
システムのPythonにインストールしたくない場合、別の回避策はvirtualenv（wrapper）を使用することです。

mkvirtualenv --python=/usr/bin/python docker-compose
pip install docker-compose==1.1.0-rc2

zkanda 2015年01月30日

pyenvを使用してPython 2.7.8にロールバックするより良い解決策を見つけました：

http://stackoverflow.com/a/28216459/1166293
https://github.com/yyuu/pyenv

編集：気にしないでください、 pyenvはそれ自身の問題の束を導入しました...

adambiggs 2015年02月03日

私にとってこのエラーの原因は、自作のopensslが/ usr / local / bin / opensslにリンクされていなかったことです。

openssl version

OpenSSL1.0.1jではなく2014年10月15日

ランニング

brew link --force openssl

figを再インストールすると問題が解決しました。

ocasta 2015年02月04日

興味深いですが、私のOpenSSLバージョンはOpenSSL 1.0.1j 2014年10月15日です。

zkanda 2015年02月04日

@aanand私の場合、バイナリにはこの問題はありません。

andizzle 2015年02月05日

自作ではなくpipを介してfigをインストールしたときに、このエラーが発生しました。 sudo pip uninstall figとbrew install fig修正してくれました。

NotBobTheBuilder 2015年02月06日

@NotBobTheBuilderソリューションの+1、これも私のために働いた

szeryf 2015年02月09日

：+1： @NotBobTheBuilderの場合

octplane 2015年02月10日

@NotBobTheBuilderはイチジクのための素晴らしいソリューションですが、

adambiggs 2015年02月10日

@ocasta OpenSSLのリンクに関する自作からのこの恐ろしい警告はどうですか？

この式は樽のみです。
Mac OS Xはすでにこのソフトウェアを提供しており、
並列はあらゆる種類の問題を引き起こす可能性があります。
Appleは、独自のTLSおよび暗号ライブラリを優先してOpenSSLの使用を非推奨にしました

adambiggs 2015年02月10日

@NotBobTheBuilderを高く評価します-それで私も修正されました。

mewm 2015年02月16日

誰かがこの問題の原因を知っていますか？それはイチジクで私に起こっています。私は今のようにpip install figに固執することを好みます。数週間前はすべて正常に機能していましたが、システムで何が変更されたのかわかりません

anentropic 2015年02月18日

私のシステムOpenSSLはOpenSSL 0.9.8zc 15 Oct 2014で、自作のopensslは新しいですが、リンクされていません。

... Python 2.7.9にアップグレードしたときに壊れたと思いますが、SSL関連のバグがいくつかあるようです...次のようになります。
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196431
http://bugs.python.org/issue23052

anentropic 2015年02月18日

brew link --force opensslを実行してfigを再インストールしても、何も起こりませんでした。

anentropic 2015年02月18日

Py 2.7.9でのSSLの変更を回避するには、figを更新する必要がありますか？
https://www.python.org/dev/peps/pep-0476/#opting -out

anentropic 2015年02月18日

私はboot2dockerを使用しています。 1.5.0にアップグレードしましたが、変更はありません。

In [1]: from fig.cli.docker_client import docker_client

In [2]: client = docker_client()

In [3]: client.version()

SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

In [4]: %debug
> /Users/anentropic/.virtualenvs/dpm/lib/python2.7/site-packages/requests/sessions.py(461)request()
    460         send_kwargs.update(settings)
--> 461         resp = self.send(prep, **send_kwargs)
    462

ipdb> p settings
{'verify': '/Users/anentropic/.boot2docker/certs/boot2docker-vm/ca.pem', 'cert': ('/Users/anentropic/.boot2docker/certs/boot2docker-vm/cert.pem', '/Users/anentropic/.boot2docker/certs/boot2docker-vm/key.pem'), 'proxies': {}, 'stream': False}

figコードは正しいように見えますが、boot2dockerによってインストールされた証明書を使用しようとしています...これらの証明書は常に機能していたので問題ないと思います。b2dをアップグレードしただけなので、期限切れになることはありません。

anentropic 2015年02月18日

うーん、私のPython（homebrew経由でインストール）はHomebrewバージョンのOpenSSLを使用しているようですが：

$ python -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.0.2 22 Jan 2015

$ brew info openssl
openssl: stable 1.0.2 (bottled)
==> Caveats
A CA file has been bootstrapped using certificates from the system
keychain. To add additional certificates, place .pem files in
  /usr/local/etc/openssl/certs

and run
  /usr/local/opt/openssl/bin/c_rehash

... /usr/local/opt/openssl/bin/c_rehashしても役に立ちませんでした:)

anentropic 2015年02月18日

以前にインストールしたバージョンのPython（2.7.8_2）を$ brew switch python 2.7.8_2経由で試しましたが、同じ問題が発生しました（エラーメッセージが少し異なっていても）。したがって、Python2.7.9バージョンは問題ではないようです。

次に、1.0.2から1.0.1j_1までの古いopensslバージョンに切り替えてみました。これは機能しているようです。

$ python -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.0.2 22 Jan 2015
$ docker-compose ps
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
$ brew switch openssl 1.0.1j_1
$ python -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.0.1j 15 Oct 2014
$ docker-compose ps
Name   Command   State   Ports 
------------------------------

kretz 2015年02月19日

私にとっては別のエラーが発生しますが、問題を絞り込むのに役立つ可能性があります。

$ brew switch openssl 1.0.1j_1
Error: openssl does not have a version "1.0.1j_1" in the Cellar.
Versions available: 1.0.1e, 1.0.1f, 1.0.1g, 1.0.2
$ brew switch openssl 1.0.1g
Opt link created for /usr/local/Cellar/openssl/1.0.1g
$ fig up
SSL error: hostname '192.168.59.103' doesn't match 'boot2docker'

OpenSSL 1.0.2に戻すと、以前のCERTIFICATE_VERIFY_FAILEDエラーが発生するため、バージョンを変更すると確実に何らかの影響があります

anentropic 2015年02月19日

回避策の1つは、コンテナーでdocker-composeを実行することです。

git clone [email protected]:docker/fig.git
cd fig
docker build --tag docker-compose .

alias docker-compose='docker run --rm -e "DOCKER_TLS_VERIFY=$DOCKER_TLS_VERIFY" -e DOCKER_HOST=tcp://172.17.42.1:2376 -e DOCKER_CERT_PATH=/usr/local/certs -v "$DOCKER_CERT_PATH:/usr/local/certs" -v "$PWD:/code" docker-compose --project-name "${PWD##*/}"'

これには、VirtualBoxのポート2376を公開する必要があります。

VBoxManage controlvm boot2docker-vm natpf1 "docker-s,tcp,127.0.0.1,2376,,2376"

cydparser 2015年02月23日

@kretzの答えは私のために働いた。

datariot 2015年02月27日

+1 @kretzbrewスイッチopenssl1.0.1j_1
トリックを作った

boostrack 2015年03月01日

brew switch openssl 1.0.1jは私のために働きます（_1の欠如に注意してください）

rseymour 2015年03月02日

私はそれが好きではありませんが、virtualenvからfigをアンインストールし、homebrew経由でインストールすると修正されました

anentropic 2015年03月07日

ありがとう@ kretz-あなたの答えは私のためにそれを解決しました！

matthewpbyrne 2015年03月11日

それは私にとってはうまくいきません：

$ brew switch openssl 1.0.1j_1
Error: openssl does not have a version "1.0.1j_1" in the Cellar.
Versions available: 1.0.2

cancan101 2015年03月11日

私の回避策は、brewから取得した2.7.9ではなく、python2.7.8でvirtualenvを作成することでした。

foundatron 2015年03月11日

さまざまな回避策...誰かが本当の問題についての洞察を持っていますか？

anentropic 2015年03月11日

App Engineは何かと何の関係がありますか？

18時09分に2015年3月11日、ライアン・小の[email protected]は書きました：

私はアプリエンジンのもののどれもPython2.7.9で動作しないと確信しています
—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/compose/issues/890#issuecomment-78329652 。

anentropic 2015年03月11日

@anentropic使用（切り替え）する前に、古いopensslバージョンをインストールする必要があります。

# Find available older versions to install
$ brew search openssl
openssl
homebrew/versions/openssl098  homebrew/versions/openssl101

# Install older 1.0.1 version
$ brew install homebrew/versions/openssl101

# See what versions are installed locally
$ brew info openssl
...
/usr/local/Cellar/openssl/1.0.1f (429 files,  15M)
  Built from source
/usr/local/Cellar/openssl/1.0.1i (430 files,  15M)
  Poured from bottle
/usr/local/Cellar/openssl/1.0.1j (431 files,  15M)
  Poured from bottle
/usr/local/Cellar/openssl/1.0.1j_1 (431 files,  15M)
  Poured from bottle
/usr/local/Cellar/openssl/1.0.2 (459 files,  18M)
  Poured from bottle
...

# Switch to one of the 1.0.1 you got installed
$ brew switch openssl 1.0.1j_1

kretz 2015年03月11日

brew install openssl101が、 1.0.1jに切り替える可能性がありません1.0.1lが表示され、システムが混乱するのではないかと心配していました。それらは別々の醸造パッケージであり、私はすでに1.0.2を並行して持っていました

役に立たなかったようですが、多分私はそれで十分に行きませんでした

anentropic 2015年03月11日

申し訳ありませんが、間違ったgithubの問題に返信しました（コメントをすばやく削除しました）
11:30 anentropicの水、2015年3月11日には[email protected]
書きました：

私はopenssl101をbrewinstallしましたが、それは私に可能性を与えませんでした
1.0.1jに切り替えます...それは私に1.0.1lを与えました、そして私はそれが行くのではないかと心配しました
それらは別々の醸造パッケージであり、私はすでに持っていたので、私のシステムを混乱させます
1.0.2並列
役に立たなかったようですが、多分私はそれで十分に行きませんでした
—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/compose/issues/890#issuecomment-78340580 。

foundatron 2015年03月12日

そのため、Mac OSXで実行している場合も、この問題が発生しているようです。 docker-composeを使用してこれが私の.ymlファイルです。

web:
    build: .
    links:
        - db
        - cache
        - worker
    ports:
        - "8080:8080"
db:
    image: mysql
cache:
    image: redis
worker:
    build: .
    command: celery -A application.extentions worker -l info

docker-compose pullを実行すると、次の出力が失敗しました。

$ docker-compose pull
Pulling db (mysql:latest)...
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

私がチェックしたいくつかのこと。
which openssl; openssl version

/usr/local/bin/openssl
OpenSSL 1.0.2 22 Jan 2015

psykzz 2015年03月16日

@psykzz brewでインストールすると、

brew install docker-compose

zkanda 2015年03月17日

@arvindtest何がこの問題に関連していると思いますか？

anentropic 2015年03月18日

参考までに、これに多くの苦労をした後、これはboot2dockerの問題のようです。
私のために働いたのはTLSを無効にすることでした。これを行うためのユーザーフレンドリーな方法はまだありませんが、手順の概要は次のとおりです。
https://github.com/deis/deis/issues/2230

基本的に、次のことを行う必要があります。

boot2docker ssh
sudo echo'DOCKER_TLS = no '> / var / lib / boot2docker / profile

次に、boot2dockerを再起動します。
boot2docker停止
boot2docker開始

〜/ .bashrcにこのようなものを追加します（IPが正しいことを確認してください）

export DOCKER_HOST = tcp：//192.168.59.103 ：2375
未設定のDOCKER_CERT_PATH
未設定のDOCKER_TLS_VERIFY

coderfi 2015年03月22日

あなたのbashrcで$（boot2docker shellinit）を持っていないのはなぜですか

すべてを正しく支援する必要がありますか？

つまり、まだTLSソリューションを実行する必要があります。
2015年3月21日23:05、「coderfi」 [email protected]は次のように書いています。

参考までに、これと多くの苦労をした後、これは
boot2dockerの問題。
私のために働いたのはTLSを無効にすることでした。まだユーザーフレンドリーな方法はありません
これを行うには、手順の概要は次のとおりです。
deis / deis＃2230 https://github.com/deis/deis/issues/2230
基本的に、次のことを行う必要があります。
boot2docker ssh
sudo echo'DOCKER_TLS = no '> / var / lib / boot2docker / profile
次に、boot2dockerを再起動します。
boot2docker停止
boot2docker開始
そしてあなたの〜/ .bashrcにこのようなもの
IPが正しいことを確認してください
export DOCKER_HOST = tcp：//192.168.59.103 ：2375
未設定のDOCKER_CERT_PATH
未設定のDOCKER_TLS_VERIFY
—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/compose/issues/890#issuecomment-84468058 。

psykzz 2015年03月22日

@kretzそれは動作します！ありがとう。

TOMOAKI12345 2015年03月26日

@psykzz $(boot2docker shellinit)ですか？

anentropic 2015年03月26日

はい、コメントを更新しました。 derp。

psykzz 2015年03月26日

TLSを無効にする@coderfiのソリューションが機能することを確認できます！

anentropic 2015年03月26日

それがあなたのために働くことをうれしく思います。 :)

@Mattはい、シェルのinitシェル拡張のヒントについては正しいです。
ただし、boot2dockerがまだ起動していない場合は機能しない可能性があるため、
例を明示的にしました。

Fi
2015年3月26日午前10時18分、「anentropic」 [email protected]は次のように書いています。

@coderfihttps ：//github.com/coderfiのソリューションを確認でき
TLSを無効にすることは私のために働きます！
—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/compose/issues/890#issuecomment-86630313 。

coderfi 2015年03月26日

これは明らかかもしれませんが、TLSを無効にしたり、これを機能させるためだけにOpenSSLをダウングレードしたりする場合は、実行内容に応じて慎重に検討する必要があります。

これはすべてに関係するわけではありませんが、 gliderlabs/alpine:3.1からプルするDockerfileを使用したpipインストール中に、同様のエラーがポップアップしました。これは、progriumとcrewの最小限のLinuxコンテナーです。問題は、システム証明書パッケージをインストールしていなかったことでした。この問題は、 pipをインストールする前にパッケージをインストールし、要件ファイルを実行することで解決されました。

RUN apk-install -X ca-certificates

djm 2015年03月29日

👍3

提案された解決策は私にとって実際にはうまくいきませんでした。 1.0.1OpenSSLバージョンのいずれにも切り替えることができませんでした。結局、pipでインストールされたすべてのdocker-composeバージョンをアンインストールし、 brew install docker-compose実行するだけでうまくいくことがわかりました。

metakermit 2015年03月30日

上記の解決策は機能しましたが、私には面倒でした。簡単なboot2docker upgradeで、私の側のすべてが修正されました。

chafreaky 2015年03月31日

私はすでに最新のboot2dockerバージョンを持っていますが、上記の修正がないと機能しません

anentropic 2015年03月31日

自作の開発者は、docker-pyとdocker-composeをrequests 2.6.0の使用にアップグレードする必要があることを示唆しています

https://github.com/Homebrew/homebrew/issues/38226#issuecomment -88083428

anentropic 2015年03月31日

👍1

うまくいけば、これは誰かを助けるでしょう...解決策はわかりませんが、Mac OSXプロキシとしてCharlesを使用している場合はこのメッセージが表示されます。

neilsarkar 2015年04月06日

FWIW、pipを介してdocker-composeをインストールすると、docker-compose自体が機能するようになりました（OS X Mavericksにcurlを介してインストールすると、 illegal operationエラーが発生しました）。その後、SSLエラーも発生していました。 brew link --force openssl && brew switch openssl 1.0.1j実行すると、修正されたようです。

LoopLabsInc 2015年04月18日

@rseymourの答えは私のために働いた

ghost 2015年04月25日

brewでopenssl-1.0.1jが見つからない場合は、githubリポジトリから古いバージョンのopensslレシピを取得して利用できます。

» brew switch openssl 1.0.1j
Error: openssl does not have a version "1.0.1j" in the Cellar.
Versions available: 1.0.2a-1
» brew unlink openssl
Unlinking /usr/local/Cellar/openssl/1.0.2a-1... 1543 symlinks removed
» brew install https://raw.githubusercontent.com/Homebrew/homebrew/62fc2a1a65e83ba9dbb30b2e0a2b7355831c714b/Library/Formula/openssl.rb
...
🍺  /usr/local/Cellar/openssl/1.0.1j_1: 431 files, 14M, built in 4.2 minutes
» docker-compose up                                                                                                                   
Creating myservice...

lazyval 2015年04月30日

👍1

1.0.1mを試しましたが、うまくいきませんでした。
だから私は@lazyvalの方法を試し
これは私がやったことです。

brew install https://raw.githubusercontent.com/Homebrew/homebrew/62fc2a1a65e83ba9dbb30b2e0a2b7355831c714b/Library/Formula/openssl.rb
醸造スイッチopenssl1.0.1j_1
brew unlink openssl101 //この前に1.0.1mをリンクしたので
brew link openssl --force
docker-compose ps

ありがとうございました！！

ryutaaoki 2015年05月05日

👍1

Python 2.7.9以降でバイナリをビルドする必要があるため、現在これを調査しています。

aanand 2015年05月28日

_＃1427から移転_

サーバ：

CoreOS Stable
Docker 1.5.0

クライアント：

CentOS 6.6、64ビット
カーネル2.6.32-042stab105.14
Dockerクライアント1.5.0
docker-compose 1.2.0
~/.docker/{ca.pem,cert.pem,key.pem}配置されたSSL証明書
DOCKER_HOST=tcp://docker-builder:2376
DOCKER_TLS_VERIFY=1

次のMakefileを使用してSSL証明書を作成します。

#!/bin/bash

SERVER=docker-builder

clean:
    rm ca.* server.* client.* *.key

all: ca.crt server.crt client.crt

%.key:
    openssl genrsa -out $@ 4096

ca.crt: ca.key
    openssl req -new -x509 -days 365 -key ca.key -sha256 -out ca.crt \
        -subj "/C=US/ST=Texas/L=Austin/O=Abc123/OU=Operations/CN=${SERVER}/[email protected]"

server.csr: server.key
    openssl req -new -key server.key -out server.csr \
        -subj "/C=US/ST=Texas/L=Austin/O=Abc123/OU=Operations/CN=${SERVER}/[email protected]"

server.crt: ca.key ca.crt server.csr
    openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key \
        -CAcreateserial -out server.crt

client.csr: client.key
    openssl req -new -key client.key -out client.csr \
        -subj "/C=US/ST=Texas/L=Austin/O=Abc123/OU=Operations/CN=Docker Client/[email protected]"

client.ext.cnf:
    echo "extendedKeyUsage = clientAuth" > client.ext.cnf

client.crt: client.csr ca.crt ca.key client.ext.cnf
    openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key \
        -CAcreateserial -out client.crt -extfile client.ext.cnf

このマシンをプロビジョニングするための（明らかに理想的とは言えない）ユーザーデータスクリプトは次のとおりです。

#cloud-config

write_files:
    - path: /home/core/server.crt
      owner: core:core
      permissions: 0644
      content: |
        -----BEGIN CERTIFICATE-----
        <cert goes here>
        -----END CERTIFICATE-----


    - path: /home/core/server.key
      owner: core:core
      permissions: 0644
      content: |
        -----BEGIN RSA PRIVATE KEY-----
        <key goes here>
        -----END RSA PRIVATE KEY-----


    - path: /home/core/ca.crt
      owner: core:core
      permissions: 0644
      content: |
        -----BEGIN CERTIFICATE-----
        <ca cert goes here>
        -----END CERTIFICATE-----

coreos:
  update:
    reboot-strategy: reboot
  units:
  units:
    - name: var-lib-docker.mount
      command: start
      content: |
        [Unit]
        Description=Mount RAM to /var/lib/docker
        Before=docker.service
        [Mount]
        What=tmpfs
        Where=/var/lib/docker
        Type=tmpfs
        Options=size=200g
    - name: docker.service
      command: restart
      content: |
        [Unit]
        Description=Docker Application Container Engine
        Documentation=http://docs.docker.io
        After=network.target
        [Service]
        ExecStartPre=/bin/mount --make-rprivate /
        # Run docker but don't have docker automatically restart
        # containers. This is a job for systemd and unit files.
        ExecStart=/usr/bin/docker -d \
          --tlsverify \
          --tlscert=/home/core/server.crt \
          --tlscacert=/home/core/ca.crt \
          --tlskey=/home/core/server.key \
          -H 0.0.0.0:2376 -H unix:///var/run/docker.sock

        [Install]
        WantedBy=multi-user.target

dockerクライアントを使用して、リモートDockerサーバーにアクセスすることに成功しました。リモートサーバーは1日に最大10万回呼び出され、成功を収めています。

curlまたはPython2.7でpip install --upgradeを介してインストールされたdocker-composeを使用しようとすると、SSLエラーが発生します。

$ docker-compose up -d
SSL error: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

これは、 DOCKER_CERT_PATH=/home/user/.docker/とREQUESTS_CA_BUNDLE=/home/user/.docker/ca.pemを個別に、または一緒に手動で指定した後の場合です。

明確にするために：このセットアップはdockerデーモンだけでうまく機能しますが、 -composeについての何かが間違っています。

grahamc 2015年05月28日

いくつかの注意：

OSX用のCompose1.3.0RC1バイナリにはこのバグがあります。偶然ではないかもしれませんが、Python 2.7.9に対してビルドされたのはこれが初めてです。以前は、2.7.6でした。
奇妙なことに、boot2docker VMに対しては再現できますが、MachineによってプロビジョニングされたVirtualboxVMに対しては再現できません。 @ ehazlett 、 @ nathanleclaire 、 @ tianon-そこに何か洞察はありますか？
ComposeがPipとともにインストールされているときにこれを経験している人には、次のコマンドの出力を報告してください。

$ python -V $ python -c 'import ssl; print ssl.OPENSSL_VERSION'

エラーを再現できるローカルマシンには、 Python 2.7.10とOpenSSL 1.0.2a 19 Mar 2015ます。

これはHomebrewに報告されており、PythonとOpenSSLの再インストールに成功したと言う人もいますが、私にはうまくいきませんでした。 https://github.com/Homebrew/homebrew/issues/38226

aanand 2015年05月28日

うーん、それは本当に奇妙です。使用しているb2dのバージョンとバージョン
機械の？どちらもb2dを使用しているので、何が違うのかわかりません
バージョンのほかに。

OS Xマシンにpip経由でインストールし、何が得られるかを確認します。

9:19の木、2015年5月28日には、Aanandプラサド[email protected]
書きました：

いくつかの注意：
1.1。
OSX用のCompose1.3.0RC1バイナリにはこのバグがあります。おそらくそうではない
偶然にも、Python2.7.9に対してビルドされたのはこれが初めてです。
以前は2.7.6でした。
2.2。
奇妙なことに、boot2docker VMに対しては再現できますが、
MachineによってプロビジョニングされたVirtualboxVM。 @ehazlett
https://github.com/ehazlett、@ nathanleclaire
https://github.com/nathanleclaire、@tianon
https://github.com/tianon-そこに何か洞察はありますか？
3.3。
ComposeがPipとともにインストールされているときにこれを経験している人は、どうぞ
次のコマンドの出力を報告します。
$ python -V
$ python -c'import ssl; print ssl.OPENSSL_VERSION '
エラーを再現できるローカルマシンには、Pythonがあります
2.7.10およびOpenSSL1.0.2a 2015年3月19日。
4.4。
これはHomebrewに報告されており、一部の人々は彼らが持っていたと言います
PythonとOpenSSLの再インストールに成功しましたが、うまくいきませんでした。
自作/自作＃38226
https://github.com/Homebrew/homebrew/issues/38226
—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/compose/issues/890#issuecomment-106306690 。

ehazlett 2015年05月28日

$ boot2docker version
Boot2Docker-cli version: v1.6.2
Git commit: cb2c3bc

$ docker-machine --version
docker-machine version 0.2.0 (8b9eaf2)

証明書の生成について何か違うのでしょうか？ boot2dockerよりもマシンの証明書ディレクトリに多くのファイルがあるようです。

$ $(boot2docker shellinit)
$ ls -l $DOCKER_CERT_PATH/*.pem
-rw-r--r--  1 aanand  staff  1042 28 May 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
-rw-r--r--  1 aanand  staff  1070 28 May 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
-rw-r--r--  1 aanand  staff  1675 28 May 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem

$ eval "$(docker-machine env)"
$ ls -l $DOCKER_CERT_PATH/*.pem
-rw-r--r--  1 aanand  staff  1029 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/ca.pem
-rw-r--r--  1 aanand  staff  1054 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/cert.pem
-rw-r--r--  1 aanand  staff  1679 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/key.pem
-rw-------  1 aanand  staff  1679 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/server-key.pem
-rw-r--r--  1 aanand  staff  1086 11 May 12:15 /Users/aanand/.docker/machine/machines/dev/server.pem

aanand 2015年05月28日

それは結構です。クライアントは、ca.pem、cert.pem、およびkey.pemを使用するだけです。
（サーバーは、マシン内のホストの単なるローカルコピーです）。私はとして作成します
よく、証明書を調べて、違いが何であるかを確認します。

午前9時30分木、2015年5月28日には、Aanandプラサド[email protected]
書きました：

$ boot2dockerバージョン
Boot2Docker-cliバージョン：v1.6.2
Gitコミット：cb2c3bc
$ docker-machine --version
docker-machineバージョン0.2.0（8b9eaf2）
証明書の生成について何か違うのでしょうか？もっとあるようです
boot2dockerよりもマシンのcertdirにあるファイル。
$ $（boot2docker shellinit）
$ ls -l $ DOCKER_CERT_PATH/*。pem
-rw-r--r-- 1aanandスタッフ104225月28日14：27 / Users / aanand / .boot2docker / certs / boot2docker-vm / ca.pem
-rw-r--r-- 1aanandスタッフ10705月28日14：27 / Users / aanand / .boot2docker / certs / boot2docker-vm / cert.pem
-rw-r--r-- 1aanandスタッフ167525月28日14：27 / Users / aanand / .boot2docker / certs / boot2docker-vm / key.pem
$ eval "$（docker-machine env）"
$ ls -l $ DOCKER_CERT_PATH/*。pem
-rw-r--r-- 1aanandスタッフ1029115月12：15 / Users / aanand / .docker / machine / machines / dev / ca.pem
-rw-r--r-- 1aanandスタッフ105415月12：15 / Users / aanand / .docker / machine / machines / dev / cert.pem
-rw-r--r-- 1aanandスタッフ167911 May 12:15 /Users/aanand/.docker/machine/machines/dev/key.pem
-rw ------- 1aanandスタッフ167911 May 12:15 /Users/aanand/.docker/machine/machines/dev/server-key.pem
-rw-r--r-- 1aanandスタッフ108615月11日12：15 / Users / aanand / .docker / machine / machines / dev / server.pem
—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/compose/issues/890#issuecomment-106309885 。

ehazlett 2015年05月28日

grahamc@snap$ python -V
Python 2.7.6

grahamc@snap$ python -c 'import ssl; print ssl.OPENSSL_VERSION'
OpenSSL 1.0.1e-fips 11 Feb 2013

grahamc 2015年05月28日

https://github.com/docker/docker-py/issues/465も参照して@garethrのテストスクリプトは、ホスト名チェックを無効にするために1つの変更を加えた後、私にもエラーを再現します。

from docker.client import Client
from docker.utils import kwargs_from_env

kwargs = kwargs_from_env()
kwargs['tls'].assert_hostname = False

client = Client(**kwargs)
print client.version()

$ eval "$(boot2docker shellinit)" && python test.py
Writing /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
Writing /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
Writing /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem
Traceback (most recent call last):
  File "test.py", line 8, in <module>
    print client.version()
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", line 1108, in version
    return self._result(self._get(url), json=True)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", line 106, in _get
    return self.get(url, **self._set_request_timeout(kwargs))
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 477, in get
    return self.request('GET', url, **kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 465, in request
    resp = self.send(prep, **send_kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 573, in send
    r = adapter.send(request, **kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", line 431, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

ただし、マシンでプロビジョニングされたVMでは引き続き機能します。

$ eval "$(docker-machine env)" && python test.py
{u'KernelVersion': u'4.0.3-boot2docker', u'Arch': u'amd64', u'ApiVersion': u'1.18', u'Version': u'1.6.2', u'GitCommit': u'7c8fca2', u'Os': u'linux', u'GoVersion': u'go1.4.2'}

ホスト名チェックを再度有効にすると（テストスクリプトのassert_hostname行をコメントアウトすることにより）、boot2docker-cli VMに対しては同じエラーで失敗しますが、マシンVMに対しては

Traceback (most recent call last):
  File "test.py", line 8, in <module>
    print client.version()
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", line 1108, in version
    return self._result(self._get(url), json=True)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", line 106, in _get
    return self.get(url, **self._set_request_timeout(kwargs))
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 477, in get
    return self.request('GET', url, **kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 465, in request
    resp = self.send(prep, **send_kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", line 573, in send
    r = adapter.send(request, **kwargs)
  File "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", line 431, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: no appropriate commonName or subjectAltName fields were found

aanand 2015年05月28日

さらに、curl（pipではなくバイナリリリース）を介してv1.3.0-rc1を使用しようとしましたが、docker1.6.2デーモンで以前と同じエラーが発生しました。

SSL error: [Errno 1] _ssl.c:507: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

grahamc 2015年05月28日

ええ-RC1バイナリはPython2.7.9とOpenSSL1.0.2aで構築されましたが、これは問題のある組み合わせの1つと思われます。

aanand 2015年05月28日

b2dでの証明書の生成はVM上にあると私は信じているので、これは理にかなっています
一方、machineはそれらをmachineで生成します。を検出して追加できます
必要に応じて、SANへのマシン名。実際、それはおそらく良いでしょう
特にb2dVMの場合。今それが機能する理由はあなたが
マシンがIPSANとして追加するIPを使用してエンジンにアクセスします。あります
PRを開いて、任意の追加SANを許可します。これも機能します。

2015年5月28日（木曜日）に、Aanandプラサドの[email protected]は書きました：

docker / docker-py＃465も参照してください。
https://github.com/docker/docker-py/issues/465。 @garethr
https://github.com/garethrのテストスクリプトでエラーが再現されます
私も、ホスト名チェックを無効にするために1つの変更を加えた後：
docker.clientからimportClientfrom docker.utils import kwargs_from_env
kwargs = kwargs_from_env（）
kwargs ['tls']。assert_hostname = False
client = Client（** kwargs）print client.version（）
$ eval "$（boot2docker shellinit）" && python test.py
/Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pemの書き込み
/Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pemの書き込み
/Users/aanand/.boot2docker/certs/boot2docker-vm/key.pemの書き込み
トレースバック（最後の最後の呼び出し）：
ファイル "test.py"、8行目、
client.version（）を出力します
ファイル "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py"、行1108、バージョン
self._result（self._get（url）、json = True）を返します
ファイル "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py"、行106、_get
self.get（url、* _self._set_request_timeout（kwargs））を返します
ファイル "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py"、行477、get
self.request（ 'GET'、url、* _kwargs）を返します
ファイル "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py"、行465、リクエスト
resp = self.send（prep、* _send_kwargs）
ファイル "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py"、行573、送信
r = adapter.send（request、* _kwargs）
ファイル "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py"、行431、送信
SSLError（e、request = request）を発生させます
requests.exceptions.SSLError：[SSL：CERTIFICATE_VERIFY_FAILED]証明書の検証に失敗しました（_ssl.c：590）
ただし、マシンでプロビジョニングされたVMでは引き続き機能します。
$ eval "$（docker-machine env）" && python test.py
{u'KernelVersion '：u'4.0.3-boot2docker'、u'Arch '：u'amd64'、u'ApiVersion '：u'1.18'、u'Version '：u'1.6.2'、u'GitCommit '：u'7c8fca2'、u'Os '：u'linux'、u'GoVersion '：u'go1.4.2'}
ホスト名チェックを再度有効にした場合（assert_hostnameをコメントアウトすることにより）
テストスクリプトの行）、それは_同じエラー_で失敗します
boot2docker-cli VMですが、マシンVMに対して_異なるエラー_が発生します。
関連する場合と関連しない場合があります。
トレースバック（最後の最後の呼び出し）：
ファイル "test.py"、8行目、
client.version（）を出力します
ファイル "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py"、行1108、バージョン
self._result（self._get（url）、json = True）を返します
ファイル "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py"、行106、_get
self.get（url、* _self._set_request_timeout（kwargs））を返します
ファイル "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py"、行477、get
self.request（ 'GET'、url、* _kwargs）を返します
ファイル "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py"、行465、リクエスト
resp = self.send（prep、* _send_kwargs）
ファイル "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py"、行573、送信
r = adapter.send（request、* _kwargs）
ファイル "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py"、行431、送信
SSLError（e、request = request）を発生させます
requests.exceptions.SSLError：適切なcommonNameまたはsubjectAltNameフィールドが見つかりませんでした
—
このメールに直接返信するか、GitHubで表示してください
https://github.com/docker/compose/issues/890#issuecomment-106363305 。

ehazlett 2015年05月28日

OK、OS Xの修正に到達したと思います： https ：

Linux用に修正するには、DockerfileをPython2.7.9とOpenSSL1.0.1に固定するように更新する必要があります。これは、 debian:wheezyから始まるので楽しい作業になります（十分に使用していることを確認するために行います）。古いglibc-https：//github.com/docker/compose/pull/505を参照）。

aanand 2015年05月28日

@kretzのコメントで説明されているように1.0.1kに切り替え、pip経由で1.3.0 RC1をインストールすることで、

Pythonを切り替える前に、1.0.2aが報告されました。

❯ python -c 'import ssl; print ssl.OPENSSL_VERSION'
OpenSSL 1.0.2a 19 Mar 2015

切り替えた後、1.0.1kと報告され、docker-composeは期待どおりに機能しているようです。

❯ python -c 'import ssl; print ssl.OPENSSL_VERSION'
OpenSSL 1.0.1k 8 Jan 2015

matschaffer 2015年05月29日

このエラーを削除した回避策は、virtualenvに次のパッケージをインストールすることでした。
pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7

jsh2134 2015年05月29日

https://github.com/docker/compose/issues/890#issuecomment-106289821で説明されている環境でPython2.7.6を提供します（snap-ci.com経由で無料アカウントを取得できます）

pipインストールで@ jsh2134の回避策を使用する次のスクリプト（https://github.com/docker/compose/issues/890#issuecomment-106806702）を使用します。

#!/bin/bash

set -e
set -u
set -x


readonly DOCKER_VERSION=1.5.0
readonly TARGETFILE=$SNAP_CACHE_DIR/docker-$DOCKER_VERSION
[[ -f "$TARGETFILE" ]] || curl https://get.docker.io/builds/Linux/x86_64/docker-$DOCKER_VERSION > $TARGETFILE
cp $TARGETFILE ~/docker
chmod +x ~/docker


export DOCKER_HOST="tcp://docker-builds:2376" DOCKER_TLS_VERIFY=1

mkdir -p ~/.docker
cat > ~/.docker/ca.pem <<EOC
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

EOC
cat > ~/.docker/key.pem <<EOC
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

EOC
cat > ~/.docker/cert.pem <<EOC
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
EOC

function install_docker_compose {
  pip install --upgrade pip
  pip install --upgrade docker-compose
  pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7
  export COMPOSE=docker-compose
}

install_docker_compose

export COMPOSE_PROJECT_NAME=$(basename "$(pwd)")-${SNAP_COMMIT:-HEAD}

# Before running anything, setup the EXIT trap to always rm the container on
# exit of the script.
function cleanup {
  $COMPOSE kill
  $COMPOSE rm --force
}

trap cleanup EXIT

$COMPOSE --version
$COMPOSE build
$COMPOSE up -d

set +e
$COMPOSE run $@
exitcode=$?
set -e

set +x
echo ""
echo "Component Data:"
for id in `$COMPOSE ps -q`; do
  ~/docker inspect \
    -f 'Container {{ .Name }} exited with status {{ .State.ExitCode }}' $id
  ~/docker logs $id 2>&1 | sed -e "s/^/        /"
  echo "---"
done

exit $exitcode

次の出力が得られます。

+ readonly DOCKER_VERSION=1.5.0
+ DOCKER_VERSION=1.5.0
+ readonly TARGETFILE=/var/go/docker-1.5.0
+ TARGETFILE=/var/go/docker-1.5.0
+ [[ -f /var/go/docker-1.5.0 ]]
+ cp /var/go/docker-1.5.0 /var/go/docker
+ chmod +x /var/go/docker
+ export DOCKER_HOST=tcp://docker-builds:2376 DOCKER_TLS_VERIFY=1
+ DOCKER_HOST=tcp://docker-builds:2376
+ DOCKER_TLS_VERIFY=1
+ mkdir -p /var/go/.docker
+ cat
+ cat
+ cat
+ install_docker_compose
+ /bin/true
+ pip install --upgrade pip
/var/go/py-virtualenv2.7/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Collecting pip
  Using cached pip-7.0.1-py2.py3-none-any.whl
Installing collected packages: pip
  Found existing installation: pip 6.0.8
    Uninstalling pip-6.0.8:
      Successfully uninstalled pip-6.0.8
Successfully installed pip-7.0.1
+ pip install --upgrade docker-compose
/var/go/py-virtualenv2.7/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Requirement already up-to-date: docker-compose in /var/go/py-virtualenv2.7/lib/python2.7/site-packages
Requirement already up-to-date: docopt<0.7,>=0.6.1 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: PyYAML<4,>=3.10 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: requests<2.6,>=2.2.1 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: texttable<0.9,>=0.8.1 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: websocket-client<1.0,>=0.11.0 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: docker-py<1.2,>=1.0.0 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: dockerpty<0.4,>=0.3.2 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: six<2,>=1.3.0 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from docker-compose)
Requirement already up-to-date: backports.ssl-match-hostname in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from websocket-client<1.0,>=0.11.0->docker-compose)
+ pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7
Collecting pyopenssl==0.14
/var/go/py-virtualenv2.7/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
  Downloading pyOpenSSL-0.14.tar.gz (128kB)
Collecting ndg-httpsclient==0.4
  Downloading ndg_httpsclient-0.4.0.tar.gz
Collecting pyasn1==0.1.7
  Downloading pyasn1-0.1.7.tar.gz (68kB)
Collecting cryptography>=0.2.1 (from pyopenssl==0.14)
  Downloading cryptography-0.9.tar.gz (302kB)
Requirement already satisfied (use --upgrade to upgrade): six>=1.5.2 in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from pyopenssl==0.14)
Collecting idna (from cryptography>=0.2.1->pyopenssl==0.14)
  Downloading idna-2.0.tar.gz (135kB)
Requirement already satisfied (use --upgrade to upgrade): setuptools in /var/go/py-virtualenv2.7/lib/python2.7/site-packages (from cryptography>=0.2.1->pyopenssl==0.14)
Collecting enum34 (from cryptography>=0.2.1->pyopenssl==0.14)
  Downloading enum34-1.0.4.tar.gz
Collecting ipaddress (from cryptography>=0.2.1->pyopenssl==0.14)
  Downloading ipaddress-1.0.7-py27-none-any.whl
Collecting cffi>=0.8 (from cryptography>=0.2.1->pyopenssl==0.14)
  Downloading cffi-1.0.3.tar.gz (317kB)
Collecting pycparser (from cffi>=0.8->cryptography>=0.2.1->pyopenssl==0.14)
  Downloading pycparser-2.13.tar.gz (299kB)
Installing collected packages: idna, pyasn1, enum34, ipaddress, pycparser, cffi, cryptography, pyopenssl, ndg-httpsclient
  Running setup.py install for idna
  Running setup.py install for pyasn1
  Running setup.py install for enum34
  Running setup.py install for pycparser
  Running setup.py install for cffi
  Running setup.py install for cryptography
  Running setup.py install for pyopenssl
  Running setup.py install for ndg-httpsclient
Successfully installed cffi-1.0.3 cryptography-0.9 enum34-1.0.4 idna-2.0 ipaddress-1.0.7 ndg-httpsclient-0.4.0 pyasn1-0.1.7 pycparser-2.13 pyopenssl-0.14
+ export COMPOSE=docker-compose
+ COMPOSE=docker-compose
+++ pwd
++ basename /var/snap-ci/repo/tests/composer
+ export COMPOSE_PROJECT_NAME=composer-a71ac4f39281a9571a2b5da1284ab1c05da40646
+ COMPOSE_PROJECT_NAME=composer-a71ac4f39281a9571a2b5da1284ab1c05da40646
+ trap cleanup EXIT
+ docker-compose --version
docker-compose 1.2.0
+ docker-compose build
test1 uses an image, skipping
test2 uses an image, skipping
test uses an image, skipping
+ docker-compose up -d
SSL error: [Errno bad handshake] [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')]
+ cleanup
+ docker-compose kill
SSL error: [Errno bad handshake] [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')]

特にエラーに注意してください（これは新しいようです）：

/var/go/py-virtualenv2.7/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.

grahamc 2015年05月29日

https://github.com/docker/compose/issues/1484を作成して、これまでの調査結果をブレインダンプしました。

aanand 2015年05月29日

＃1474の修正でいくつかのバイナリを構築しました。 SSLの問題が発生している場合は、試してみてください。

http://cl.ly/3W3a2S3t2c32/download/docker-compose-Linux-x86_64
http://cl.ly/0i00310l3x27/download/docker-compose-Darwin-x86_64

aanand 2015年06月02日

+ curl -L http://cl.ly/3W3a2S3t2c32/download/docker-compose-Linux-x86_64
+ /usr/bin/docker-compose --version
docker-compose version: 1.3.0rc1
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013

+ /var/go/docker-compose up -d
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

grahamc 2015年06月02日

@ jsh2134なぜpyOpenSSLを0.14に固定しているのですか？

hynek 2015年06月04日

@kretzの回答は+1 :)

stringbeans 2015年06月27日

+1同じ問題：（dockerがosxで完全に壊れているようですか？

BlueHotDog 2015年06月28日

@coderfiソリューションは私のために働いた：Windows 7

crramirez 2015年06月29日

Dockerマシンでコンテナーを起動するクライアントとして機能しているCentos7VMのバリアントエラーの1つに対処する：

[ root @ xxxx cm]＃docker-compose ps
SSLエラー：適切なcommonNameまたはsubjectAltNameフィールドが見つかりませんでした

これは一時的なものでした。ログアウトしてSSHで再度ログインしても、しばらくの間エラーが表示されませんでした。今それを常に見ています。

[ root @ xxxx cm] ＃python -c'import ssl; print（ssl.OPENSSL_VERSION） '
OpenSSL 1.0.1e-fips 2013年2月11日

[ root @ xxxx cm] ＃dockerバージョン
クライアントバージョン：1.6.2
クライアントAPIバージョン：1.18
Goバージョン（クライアント）：go1.4.2
Gitコミット（クライアント）：ba1f6c3 / 1.6.2
OS / Arch（クライアント）：linux / amd64
サーバーバージョン：swarm / 0.2.0
Goバージョン（サーバー）：go1.3.3
Gitコミット（サーバー）：48fd993
OS / Arch（サーバー）：linux / amd64

[ root @ xxxx cm]＃docker-compose --version
docker-compose 1.2.0

上記の修正のいくつかを自分の環境に適用する方法がわかりません。私はboot2dockerを使用していません。 bashコマンドラインでdocker1.6.2を処理します。

stefan-jones 2015年06月30日

こんにちは。私は実際にその問題を開いたので、修正できません。私はたくさんのことを試しました。つまり、pip / brew /最新バージョンでcomposeをインストールします。 opensslが0.x1.0.2xバージョンなどを試したが、まだ機能しないのと同じです。

PS：私はboot2dockerを使用していません。私はvagrantを介して作成した独自のVMを持っており、証明書を生成し、それらを使用してdockerデーモンを起動します。どうやらそれはdockerで動作するので、問題は私の証明書から来ていません。

>>> docker run hello-world
Hello from Docker.
[...]
>>> docker-compose up
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)
>>> docker-compose -v
docker-compose version: 1.3.1
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1j 15 Oct 2014
>>> docker -v
Docker version 1.6.2, build 7c8fca2

このエラーも一度に発生しました：

/usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
SSL error: [Errno 1] _ssl.c:507: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

catuss-a 2015年06月30日

ここを読んで、提案されたパッケージをインストールすることをいじった後：

https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning

docker-composeからのエラーメッセージが変更されました。

[ root @ xxx cm]＃docker-compose up -d
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:251：SecurityWarning：証明書にsubjectAltNameがないため、フォールバックしてcommonNameを確認します。今。この機能は主要なブラウザーによって削除され、RFC 2818によって非推奨になりました（詳細については、https：//github.com/shazow/urllib3/issues/497を参照してください）。
セキュリティ警告
SSLエラー：ホスト名 'xx.xx.xx.xx'が一致しませんなし

（私がxxした点線のクワッドは、スウォームマスター/ドッカーホストのものです）。

この問題は、証明書を編集または再生成することでも解決できますか？

補遺：証明書は、「docker-machinecreate」によってこれらのVMで作成されました。

証明書の詳細が不十分になるdocker-machineのバグに対処できますか？

stefan-jones 2015年06月30日

このエラーは、docker-machineで作成されたDockerホストでのみ発生します。 SSL証明書が正しく作成されていないと思いますか？

prologic 2015年07月03日

誰かがこれを修正するための回避策または解決策を持っていますか？これは私にとって今のところ少しブロッカーです：/

prologic 2015年07月07日

@prologicバイナリまたはPipでインストールされたComposeでエラーが発生しますか？後者の場合は、 requests[security]もインストールしてみてください。

aanand 2015年07月07日

@aanandありがとう！私はそれを試して、それがうまくいくかどうかを報告します！

prologic 2015年07月07日

@prologic PythonのバグのあるSSLモジュールに依存する代わりに、 requests[security]をパッケージ化したい。＃1530で努力を追跡しています。

aanand 2015年07月07日

@aanandありがとうございます！これは完璧に機能しました:)

prologic 2015年07月07日

@coderfiあなたのソリューションは私のために働いた、ありがとう

ouit0408 2015年07月09日

@ aanand 6月2日のビルドは私にとっては問題なく動作します。この痛みを伴うバグを押しつぶして頑張ってください。

rseymour 2015年07月09日

@neilsarkar私はたまたまcharlesプロキシを実行していました、あなたのコメントは私を救いました。：+1：

martzcodes 2015年07月10日

私はOSX 10.9.5を使用しています、これが私の選択です：

# ➜  openssl version
# OpenSSL 1.0.2d 9 Jul 2015

➜  pyenv local system # switch to built-in python 2.7.5 for current directory
# ➜  python --version
# Python 2.7.5
# ➜  python -c 'import ssl; print(ssl.OPENSSL_VERSION)'
# OpenSSL 0.9.8zd 8 Jan 2015

# ➜  docker-compose --version
# docker-compose version: 1.3.1
# CPython version: 2.7.5
# OpenSSL version: OpenSSL 0.9.8zd 8 Jan 2015

# ➜  docker-compose ps
# /usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
#   InsecurePlatformWarning
# Name   Command   State   Ports
# ------------------------------

twlz0ne 2015年07月14日

私の回避策：

246：253行をコメントアウト
/usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connection.py

これはセキュリティ例外をスローしている部分です

ernstnaezer 2015年07月14日

私にとっての問題は、brew link --force openssl、fig / docker-composeを指定しても、/ usr / bin / opensslを使用することでした。

$ sudo mv /usr/bin/openssl /usr/bin/openssl_old
$ brew link --force openssl OR brew unlink openssl && brew link --force openssl

これは私のために働いた。今、私はもう迷惑なメッセージを受け取りません。

naillizard 2015年07月20日

参考までに、brew fig / docker-composeレシピはシステムpythonを使用するため、pyenvまたはbrewを介してpythonをインストールした場合でも、brew install fig / docker-composeは、利用可能な場合はシステムopenssl libを使用します。それ以外の場合は、他のバージョンをインストールします。

仕事中のMACで、pyenv install 2.7.8、easy_install pip、pip installdocker-composeで解決しました。

しかし、自宅のMacでは、「両方ともヨセミテを実行しています」と同じことをしましたが、それでも警告が表示されます。

掘り続けます。

naillizard 2015年07月26日

@ dtunes-根本的な原因（上記で参照されている@aanand ）はhttps://github.com/boot2docker/boot2docker/issues/808です。 system-python / homebrew-pythonは、新しいOpenSSLと古いOpenSSLのどちらに対してリンクされているかによって異なるため、非常に重要です。

glyph 2015年08月01日

はい、そのチケットを見ました。私を悩ませているのは、仕事中の私のMacで、上記のさまざまなアプローチを試した後、どれもうまくいかなかったことです。
次に、/ usr / bin / opensslを/ usr / bin / openssl_oldに移動し、home brewを使用して最新のopensslをインストールし、強制的にリンクしました。その時だけ私は次のことをしました：

~ $ brew install pyenv
~ $ pyenv install 2.7.8
~ $ pyenv global 2.7.8
~ $ easy_install pip
~ $ pip install docker-compose

これは仕事でトリックをしました、しかし私の自宅のMacでは、それはうまくいきませんでした。ただし、間違えた場合に備えて再試行し、結果を報告します。

naillizard 2015年08月03日

@ dtunes-すべての依存関係を再構築するには、 ~/Library/Caches/pipを削除して、間違ったOpenSSLに対して構築されたキャッシュされたバイナリホイールが再利用されないようにする必要があります。

glyph 2015年08月04日

@glyphは書いた：

根本的な原因（上記で参照されている@aanand ）は、boot2docker / boot2docker＃808です。 system-python / homebrew-pythonは、新しいOpenSSLと古いOpenSSLのどちらに対してリンクされているかによって異なるため、非常に重要です。

@glyphまたは@aanand 、それは、＃1474からマージされた@aanandの修正（@ aanand 、boot2docker / boot2docker＃808が適切にアドレス指定されている場合、＃1474をバックアウトする必要がありますか？次の暗号化リリース（これとこれを参照）にも希望を置いていますか？

@aanandは書いた：

docker-machineでプロビジョニングされたBoot2DockerVMに対してこのエラーを再現できないことに注意してください。これは、boot2dockerコマンドでプロビジョニングされたVMに対してのみ発生します。

@ehazlettは書いた：

これは理にかなっています。なぜなら、b2dでの証明書の生成はVMで行われるのに対し、machineはそれらをmachineで生成するからです。

私は誤解しているかもしれませんが、これと関連する問題について、ホスト側のPython / OpenSSLのさまざまな組み合わせを非難するおしゃべりがたくさんあります。問題の原因がb2dで配布されている壊れたOpenSSLである場合、Composeのホスト側のOpenSSLが同様に壊れていることを確認するのが最善の方法かどうかわかりません。価値があるのは、これらのタイプのホスト側のゆがみが、（たとえば）Vagrantを介してb2dを実行し、Composeの外部でb2dにアクセスする人にとってこの問題を解決する可能性は低いです（たとえば、docker / docker-py＃465を参照）。

このコメントがboot2docker / boot2docker＃808でより適切である場合は、そこに移動できます。

posita 2015年08月04日

私は自作のメンテナであり、グリフがこれを実行するのを手伝いました。

boot2dockerによって生成されたサーバー証明書のサブジェクトDNと発行者DNは、同じように/O=Boot2Docker設定されます。サーバー証明書は実際にはCA証明書によって署名されていると思いますが、AFAICT OpenSSL 1.0.2は、提供されたサーバー証明書に対してサーバー証明書を検証するのではなく、この情報（つまり、同一のサブジェクトDNと発行者DN）を使用して、サーバー証明書を自己署名として拒否します。 CA証明書。 1.0.2より前のバージョンのOpenSSLは、提供されたCA証明書に対してサーバー証明書を検証します。これは成功します。

サーバー証明書とCA証明書に個別のサブジェクトDNを指定すると（サーバー証明書に個別のサブジェクトDNと発行者DNが含まれるように）、すべてのOpenSSLバージョンで証明書を検証できると思いますがテストはしていません。私は（このX.509サバイバルガイドを読んだが、関連する仕様は読んでいないことに基づいて）疑っていますが、OpenSSL 1.0.2の動作は合理的であり、OpenSSL開発者が解決する必要のあるリグレッションを表していないと確信していません。

1474は2つの異なることを行います：

Pythonの最小バージョンを2.7.9に設定：これにより、urllib3はInsecurePlatformWarningを発行せずにリクエストを完了できます。これは、Pythonバージョンが2.7.9より前であり、PyOpenSSLモジュールの2つの条件の両方が満たされた場合にHTTPS接続を行うときに発行されます。存在しません。 PyOpenSSLをバンドルすることも同様に効果的ですが、PyInstallerと互換性がないことを議論から理解しています。いずれにせよ、urllib3のInsecurePlatformWarningはboot2docker証明書の問題とは関係がなく、証明書を修正してもこの回避策の必要性がなくなるわけではありません。
OpenSSLの最大バージョンを1.0.1jに設定します。 boot2docker証明書が修正されたら、これは不要になるはずです。

問題の原因がb2dで配布された壊れたOpenSSLである場合

そうではない; OpenSSL≥1.0.2を使用しているクライアントによると、boot2docker証明書（このコードによって生成される）は無効です。 boot2dockerで配布されるOpenSSLライブラリは関係ありません。

tdsmith 2015年08月04日

@glyphまたは@aanand 、それは、＃1474からマージされた@aanandの修正（@ aanand 、boot2docker / boot2docker＃808が適切にアドレス指定されている場合、＃1474をバックアウトする必要がありますか？次の暗号化リリース（これとこれを参照）にも希望を置いていますか？

はい、そう思います。この問題のあるOpenSSLは1.0.2であり、1.0.1に制限することで、証明書が失敗する原因となる検証ロジックを回避できると思います。エラーメッセージが非常にわかりにくいため、気に入らない証明書についてはまだわかりません。

また、＃1474が行っていることはあまりにも具体的すぎると思います。少なくとも私の読書からは、それは_minimum_ pythonバージョンを設定しているのではなく、_exact_バージョンを指定しています。また、jと1.0.1が異なる場合はチェックに失敗するようです。つまり、セキュリティ更新プログラムは1.0.1にも適用されません。これは_間違いなく_問題です。

glyph 2015年08月04日

サーバー証明書とCA証明書に個別のサブジェクトDNを指定すると（サーバー証明書に個別のサブジェクトDNと発行者DNが含まれるように）、すべてのOpenSSLバージョンで証明書を検証できると思いますがテストはしていません。私は（このX.509サバイバルガイドを読んだが、関連する仕様は読んでいないことに基づいて）疑っていますが、OpenSSL 1.0.2の動作は合理的であり、OpenSSL開発者が解決する必要のあるリグレッションを表していないと確信していません。

docker-machine生成された証明書を調査し、このプロパティがあるかどうかを確認します。 OpenSSLのリグレッションではなく、この動作が許容できると言うのはなぜですか？自己署名証明書を信頼することはまったく問題ありません。私が知っているように、サブジェクトまたは発行者に含まれる可能性のあるものに特別な制限はありません。そのガイドの一部をざっと読みましたが、自己署名証明書にはCAカルテルの信頼がないため、追加の構成がないとWebブラウザーはそれらを信頼しないことを指摘しているようです。

glyph 2015年08月04日

docker-machine VMの証明書を見ると、次のようになります。

...
        Issuer: O=glyph
...
        Subject: O=dev
...

だからあなたはこれについて正しいかもしれません...

glyph 2015年08月04日

docker-machineで生成された証明書を調査し、[サブジェクトDNと発行者DNが一致する]かどうかを確認します。

aanandのdocker-machine証明書にも個別のDNがあることがわかります：

自己署名証明書を信頼することはまったく問題ありません

ただし、自己署名証明書を信頼しない限り、自己署名証明書は無効です。サーバー証明書を信頼するようにOpenSSLに指示することはありません。サーバー証明書を発行したCAを信頼するようにOpenSSLに指示します。

OpenSSLのリグレッションではなく、この動作が許容できると言うのはなぜですか？

IANALですが、私の推論は、「厳密なレベルでは、[自己署名]は、証明書の発行者フィールドとサブジェクトフィールドが同じであることを意味します」という言葉に由来しています。これは、boot2dockerサーバー証明書の場合です。 OpenSSLがboot2dockerサーバー証明書を検証しようとすると、サーバー証明書はそれ自体で署名されているように見えますが、明示的に信頼されていないため、有効ではないため、CA証明書を考慮せずに完全な信頼チェーンを構築できます。これが厳密に正しい、または必要な動作であるとは確信できず、決定する資格もありませんが、「合理的」であるように思われます。

tdsmith 2015年08月04日

皆さん、掘ってくれてありがとう。

また、＃1474が行っていることはあまりにも具体的すぎると思います。少なくとも私の読書からは、Pythonの最小バージョンを設定しているのではなく、正確なバージョンを指定しています。また、jと1.0.1が異なる場合はチェックに失敗しているようです。つまり、1.0.1にもセキュリティ更新プログラムが適用されないため、これは間違いなく問題です。

同意しました。 boot2dockerの証明書と一致しないのがOpenSSL1.0.2であると仮定すると、その部分は少なくとも修正可能である必要があります-で最新のOpenSSL1.0.1を取得する方法を見ていきます。

aanand 2015年08月04日

@tdsmith 、誤解についての説明とお詫びに感謝します。 @glyph 、説明してくれてありがとう。

FWIW、私は@tdsmithの理論をテストしようとし、 generate_certをIssuerとSubject個別の値を作成しました。水を保持しているように見える場合があります（ただし、以下の警告を参照してください）。現在のgenerate_certとハッキングされたバージョンから生成された証明書を使用してb2dを実行すると、次のようになります。

`0.9.8zd`は元の`generate_cert` （0.1）で動作します

% /usr/bin/openssl version
OpenSSL 0.9.8zd 8 Jan 2015
% /usr/bin/openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=1 /O=Boot2Docker
verify return:1
depth=0 /O=Boot2Docker
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
-----BEGIN CERTIFICATE-----
MIIC/TCCAeegAwIBAgIRAKt8Sy0ND8z8omBU0uhODVAwCwYJKoZIhvcNAQELMBYx
...
qKFg5oUO9wigoGlwnSjqC/5ZmFRf9B+nWeCUVi/vWl0skOIqCMlDamD8AOVtmtRg
tg==
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2Docker
---
Acceptable client certificate CA names
/O=Boot2Docker
---
SSL handshake has read 2554 bytes and written 2188 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 621C9DF6883DA1FAF273408D0C984AC6E1DA33BA44ADA0EBA88BE59490560CFC
    Session-ID-ctx: 
    Master-Key: 39A75DE8551C41241CDBF889A5EF32DC7F86A45C792218B7E380E90627C7D0691BC5FCCAB69154B84142171F866F36C2
    Key-Arg   : None
    TLS session ticket:
    0000 - 77 ca 24 b7 2e 33 6a fc-9d 6e d0 eb aa 0d d5 89   w.$..3j..n......
    ...
    0630 - db 49 35 a1 97                                    .I5..

    Start Time: 1438703085
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
DONE

`1.0.2d` （MacPorts経由でインストール）は元の`generate_cert` （0.1）では機能しません

% openssl version
OpenSSL 1.0.2d 9 Jul 2015
% openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=0 O = Boot2Docker
verify error:num=18:self signed certificate
verify return:1
depth=0 O = Boot2Docker
verify error:num=21:unable to verify the first certificate
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
-----BEGIN CERTIFICATE-----
MIIC/TCCAeegAwIBAgIRAKt8Sy0ND8z8omBU0uhODVAwCwYJKoZIhvcNAQELMBYx
...
qKFg5oUO9wigoGlwnSjqC/5ZmFRf9B+nWeCUVi/vWl0skOIqCMlDamD8AOVtmtRg
tg==
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2Docker
---
Acceptable client certificate CA names
/O=Boot2Docker
Client Certificate Types: RSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2156 bytes and written 1373 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: BAE02ACF63C2F4E28C46664CEB8E790DB0F00E8CB75913484BFE88CC215995D2
    Session-ID-ctx: 
    Master-Key: C7227519074A26A51D815655721F18C63932897D731D1BF077B8374F8A021D51EDF2E603386D249ED62127BD71A86048
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - 14 b0 7a 58 68 91 62 10-14 53 04 cf da 41 63 6e   ..zXh.b..S...Acn
    ...
    0350 - 5f 8e fe fd 9c b0 d0                              _......

    Start Time: 1438703297
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
DONE

`0.9.8zd`はハッキングされた`generate_cert` （0.1.1;驚くことではありません）

% /usr/bin/openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=1 /O=Boot2DockerCA
verify return:1
depth=0 /O=Boot2Docker
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2DockerCA
-----BEGIN CERTIFICATE-----
MIIC/zCCAemgAwIBAgIRAMLl0tA00F2BDjyktFSD5aEwCwYJKoZIhvcNAQELMBgx
...
jhzP4aW3a8uAdpQXjf8nmJ5Qrq4Xb6yWAezXRdmPWfG1u4neBQKy1Zp64PiBd+0v
1UPu
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2DockerCA
---
Acceptable client certificate CA names
/O=Boot2DockerCA
---
SSL handshake has read 2563 bytes and written 2193 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: 1E52C9982BE1F98559529B9E804D330ADD5EC8654EE9F3AFE6139B2AEAB24919
    Session-ID-ctx: 
    Master-Key: 0714B120A52F735C484BF0F6612909CEB5FAF27D5E66B3DDB76DCB32FFE506F70E4BC5EFC42BB19E5CBE6223ACEA5803
    Key-Arg   : None
    TLS session ticket:
    0000 - c4 54 e0 2f 90 68 f2 22-7a c9 ee 2f fb da 25 7a   .T./.h."z../..%z
    ...
    0630 - 5c 95 c6 0a e9 bd 21 70-fd                        \.....!p.
    063a - <SPACES/NULS>

    Start Time: 1438703534
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
DONE

`1.0.2d` _works（！）_：tada ：： see_no_evil ：： hear_no_evil ：： speak_no_evil：ハッキングされた`generate_cert` （0.1.1）

% openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=1 O = Boot2DockerCA
verify return:1
depth=0 O = Boot2Docker
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2DockerCA
-----BEGIN CERTIFICATE-----
MIIC/zCCAemgAwIBAgIRAMLl0tA00F2BDjyktFSD5aEwCwYJKoZIhvcNAQELMBgx
...
jhzP4aW3a8uAdpQXjf8nmJ5Qrq4Xb6yWAezXRdmPWfG1u4neBQKy1Zp64PiBd+0v
1UPu
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2DockerCA
---
Acceptable client certificate CA names
/O=Boot2DockerCA
Client Certificate Types: RSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2899 bytes and written 2111 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: 0F1A3A0AB7B1E7C1CFD43CED169E730745DEB935C4DBEDDC7CD8AB698ECB8896
    Session-ID-ctx: 
    Master-Key: A48F441FD8677E1602BFB96DC7E9B39D0E9A7241D1C4AF93F3022ACB621C73E16BD69F557FF4428B033B1C07DF5EB0FB
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - 30 e1 e9 1a 4d e0 48 78-14 22 e8 21 5d 84 e7 6f   0...M.Hx.".!]..o
    ...
    0630 - 27 15 8a 64 ff 2e 24 44-3d d8                     '..d..$D=.

    Start Time: 1438703550
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
DONE

警告

すべての変更を制御しようとするために、元のgenerate_cert （0.1）がリリースされたとき、ビルドに使用されたgolang:1.3-cross Dockerイメージがパッケージにアクセスできるときにビルドされたことに注意してください。 sshと呼ばれます。その後、そのパッケージはopenssh-client置き換えられました。ハッキングされたgenerate_certビルドするときに使用されるOpenSSLのバージョンは1.0.1kです。これは静的にリンクされているようです。

% ldd generate_cert-0.1.1-linux-amd64
        linux-vdso.so.1 (0x00007ffd0936c000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007fddefe7f000)
        libc.so.6 => /lib/libc.so.6 (0x00007fddefb11000)
        /lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x00007fddf009a000)

したがって、次の2つのいずれかが発生しているように見えます。

@tdsmithが示唆しているように、OpenSSLの最新バージョンは、 Issuer == Subject場合に混乱します。または
OpenSSLで変更された証明書の生成については、他の何かがあり、OpenSSLの新しいバージョンでは、以前のバージョンで生成された証明書の検証に問題があります。

これをテストする1つの方法は、ハックせずにgenerate_certを再構築することですが、OpenSSLの更新バージョンを使用します。次にそれをします。

posita 2015年08月04日

したがって、 @ tdsmithが正しいように見えます。 Issuer <> Subjectを確保するためにハックをバックアウトした後、 golang:1.3-crossからの新しいバージョンのOpenSSLでgenerate_certを再構築すると、失敗に戻ります。クライアント側のそれ以降のOpenSSLバージョン：

`0.9.8zd` 、更新されたOpenSSLで`generate_cert` （0.1.2）と連携します

% /usr/bin/openssl version
OpenSSL 0.9.8zd 8 Jan 2015
% /usr/bin/openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=1 /O=Boot2Docker
verify return:1
depth=0 /O=Boot2Docker
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
-----BEGIN CERTIFICATE-----
MIIC/TCCAeegAwIBAgIRAIVQ9IAYtPQwnu/FHM8HNS0wCwYJKoZIhvcNAQELMBYx
...
xZ+XhXvepeJ/mBIui1qT3yAMum0Mj1zLAxqCY/qsEU4odsgU9N9DbUGngoIkBCrY
gw==
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2Docker
---
Acceptable client certificate CA names
/O=Boot2Docker
---
SSL handshake has read 2554 bytes and written 2188 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: FDE088ECF8D0EB2B36EC909B9A66C9C6770AE31355040761CB35150C5A56E92E
    Session-ID-ctx: 
    Master-Key: 86522F869CDE85C8171EEC3A7CF76FDF26F81AE6162DDDEA7D1C55FD5E49E4BDCA56D827C3BFECBFAD9AA2F71A5A94EE
    Key-Arg   : None
    TLS session ticket:
    0000 - 67 d0 60 8e 54 54 7c 7a-3e 5e 71 97 26 e0 06 2c   g.`.TT|z>^q.&..,
    ...
    0630 - cf 68 86 83 d7                                    .h...

    Start Time: 1438705996
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---
DONE

`1.0.2d` （MacPorts経由でインストール）は、更新されたOpenSSLを使用した`generate_cert` （0.1.2）では機能しません

% openssl version
OpenSSL 1.0.2d 9 Jul 2015
% openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
depth=0 O = Boot2Docker
verify error:num=18:self signed certificate
verify return:1
depth=0 O = Boot2Docker
verify error:num=21:unable to verify the first certificate
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
-----BEGIN CERTIFICATE-----
MIIC/TCCAeegAwIBAgIRAIVQ9IAYtPQwnu/FHM8HNS0wCwYJKoZIhvcNAQELMBYx
...
xZ+XhXvepeJ/mBIui1qT3yAMum0Mj1zLAxqCY/qsEU4odsgU9N9DbUGngoIkBCrY
gw==
-----END CERTIFICATE-----
---
Server certificate
subject=/O=Boot2Docker
issuer=/O=Boot2Docker
---
Acceptable client certificate CA names
/O=Boot2Docker
Client Certificate Types: RSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2156 bytes and written 1373 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: C2A8BF01E9B754CBF48C69243091C54DAD19DCF52D285C9379B684A3B333AFDD
    Session-ID-ctx: 
    Master-Key: F8510162517AF4C115A13B7CA9E05E04868B4D78CBFA57B28A5B9616EE6FBED6B7B4FC52C2003EBC5D150FA8BDE95F4C
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - bc bc 2c 3e 2d b0 92 49-80 c2 c0 df 4f bd fb 84   ..,>-..I....O...
    ...
    0350 - 1e c7 c2 b2 e6 f5 74                              ......t

    Start Time: 1438705985
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
DONE

posita 2015年08月04日

SvenDowideit / generate_cert＃10が必要です。ちなみに、ハッキングされたgenerate_certを指すb2dイメージを作成したい場合は、公式の修正がリリースされるまでこれらを

私が正しく理解していれば、これにより、クライアント側でOpenSSL / Pythonバージョンのゲームをプレイする必要がなくなります（少なくともこの問題に関しては）。

@SvenDowideitのタグ付け

posita 2015年08月04日

私はOpenSSLの人たちと少しやりとりをしました。スティーブヘンソンからの要約は次のとおりです。

From: Stephen Henson via RT <[email protected]>
Subject: [openssl.org #3979] New OpenSSL issue: valid certificate fails validation where subject text == issuer text
Date: August 5, 2015 at 04:32:18 PDT
Cc: [email protected]
Reply-To: [email protected]

... The bug is that OpenSSL 1.0.2 is less strict about
what counts as a valid self signed certificate. Before 1.0.2 the certificate
had to have issuer and subject matching, if present AKID==SKID and
keyUsage (if present) had to include keyCertSign. For1.0.2 and later the
keyCertSign check is no longer present.

The attached patch should fix it. Let me know if it works for you.

A workaround (other than making subject != issuer) is to include SKID/AKID in
all certificates.

Regards, Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

バグのあるOpenSSLクライアントに対応するために、b2dが証明書を生成する方法を変更することは、クライアント側でOpenSSLにパッチを適用してインストールするよりもはるかに優れているようです。ただし、どちらの特定のアプローチがより適切かはわかりません（件名を！=発行者にするか、すべての証明書にSKID / ADIDを含めるか）。そのお金を@SvenDowideitに渡します。：にやにや笑い：

好奇心旺盛な方のために（ここでも、このルートを取るべきではないと思います）、SteveからのOpenSSLパッチは次のとおりです。

diff --git a/crypto/x509v3/v3_purp.c b/crypto/x509v3/v3_purp.c
index 1f9296a..7a0130a 100644
--- a/crypto/x509v3/v3_purp.c
+++ b/crypto/x509v3/v3_purp.c
@@ -63,6 +63,7 @@
 #include <openssl/x509_vfy.h>

 static void x509v3_cache_extensions(X509 *x);
+static int check_ca(const X509 *x);

 static int check_ssl_ca(const X509 *x);
 static int check_purpose_ssl_client(const X509_PURPOSE *xp, const X509 *x,
@@ -493,7 +494,7 @@ static void x509v3_cache_extensions(X509 *x)
     if (!X509_NAME_cmp(X509_get_subject_name(x), X509_get_issuer_name(x))) {
         x->ex_flags |= EXFLAG_SI;
         /* If SKID matches AKID also indicate self signed */
-        if (X509_check_akid(x, x->akid) == X509_V_OK)
+        if (X509_check_akid(x, x->akid) == X509_V_OK && check_ca(x) == 1)
             x->ex_flags |= EXFLAG_SS;
     }
     x->altname = X509_get_ext_d2i(x, NID_subject_alt_name, NULL, NULL);

完全な履歴： http ： 3979。

posita 2015年08月05日

待ってください..._ less_ strict？より厳密なチェックが通過した場合、どのように_less_厳密なチェックが失敗するのか混乱していますか？

glyph 2015年08月05日

待ってください..._ less_ strict？より厳密なチェックが通過した場合、どのように_less_厳密なチェックが失敗するのか混乱していますか？

ええ、私もその言語の選択に問題がありました。差分を見ると、彼は、多くのチェックを実行しないことによって、自己署名としてより多くの証明書を誤ってスイープすることを意味していると思います（つまり、自己署名として適格でないものを決定する際の厳密性が低くなります）。しかし、あなたは正しいです。それは奇妙な言い回しです。

私はOpenSSLソースの調査にそれほど多くの時間を費やしていませんが、多くの場所でそれらがかなり浸透できないことがわかりました。おそらく、そのプロジェクトに取り組むには「特別な」考え方が必要です。：ニヤリ：

posita 2015年08月05日

私はOpenSSLソースの調査にそれほど多くの時間を費やしていませんが、多くの場所でそれらがかなり浸透できないことがわかりました。おそらく、そのプロジェクトに取り組むには「特別な」考え方が必要です。

控えめな表現だと思います：wink:。

いずれにせよ、OpenSSLの人々に連絡してくれてありがとう、ここでそれが解決されることをうれしく思います。それまでの間、b2dでそれを回避することは正しいことのように思われます。ここで作曲することは何もないと思いますが、待ってください。

glyph 2015年08月05日

ここで述べたよう

pip install requests[security]

iffy 2015年08月07日

@iffyそれは赤いニシンです。別のOpenSSLに対してリンクされたキャッシュされたバイナリホイールがあったため、おそらく修正されます。

glyph 2015年08月07日

参考までに、boot2docker / boot2docker＃1029として提出された修正を含むPR。

posita 2015年08月10日

これに対する修正（@positaに感謝！）は、boot2dockerの最新バージョンで公開されています。改良する：

$ boot2docker upgrade
$ boot2docker delete
$ boot2docker init
$ boot2docker up

それで問題は解決しました。ぜひお試しいただき、ご報告ください。

または、 Docker Machineに切り替えます。これは、新しいDockerToolboxの一部として標準で提供されています。

aanand 2015年08月12日

私はまだこの問題を抱えています...

❯ openssl version && docker-compose --version && docker-machine --version && python --version
OpenSSL 1.0.2d 9 Jul 2015
docker-compose version: 1.4.0
docker-machine version 0.4.1 (HEAD)
Python 2.7.10

❯ docker-compose ps
/usr/local/Cellar/fig/1.4.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Name   Command   State   Ports
------------------------------

chiefy 2015年08月17日

@ chiefydocker -compose呼び出しが成功しています。あなたが見ている警告は無害です。表示を避けたい場合は、OS X10.10.5にアップグレードする必要があります。

tdsmith 2015年08月17日

@tdsmithは私に無害ではなく、私のOCDを狂わせています：smile：ヒントをありがとう、今すぐアップグレードします。

chiefy 2015年08月17日

brew経由でインストールされたPythonバージョンをアンインストールすると、この問題が解決しました。 brew remove --force python

fredr 2015年08月27日

brewバージョンをアンインストールしましたが、まだPython 2.7.10があり、
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)エラー。

次の設定があります：

OpenSSL 0.9.8zg 14 July 2015
docker-compose version: 1.4.0
docker-machine version 0.4.1 (e2c88d6)
Python 2.7.10

@chiefy
問題を解決しましたか？

docker-composeの人が問題の解決に取り組んでいるかどうか、または基本的に問題ではないかどうかを誰かが知っていますか？

よろしく、

PavelPolyakov 2015年09月13日

@PavelPolyakov
番号。私の両方のMac（10.9.xと10.10.x）で、変更なしでさまざまなことを試しました。これはdocker-composeものではなく、PythonのものFWIWの多くだと思います。

chiefy 2015年09月13日

@chiefy
私は同意しますが、それを機能させる方法のバリエーションは見つかりませんでした:(

PavelPolyakov 2015年09月13日

誰もがすでにこの問題を解決しているようですが、私ではありません:)

brewを使用してPythonを一度インストールしましたが、システムを削除したと思うので、古いものに戻すオプションがありません。

私はいくつかのバリエーションでdockerをインストールしようとしました：

バイナリから（dockerツールボックスのダウンロード）
醸造自体から

しかし、私はまだ持っています：

誰かがこの行動を克服する方法の包括的なガイドを持っていますか？

よろしく、

PavelPolyakov 2015年09月16日

@ PavelPolyakov-バグは、boot2docker（場合によってはdocker-machine）が、PythonのSSLサポートでは使用できない証明書を作成していたことです。すべてのソフトウェアをアップグレードしても、古い証明書が残っている場合は、問題が発生します。したがって、この時点で、現在のバージョンのdocker-machineを使用して、取得した開発VMを再プロビジョニングし、新しいSSL証明書がプロビジョニングされるようにすることをお勧めします。これには、ホスト上の~/.dockerを脇に移動することが含まれる場合があります。

glyph 2015年09月17日

@PavelPolyakovと@ chiefy 、 @ glyphのアドバイスに加えて、これを試すこともできます（ boot2docker環境を完全に再プロビジョニングしたくない場合）：

% mv ~/.docker ~/.docker.bak
% ssh docker@[boot2dockerip]
docker@[boot2dockerip]'s password: [typically "tcuser"]
...
Boot2Docker version 1.8.1, build master : 7f12e95 - Thu Aug 13 03:24:56 UTC 2015
Docker version 1.8.1, build d12ea79
docker<strong i="10">@boot2docker</strong>:~$ rm -frv ~/.docker
...
docker<strong i="11">@boot2docker</strong>:~$ sudo -s
root<strong i="12">@boot2docker</strong>:/home/docker# rm -v /var/lib/boot2docker/tls/*
...
root<strong i="13">@boot2docker</strong>:/home/docker# shutdown -h now
...

[boot2dockerip]はVM環境に固有です。より簡単な方法があるかもしれません（例えば、Vagrantを使用している場合はvagrant ssh ）。次に、 boot2dockerインスタンスを再起動し、SSLエラーが引き続き発生するかどうかを確認します。

posita 2015年09月17日

@glyph

アドバイスをありがとう、私にとっては、docker-machineを再プロビジョニングすることは問題ではありません。しかし、それは役に立ちません。

docker＆coをインストールする場合：
brew install docker docker-machine docker-compose

その後、 defaultマシンは作成されません。そして、 docker-machine createを使用してそれを作成する方法がわかりません。

* .pkgファイルを使用してdocker-toolbeltをインストールすると、マシンは作成されますが、SSLエラーが発生します。
私もやろうとしました：

docker-machine regenerate-certs default

しかし、それは役に立ちません。

@posita
アドバイスもありがとうございます。
あなたのガイドでは、 mv ~/.docker ~/.docker-bakを提案しています-どのような理由で？これを行うとすぐに、ファイルが移動されるため、マシンを再起動できなくなります。
はい、マシンにログインしてtls/*を削除してからシャットダウンすることはできますが、再起動するにはどうすればよいですか？

ゼロから再プロビジョニングする方法は？

@すべて
docker（docker-composeが機能している）をインストールする方法は何ですか？ brew install経由ですか、それともtoolbelt .pkg経由ですか？
docker-machineにある証明書がPythonで有効で有用であることをどのように確認できますか？Pythonとopensslをbrewcanよりもさらにアップグレードするにはどうすればよいですか？

助けてくれてありがとう。

よろしく、

PavelPolyakov 2015年09月17日

@PavelPolyakov - docker-machineは、「デフォルト」マシンの概念がありません。 docker-machine create --driver virtualbox my-docker-machine実行できます。

glyph 2015年09月18日

@PavelPolyakovそれが終わったら、 eval "$(docker-machine env my-docker-machine)" 、またはローカル開発マシンを呼び出すために選択したことを行う必要があります。

glyph 2015年09月18日

@glyph
正解です。これは、 brewからすべてを実行する上で欠けていた部分defaultという名前のマシンを正常にプロビジョニングしました（* .pkgからのインストール中に実行されるのと同じです）。

ただし、いつものように、私は次のように終わります。

:(

PavelPolyakov 2015年09月18日

あなたのガイドでは、mv〜 / .docker〜 / .docker-bakに提案しています-どのような理由で？これを行うとすぐに、ファイルが移動されるため、マシンを再起動できなくなります。

@PavelPolyakov 、docker-machineは使いません。私は他の環境に基づいて推測していました。これが機能しない場合は無視してください。

はい、マシンにログインしてtls/*を削除してからシャットダウンすることはできますが、再起動するにはどうすればよいですか？

docker-machine restartは機能しませんか？

私のコメントは、Vagrantでboot2dockerを実行した私自身の経験に基づいています。 docker-machineにはあまり当てはまらないかもしれません。 @glyphはその環境でより多くの経験を持っているようです。私は彼の提案を試してみます。

dockerをインストールする方法は何ですか（docker-composeが機能しています）。 brew install経由ですか、それともtoolbelt .pkg経由ですか？

これはこの問題の範囲外です（特にdocker-compose示されているboot2docker証明書の問題を扱います）が、OSXではバイナリビルドを使用し

posita 2015年09月18日

@PavelPolyakov 、次のようにするとどうなりますか？

docker-machine create --driver virtualbox shiny-new-machine-74d5a19e
eval $( docker-machine env shiny-new-machine-74d5a19e )
docker-compose build

次の手順を実行すると表示されるboot2dockerのバージョンは何ですか？

docker-machine ssh shiny-new-machine-74d5a19e

shiny-new-machine-74d5a19eは、既存のインスタンスを参照していない限り、自由に置き換えてください（つまり、上記のコマンドを実行する前にdocker-machine lsを実行したときに、名前が表示されていないはずです。。）。

posita 2015年09月18日

@posita

PavelPolyakov 2015年09月18日

うーん....：混乱：

eval $( docker-machine env shiny-new-machine-74d5a19e ) # probably unnecessary if you're still in the same shell as above
which openssl
openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null

posita 2015年09月18日

@posita
引き続きご支援いただきありがとうございます。

openssl s_client -showcerts -connect "${DOCKER_HOST#tcp:\/\/}" -key "${DOCKER_CERT_PATH}/key.pem" -cert "${DOCKER_CERT_PATH}/cert.pem" -CAfile "${DOCKER_CERT_PATH}/ca.pem" -tls1 </dev/null
http://pastebin.com/Y9ZqfTVG

PavelPolyakov 2015年09月18日

別のOSXマシンで同じことを試みました。
すべての最新のアップデート（OSおよびbrewパッケージ）で、SSLで同じ問題に直面しました。

PavelPolyakov 2015年09月18日

@PavelPolyakov 、私はあなたのopenssl s_client ...ダンプからこれを見ています：

...
Certificate chain
 0 s:/O=shiny-new-machine-74d5a19e
   i:/O=PavelPolyakov
...

これらはboot2dockerデフォルトではなく、（現在は）次のようになっているはずです。

...
Certificate chain
 0 s:/O=Boot2Docker
   i:/O=Boot2Docker
...

詳細を知らなくても、 docker-machineは、仮想マシンをプロビジョニングするときにデフォルトを（どういうわけか）上書きしていると思います。しかし、 openssl呼び出しは機能しているように見えるので、これが問題であるかどうかはわかりません。また、 docker-composeが失敗する理由もわかりません。：交絡：

次の出力は何ですか？

(
set -x
eval $( docker-machine env shiny-new-machine-74d5a19e )
env | grep DOCKER
ls -al "${DOCKER_CERT_PATH}"
openssl x509 -in "${DOCKER_CERT_PATH}/cert.pem" -text
openssl x509 -in "${DOCKER_CERT_PATH}/ca.pem" -text
docker-compose --verbose version
docker-compose --verbose ps
DOCKER_TLS_VERIFY=0 docker-compose --verbose ps
) >"${HOME}/Desktop/docker-compose-890-outerr-$( date -u +%Y-%m-%dT%H:%M:%SZ ).txt" 2>&1

これにより、貼り付け/アップロードに適した~/Desktop/docker-compose-890-outerr-2015-09-18T14:45:29Z.txtようなファイルが作成されます。

posita 2015年09月18日

@posita
ここにあります：
http://pastebin.com/vWqZgVKi

PavelPolyakov 2015年09月18日

これはあなたの問題とは何の関係もないと確信していますが、 docker-composeとdocker-pyバージョンは遅れています。これらは最新のリリースです：

...
 docker-compose version: 1.4.1
 docker-py version: 1.4.0
...

また（そして私はこれを誤解しているかもしれません）、あなたのca.pemとcert.pemが同じSubject共有しているように見えます（これが元のboot2docker原因docker-machineによって作成/維持されているように見えるので、問題があるのではないかと思います。 docker / machine＃1335とdocker / machine＃1767が見つかりました。これらは関連している可能性がありますが、どちらも直接的ではないようです。

FWIW、MacPortsからインストールされたOpenSSLとPython2.7でdocker-compose （ virtualenv pipを介してインストール）を使用しています。そのバージョンのOpenSSLは、この問題で特定された問題の影響を受けます（そして、 boot2dockerへの更新によって回避されました）。私にとって、この組み合わせはboot2docker 1.8.1+とVagrantで問題なく機能します（私のVagrantfileは、プロビジョニングの魔法を使ってboot2docker証明書をホストにコピーして戻します）：

% cat /.../Vagrantfile
...
         # See <http://tinyurl.com/nz4tgy6>
         boot2docker.vm.provision :shell, inline: "set -e ; while ! docker >/dev/null ps --quiet ; do echo 'Waiting for Docker to come alive so we can kill it...' ; sleep 1 ; done ; sudo /etc/init.d/docker stop ; sudo rm -f /var/lib/boot2docker/tls/*.pem ~docker/.docker/*.pem ; sudo /etc/init.d/docker restart ; while ! docker >/dev/null ps --quiet ; do echo 'Waiting for Docker to come alive again so we can steal its keys...' ; sleep 1 ; done ; echo 'It lives!' ; [ -z \"$( find ~docker/.docker -name '*.pem' 2>/dev/null )\" ] || cp -Rv ~docker/.docker/*.pem '/vagrant/certs" , privileged: true
...
% env | grep DOCKER
DOCKER_HOST=tcp://w.x.y.z:2376
DOCKER_TLS_VERIFY=1
DOCKER_CERT_PATH=/.../certs
% ls "${DOCKER_CERT_PATH}"
ca.pem
cert.pem
key.pem
% openssl x509 -in "${DOCKER_CERT_PATH}/cert.pem" -text
...
        Issuer: O=Boot2DockerCA
...
        Subject: O=Boot2Docker
...
% openssl x509 -in "${DOCKER_CERT_PATH}/ca.pem" -text
...
        Subject: O=Boot2DockerCA
...
% virtualenv --python=python2.7 .../venv
...
% .../venv/bin/pip install docker-compose
...
% .../venv/bin/docker-compose --verbose version
docker-compose version: 1.4.1
docker-py version: 1.4.0
CPython version: 2.7.10
OpenSSL version: OpenSSL 1.0.2d 9 Jul 2015
% .../venv/bin/docker-compose ps
Name   Command   State   Ports
------------------------------

私はあなたがそのオプションを持っていないかもしれないことを理解しています。問題の診断に役立つ可能性のある違いを明らかにするために投稿しています。上記をdocker-machine作成した証明書と比較してください。

+-zsh:39> openssl x509 -in /.../.docker/machine/machines/shiny-new-machine-74d5a19e/cert.pem -text
...
        Issuer: O=PavelPolyakov
...
        Subject: O=PavelPolyakov
...
+-zsh:40> openssl x509 -in /.../.docker/machine/machines/shiny-new-machine-74d5a19e/ca.pem -text
...
        Subject: O=PavelPolyakov
...

そのノートSubjectのca.pem同じであるSubjectのcert.pem 。

あなたの問題はdocker-compose問題ではないと思います。（ @aanand 、おそらくコメントできますか？）この問題が非常に雑然としているので、 docker / machineの新しい問題を提出することを検討してください。私はあなたの最初のコメントから始めて、これを参照します。

posita 2015年09月18日

docker / machineの新しい問題を提出することにした場合は、VMインスタンスの/var/log/docker.logまたは/var/log/boot2docker.logに何か面白いものがある場所を追加することを検討してください。たとえば、これを試してください。

ssh docker@[machine-instance] grep generate_cert /var/log/boot2docker.log

または：

docker-machine ssh grep generate_cert /var/log/boot2docker.log

posita 2015年09月18日

OSX el capitainでこれを取得し、

docker-machine version 0.4.1 (HEAD)
Docker version 1.8.2, build 0a8c2e3
docker-compose version: 1.4.2

dblooman 2015年09月29日

こんにちは@DaveBlooman 、

興味がありますが、brewを使用してPythonなどをインストールしていますか？またはその逆。
そして、 docker-compose build実行するときに正確なエラーがありますか？

PavelPolyakov 2015年09月29日

自作経由、Python 2.7.10

dblooman 2015年09月29日

だから間違いなくbrewために何かが起こります:(

PavelPolyakov 2015年09月29日

@ DaveBlooman 、 @PavelPolyakovの問題を再現

posita 2015年09月29日

私は同じ問題を抱えていましたが、それはおそらくネットワーク構成で何かを台無しにしていた別のアプリケーション（私の場合はAstrill）によってVPN接続が開いていたという事実によるものでした。これが同じ問題を抱えている他の誰かを助けることができることを願っています。

oirad 2015年10月25日

OSX10.9.5でエラーが発生する

/usr/local/Cellar/docker-compose/1.5.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Starting compose_maven_1
/usr/local/Cellar/docker-compose/1.5.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Starting compose_ssh_1
/usr/local/Cellar/docker-compose/1.5.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning

Python 2.7.10
docker-machineバージョン0.5.0
docker-composeバージョン：1.5.0

すべてHomebrew経由でインストールされます

anthonygreen 2015年11月07日

@anthonygreen 、それは実質的に異なる問題のように見えます。ここで説明しているものと同じエラーメッセージは表示されません。 Homebrewユーザーは、これとは関係のないかなりの数の問題を経験しているようです。新しい問題の提出を検討してください。

posita 2015年11月07日

この投稿全体を読んだわけではありませんが、Docker Toolbox1.9.1aを使用したOSXYosemiteの最近のセットアップで同じエラーが発生しました。

$ docker-machine --version
docker-machine version 0.5.1 (7e8e38e)
$ docker-compose --version
docker-compose version: 1.5.1
$ docker --version
Docker version 1.9.1, build a34a1d5

カスタムCURL_CA_BUNDLE環境変数セット（いくつかのカスタム内部証明書を含む）があり、 docker-compose実行する前にこの環境変数の設定を解除すると、 [SSL: CERTIFICATE_VERIFY_FAILED]エラーを乗り越えることができました。

$ (unset CURL_CA_BUNDLE; docker-compose up)
Starting ...

編集：おっと、ここにコメントすることを意味しますhttps://github.com/docker/machine/issues/1880

pmahoney 2015年11月25日

🎉1

@pmahoney 、残りの人に知らせてくれてありがとう！私はそれを推測することはなかったでしょう。参考までに、おそらく次のようなこともできます（サブシェルが必要ない場合）：

$ CURL_CA_BUNDLE= docker-compose up

posita 2015年11月26日

👍1

@posita env varを空の文字列に設定すると、警告が表示されます。

$TMPDIR/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html

SSLエラーは発生しませんが。

pmahoney 2015年11月26日

@pmahoney 、おもしろい。したがって、設定されているが空のCURL_CA_BUNDLEは、まったく設定されていない（おそらくデフォルトの場所に見える）のとは異なるセマンティクス（つまり、nullオーバーライド）を持っているように見えます。ドキュメントの動作でこれを見つけようとしましたが、成功しませんでした。私が見つけた最も近いものはこれでした。

posita 2015年11月26日

@neilsarkar私の問題はCharlesプロキシの実行でもありました！ありがとうございました！

pirelenito 2015年11月26日

なんてこった、私はテストしていた両方のマシンにカスタムCURL_CA_BUNDLEも持っています。

ありがとう

PavelPolyakov 2015年11月26日

私にとっては何もありません。CURL_CA_BUNDLE変数はありません:(
だから私はそれをまったく成功しない値に設定しようとしましたが、CURL_CA_BUNDLEを何も設定しない場合（CURL_CA_BUNDLE =）、 @ pmahoneyが言ったように警告があり、それは機能しますが、私の端末は警告メッセージによって完全に混乱します。
私にとってより良い解決策があることを願っています:)

CURL_CA_BUNDLE変数の適切な値がわかっている場合は、それを使用します:)

THX

herveDarritchon 2015年11月26日

webkit-patchでも同じ問題が発生しました。 SSL / TLSモジュールのssl.get_default_verify_paths()は、Python / OpenSSLがCA証明書ファイルを予期している場所を示しています。したがって、これをターミナルで実行すると、次のようになります。

python3 -c "import ssl; [print(i) for i in ssl.get_default_verify_paths()]"

SSL_CERT_FILEが設定されていない場合、PythonのSSLモジュールは/usr/local/ssl/cert.pem CA証明書ファイルを想定していることがわかります（OpenSSLを/usr/local/sslインストールした場合）。したがって、 SSL_CERT_FILEをルートCA証明書を含む証明書ファイルに設定するか、ルートCA証明書を含むファイルを/usr/local/ssl/cert.pemます。ルートCA証明書が必要な場合は、 curlをダウンロードし、ソースツリーでlib/mk-ca-bundle.plを実行すると、ca-bundle.crtファイルが生成されます。 SSL_CERT_FILE設定

libsystem-ethan 2016年01月03日

@grahamc問題を解決しましたか？私はあなたと同じような設定をしていますが、リモートDockerデーモンではうまく機能しますが、 docker-compose失敗します

私が得るエラーはERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

yun-wang 2016年01月15日

いいえ、残念ながら、リモートDockerホストを放棄する必要がありました:(

grahamc 2016年01月15日

CURL_CA_BUNDLEが原因でdocker-composeが失敗するというこの問題が発生しました：

ERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

dockerは正常に機能していました。 docker-composeに環境変数を無視させるか、少なくとも期待される証明書を使用しないという警告をログに記録することをお勧めします。

buckett 2016年03月07日

👍1

@buckett 、機能リクエストとして追加するために新しい問題を提出することを検討してください。 docker-py姉妹号を提出し、お互いに参照してもらうことも検討してください。どのレイヤーが最も適切かわかりません。

posita 2016年03月07日

編集：新しい問題＃3114を作成しました

robertd 2016年03月12日

誰もがこれを修正しましたか？それでも同じエラーが発生します。私のdocker-compose versionは次のとおりです。

docker-compose version 1.6.2, build 4d72027
docker-py version: 1.7.2
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1j 15 Oct 2014

これは私がdocker-compose --verbose buildから得たものです：

compose.config.config.find: Using configuration files: ./docker-compose.yml
docker.auth.auth.load_config: File doesn't exist
Traceback (most recent call last):
  File "<string>", line 3, in <module>
  File "compose/cli/main.py", line 56, in main
  File "compose/cli/docopt_command.py", line 23, in sys_dispatch
  File "compose/cli/docopt_command.py", line 26, in dispatch
  File "compose/cli/main.py", line 189, in perform_command
  File "compose/cli/command.py", line 52, in project_from_options
  File "compose/cli/command.py", line 85, in get_project
  File "compose/cli/command.py", line 68, in get_client
  File "site-packages/docker/api/daemon.py", line 78, in version
  File "site-packages/docker/utils/decorators.py", line 47, in inner
  File "site-packages/docker/client.py", line 112, in _get
  File "site-packages/requests/sessions.py", line 477, in get
  File "site-packages/requests/sessions.py", line 465, in request
  File "site-packages/requests/sessions.py", line 573, in send
  File "site-packages/requests/adapters.py", line 431, in send
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

Dockerのツールボックスを介してdocker、docker-mahine、docker-composeをインストールしました。

上記の提案をすべて試しましたが、うまくいきませんでした。私はdockerの経験がないので、自分でそれを理解することができませんでした。

tranvictor 2016年03月23日

誰かがこれに関する根本的な原因または回避策を持っていますか？新しいopensslバージョンを使用したcompose1.7.0で表示されています。
これはすべて高山から構築および実行されるため、環境は純粋である必要があります。

/usr/src/app # env | sed 's/DOCKER_HOST=.*/DOCKER_HOST=#redacted/' && docker version && docker ps && docker-compose version && docker-compose pull
HOSTNAME=aebfe81b5938
SHLVL=1
PYTHON_PIP_VERSION=8.1.1
HOME=/root
GPG_KEY=97FC712E4C024BBEA48A61ED3A5CA953F73C700D
DOCKER_TLS_VERIFY=1
TERM=xterm
DOCKER_CERT_PATH=/certs
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG=C.UTF-8
PYTHON_VERSION=3.5.1
DOCKER_HOST=#redacted
PWD=/usr/src/app
Client:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Thu Mar 10 21:49:11 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.3
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   20f81dd
 Built:        Thu Mar 10 15:39:25 2016
 OS/Arch:      linux/amd64
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
docker-compose version 1.7.0, build 0d7bf73
docker-py version: 1.8.0
CPython version: 3.5.1
OpenSSL version: OpenSSL 1.0.2g  1 Mar 2016
Pulling registry (registry:2)...
ERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:645)

jmmills 2016年04月13日

@jmmills
私の場合、それは再定義されたCURL_CA_BUNDLE env変数が原因

PavelPolyakov 2016年04月13日

@PavelPolyakovは私の環境ダンプをチェックします... CURL_CA_BUNDLEはありません

jmmills 2016年04月13日

@PavelPolyakovわかりました、これは奇妙です。私はそのenv変数の設定を明示的に解除しましたが、私の環境にいなくても機能しました。

jmmills 2016年04月13日

@jmmillsハァッ…ここも同じ。たぶん、Pythonはset-as-emptyをunsetとは異なる方法で扱いますか？

Mac OS、自作のdocker-composeおよびdocker-machine、システムpythonを使用。新しく作成されたマシン： docker-machine create --driver=vmwarefusion --vmwarefusion-memory-size 1536 dev

env | grep CURLは何も返しません
docker-compose psは戻ります

エラー：SSLエラー：ホスト名「172.16.129.133」が「localhost」と一致しません

CURL_CA_BUNDLE='' docker-compose psは以下を返します：

/usr/local/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
/usr/local/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
Name   Command   State   Ports 
------------------------------

inanimatt 2016年04月18日

私はまったく同じものを持っていました- CURL_CA_BUNDLEは私の環境に設定されていませんでした、そしてそれを空の文字列に設定すると@inanimattと同じ出力が得られました。

alexwilson 2016年04月24日

それは間違いなくアップストリームのバグのようなにおいがします。私の推測では、curlの環境互換性コードで、「定義済み」と「空」の処理が異なります。

ありがとう、
ジェイソンミルズ

携帯から送られました。

2016年4月24日には、6:14で、アレックス・ウィルソン[email protected]は書きました：
まったく同じです-CURL_CA_BUNDLEが環境に設定されておらず、空の文字列に設定すると、@ inanimattと同じ出力が得られました。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください

jmmills 2016年04月24日

自作バージョンにのみ影響するようです-自作Pythonをインストールしてからdocker-composeをpip経由でインストールすると、すべてのエラーが解決されます。

2016年4月24日には、午前14時14で、アレックス・ウィルソン[email protected]は書きました：
まったく同じです-CURL_CA_BUNDLEが環境に設定されておらず、空の文字列に設定すると、@ inanimattと同じ出力が得られました。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください

inanimatt 2016年04月24日

👍1

以前にLinuxで問題の複製を貼り付けたと思います。明日はワークステーションで再確認できます

ありがとう、
ジェイソンミルズ

携帯から送られました。

2016年4月24日には、12：22 PMで、マット・ロビンソン[email protected]は書きました：
自作バージョンにのみ影響するようです-自作Pythonをインストールしてからdocker-composeをpip経由でインストールすると、すべてのエラーが解決されます。
2016年4月24日には、午前14時14で、アレックス・ウィルソン[email protected]は書きました：
まったく同じです-CURL_CA_BUNDLEが環境に設定されておらず、空の文字列に設定すると、@ inanimattと同じ出力が得られました。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください

jmmills 2016年04月24日

docker-composeをbrewを使用してバージョン1.7に更新したので、ここでも同じ問題が発生します。

$ docker-compose ps
ERROR: SSL error: hostname '192.168.99.100' doesn't match 'localhost'

$ docker-compose version
docker-compose version 1.7.0, build unknown
docker-py version: 1.8.0
CPython version: 2.7.10
OpenSSL version: OpenSSL 0.9.8zh 14 Jan 2016

CURL_CA_BUNDLE env varの種類を空にすると、問題が解決します。

CURL_CA_BUNDLE= docker-compose ps
/opt/boxen/homebrew/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
/opt/boxen/homebrew/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
/opt/boxen/homebrew/Cellar/docker-compose/1.7.0/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
   Name                 Command               State    Ports
------------------------------------------------------------

1.6.2にダウングレードすると、問題も解決します。

$ brew switch docker-compose 1.6.2
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.4.2
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.5.1
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.5.2
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.6.0
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.6.2
Cleaning /opt/boxen/homebrew/Cellar/docker-compose/1.7.0
3 links created for /opt/boxen/homebrew/Cellar/docker-compose/1.6.2

$ docker-compose ps
   Name                 Command               State    Ports
------------------------------------------------------------

nanoz 2016年04月26日

CURL_CA_BUNDLEを無効にするのではなく、次を使用して実行できます。
CURL_CA_BUNDLE =〜/ .docker / machine / machine / default / ca.pem docker-compose ps

aboutlo 2016年05月08日

👍1

私はおそらくこれを提起した最初の人ではありませんが、curl環境変数が無関係のPythonアプリケーションに影響を与えることは直感に反しませんか？

ありがとう、
ジェイソンミルズ

携帯から送られました。

2016年5月7日には、15:22で、ロレンツォ・シチリアの[email protected]は書きました：
CURL_CA_BUNDLEを無効にするのではなく、次を使用して実行できます。
CURL_CA_BUNDLE =〜/ .docker / machine / machine / default / ca.pem docker-compose ps
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください

jmmills 2016年05月08日

👍3

私はこの問題に遭遇しました、そして、問題は自己署名証明書のためのカスタムの場所を指している環境変数REQUESTS_CA_BUNDLEにありました。これが誰にでも役立つケース。

Michael Housh

m-housh 2016年05月09日

👍1

@aboutloこれは機能します-他のca.pemファイルでは機能せず、このファイルでのみ機能しました。私もWindowsを使用しているので、よりブードゥー構成になっています。ありがとうございます。

iongion 2016年06月14日

ndg-httpsclient（pipを使用-バージョン0.4.0）をアンインストールすると、問題が解決しました。こちらの投稿を参照してください： https ：

boxsterman 2016年07月21日

👍1

docker-composeとdocker-pyをデバッグし、コマンドで環境変数またはオプションを使用する必要があることを理解しました。これらを混ぜないでください。コマンドで--tlsを指定する場合でも、すべてのオプションをTLSConfigオブジェクトとして指定する必要があります。これは、TLSConfigオブジェクトがコマンドオプションから完全に作成され、環境変数から作成されたTFSConfigオブジェクトを操作するためです。

jitekuma 2017年03月08日

@ m-housh OMGそのヒントをありがとう！まったく同じことが私にも起こりました！私の環境からREQUESTS_CA_BUNDLEを削除し、この問題を解決しました。

AndreLouisCaron 2017年03月22日

私は同じ問題に遭遇しました。まず、OpenSSLのバージョンの違い（Pyhtonには1.0.2、OSには0.9.8）があったためですが、両方を1.0.2にしましたが、それでも機能しませんでした。
DockerにSSHで接続し、承認されたキーで証明書を確認して更新するだけで、問題を解決しました。興味深いことに、そこには間違った証明書がありました。

次の手順に従ってください：

boot2docker ssh
docker<strong i="10">@boot2docker</strong>:~$ cat .ssh/authorized_keys

この証明書が本当にコンピュータからの証明書であるかどうかを確認してください。それ以外の場合は、このファイルにコピーして保存してください。次に、実行します。

docker-compose up

これは私にとってはうまくいき、それが役立つことを願っています。

mesutayata 2017年04月25日

問題のグルーミング：ここで説明するさまざまな障害モードとユーザーエラー/構成ミスのシナリオ（すべて主に歴史的）があるようです。

作曲で進行中のアクティブな問題を指しているように見えるものは何も見当たらないので、問題を閉じます。最新バージョンで関連するエラーが引き続き表示される場合

ijc 2019年03月26日

Compose: SSLエラー：[SSL：CERTIFICATE_VERIFY_FAILED]証明書の検証に失敗しました

最も参考になるコメント

全てのコメント182件

1474は2つの異なることを行います：

`0.9.8zd`は元の`generate_cert` （0.1）で動作します

`1.0.2d` （MacPorts経由でインストール）は元の`generate_cert` （0.1）では機能しません

`0.9.8zd`はハッキングされた`generate_cert` （0.1.1;驚くことではありません）

`1.0.2d` _works（！）_：tada ：： see_no_evil ：： hear_no_evil ：： speak_no_evil：ハッキングされた`generate_cert` （0.1.1）

警告

`0.9.8zd` 、更新されたOpenSSLで`generate_cert` （0.1.2）と連携します

`1.0.2d` （MacPorts経由でインストール）は、更新されたOpenSSLを使用した`generate_cert` （0.1.2）では機能しません

関連する問題

Compose: SSLエラー：[SSL：CERTIFICATE_VERIFY_FAILED]証明書の検証に失敗しました

最も参考になるコメント

全てのコメント182件

1474は2つの異なることを行います：

0.9.8zdは元のgenerate_cert （0.1）で動作します

1.0.2d （MacPorts経由でインストール）は元のgenerate_cert （0.1）では機能しません

0.9.8zdはハッキングされたgenerate_cert （0.1.1;驚くことではありません）

1.0.2d _works（！）_：tada ：： see_no_evil ：： hear_no_evil ：： speak_no_evil：ハッキングされたgenerate_cert （0.1.1）

警告

0.9.8zd 、更新されたOpenSSLでgenerate_cert （0.1.2）と連携します

1.0.2d （MacPorts経由でインストール）は、更新されたOpenSSLを使用したgenerate_cert （0.1.2）では機能しません

関連する問題

`0.9.8zd`は元の`generate_cert` （0.1）で動作します

`1.0.2d` （MacPorts経由でインストール）は元の`generate_cert` （0.1）では機能しません

`0.9.8zd`はハッキングされた`generate_cert` （0.1.1;驚くことではありません）

`1.0.2d` _works（！）_：tada ：： see_no_evil ：： hear_no_evil ：： speak_no_evil：ハッキングされた`generate_cert` （0.1.1）

`0.9.8zd` 、更新されたOpenSSLで`generate_cert` （0.1.2）と連携します

`1.0.2d` （MacPorts経由でインストール）は、更新されたOpenSSLを使用した`generate_cert` （0.1.2）では機能しません