Acho que estou passando pela mesma coisa ao tentar usar o docker-compose release candidate ...

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

Mas fig funciona bem ...

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

Estou no OSX, executando todas as mesmas versões que @gkostyanikov , exceto que minha versão do cliente Go é go1.3.3 . Meu python / openssl também é instalado via Homebrew. Pode ter algo a ver com isso?

Editar: Na verdade, parece que o Homebrew não vincula o openssl, então estou usando a versão OSX padrão: OpenSSL 0.9.8za 5 Jun 2014 .

O problema era o Homebrew python.

docker-compose agora funciona após desinstalar o homebrew python / openssl, instalando pip com easy_install e reinstalando docker-composer usando o sistema python.

@adambiggs Sua solução funciona! Obrigado!

Isso funcionou para mim também, estou usando um mac novo e configurando-o com o homebrew python. Tive esse erro com o fig comunicando-se com o docker. Segui o conselho superei meu bloqueador, poderia ser um problema de versão do python também, mas, independentemente, acho que esta máquina usará o sistema python por um tempo.

Isso está acontecendo comigo também. E eu não quero usar o python do sistema, alguém tem outra solução alternativa?

Você já tentou usar o binário? Você tem o mesmo problema?

Não, eu não tentei o binário.
Se você não deseja instalá-lo em seus sistemas python, outra solução alternativa é usar o virtualenv (wrapper).

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

Encontrou uma solução melhor usando pyenv para reverter para o python 2.7.8:

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

Edit: Nevermind, pyenv introduziu um monte de seus próprios problemas ...

O que causou esse erro para mim foi que o opensl caseiro não estava vinculado a / usr / local / bin / openssl.

openssl version

retornou OpenSSL 0.9.8zc 15 de outubro de 2014 não OpenSSL 1.0.1j 15 de outubro de 2014

Corrida

brew link --force openssl

e reinstalar o fig resolveu o problema.

Interessante, no entanto, minha versão do OpenSSL é

@aanand no meu caso o binário não tem esse problema.

Recebi este erro quando instalei o fig por meio do pip, não do homebrew. sudo pip uninstall fig e brew install fig consertaram para mim.

+1 para a solução @NotBobTheBuilder , também funcionou para mim

: +1: para @NotBobTheBuilder

@NotBobTheBuilder é uma boa solução para fig, mas docker-compose ainda não está disponível no homebrew.

@ocasta, e esse aviso assustador do homebrew sobre a vinculação do OpenSSL?

Esta fórmula é apenas para barris.
O Mac OS X já fornece este software e instalando outra versão em
paralelo pode causar todos os tipos de problemas.

A Apple suspendeu o uso de OpenSSL em favor de suas próprias bibliotecas TLS e criptográficas

Perfeito @NotBobTheBuilder - Isso também resolveu.

alguém sabe a origem desse problema? está acontecendo comigo com figo. Eu prefiro ficar com pip install fig como faço agora. Tudo funcionou bem algumas semanas atrás, não sei o que mudou no meu sistema

Meu sistema OpenSSL é OpenSSL 0.9.8zc 15 Oct 2014 , meu homebrew openssl é mais recente, mas não vinculado.

... Acho que quebrou quando atualizei para o Python 2.7.9, parece que há alguns bugs relacionados ao SSL com ele ... é muito parecido com isto:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196431
http://bugs.python.org/issue23052

executar brew link --force openssl e reinstalar o fig não fez nada para mim.

O fig precisa ser atualizado para contornar as alterações de SSL em Py 2.7.9?
https://www.python.org/dev/peps/pep-0476/#opting -out

Estou usando boot2docker. Acabei de atualizar para 1.5.0, mas nenhuma alteração.

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}

O código do fig parece correto, ele está tentando usar os certificados instalados pelo boot2docker ... Presumo que esses certificados estejam ok porque sempre funcionaram e eu acabei de atualizar o b2d, então eles não deveriam ter expirado.

Hmm, meu Python (instalado via homebrew) parece estar usando a versão homebrew do 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

... executar /usr/local/opt/openssl/bin/c_rehash não ajudou :)

Tentei uma versão previamente instalada do python (2.7.8_2) via $ brew switch python 2.7.8_2 com o mesmo problema (mesmo que a mensagem de erro fosse um pouco diferente). Portanto, a versão Python 2.7.9 parece não ser o problema.

Então tentei mudar para uma versão mais antiga do openssl, de 1.0.2 para 1.0.1j_1, que parece funcionar.

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

Para mim, recebo apenas um erro diferente, mas talvez ajude a identificar o que está errado:

$ 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'

Voltar para o OpenSSL 1.0.2 produz o erro CERTIFICATE_VERIFY_FAILED portanto, alterar as versões definitivamente tem algum efeito

Uma solução alternativa é executar docker-compose em um contêiner:

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##*/}"'

Isso requer a exposição da porta 2376 no VirtualBox:

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

A resposta de @kretz funcionou para mim.

+1 @kretz brew switch openssl 1.0.1j_1
fez o truque

brew switch openssl 1.0.1j funciona para mim (observe a falta de _1)

Eu não gosto disso, mas desinstalar o fig do meu virtualenv e instalar via homebrew consertou as coisas para mim

Obrigado @kretz - sua resposta resolveu para mim!

Não funciona para mim porque:

$ 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

Minha solução alternativa foi criar um virtualenv com python 2.7.8, em vez do 2.7.9 que obtive da fermentação.

várias soluções alternativas ... alguém tem uma visão do problema real?

o que o App Engine tem a ver com alguma coisa?

Em 11 de março de 2015 às 18h09, Ryan Small [email protected] escreveu:

Tenho certeza de que nenhuma das coisas do app engine funciona com o python 2.7.9

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/compose/issues/890#issuecomment -78329652.

@anentropic Você precisa instalar a versão anterior do openssl antes de poder usá-lo (alternar para).

# 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

Eu fiz brew install openssl101 mas isso não me deu a possibilidade de mudar para 1.0.1j ... ele me deu um 1.0.1l e eu me preocupei que iria confundir meu sistema desde eles são pacotes de cerveja separados e eu já tinha 1.0.2 em paralelo

não pareceu ajudar, mas talvez eu não tenha ido longe o suficiente com isso

Desculpe, eu respondi ao problema do github errado (rapidamente excluí meu comentário)
Na quarta-feira, 11 de março de 2015 às 11:30 anentropic [email protected]
escrevi:

Eu fiz o brew install openssl101, mas não me deu a possibilidade de
mudar para 1.0.1j ... me deu um 1.0.1l e me preocupei que fosse
confundir meu sistema, uma vez que são pacotes de cerveja separados e eu já tinha
1.0.2 em paralelo

não pareceu ajudar, mas talvez eu não tenha ido longe o suficiente com isso

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/compose/issues/890#issuecomment -78340580.

Parece que também estou tendo esse problema, rodando no Mac OSX. Usando docker-compose, este é meu arquivo .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

Ao executar docker-compose pull obtenho a seguinte saída que falhou.

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

Algumas coisas eu verifiquei.
which openssl; openssl version

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

@psykzz Deve funcionar se você instalar com brew

brew install docker-compose

@arvindtest o que o faz pensar que está relacionado a esse problema?

Para sua informação, depois de lutar muito com isso, parece que este é um problema do boot2docker.
O que funcionou para mim foi desativar o TLS. Ainda não existe uma maneira amigável de fazer isso, mas as instruções são descritas aqui:
https://github.com/deis/deis/issues/2230

Basicamente, você precisa:

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

em seguida, reinicie o boot2docker, ou seja,
parada boot2docker
boot2docker start

e algo parecido com o seu ~ / .bashrc (certifique-se de que o ip está correto)

export DOCKER_HOST = tcp: //192.168.59.103 : 2375
não definir DOCKER_CERT_PATH
cancelar DOCKER_TLS_VERIFY

Em seu bashrc por que não ter apenas $ (boot2docker shellinit)

Deve ajudar com tudo certo?

Quer dizer, você ainda precisa fazer a solução TLS.
Em 21 de março de 2015 23:05, "coderfi" [email protected] escreveu:

Para sua informação, depois de lutar muito com isso, parece que este é um
problema do boot2docker.
O que funcionou para mim foi desativar o TLS. Ainda não existe uma maneira amigável
para fazer isso, mas as instruções são descritas aqui:
deis / deis # 2230 https://github.com/deis/deis/issues/2230

Basicamente, você precisa:

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

em seguida, reinicie o boot2docker, ou seja,
parada boot2docker
boot2docker start

e algo assim para o seu ~ / .bashrc
certifique-se de que o ip está correto

export DOCKER_HOST = tcp: //192.168.59.103 : 2375
não definir DOCKER_CERT_PATH
cancelar DOCKER_TLS_VERIFY

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/compose/issues/890#issuecomment -84468058.

@kretz isso funciona! obrigado.

@psykzz , você quer dizer $(boot2docker shellinit) ?

sim, atualizei meu comentário. derp.

Posso confirmar que a solução de @coderfi para desativar o TLS funciona para mim!

Ainda bem que funciona para você. :)

@Matt sim, você está correto sobre a dica de expansão shell init shell.
No entanto, isso pode não funcionar se o boot2docker ainda não tiver iniciado, então eu apenas
tornou o exemplo explícito.

Fi
Em 26 de março de 2015, 10h18, "anentropic" [email protected] escreveu:

Posso confirmar que a solução de @coderfi https://github.com/coderfi para
desabilitar TLS funciona para mim!

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/compose/issues/890#issuecomment -86630313.

Talvez isso seja óbvio, mas aqueles que desabilitam o TLS ou fazem o downgrade do OpenSSL apenas para fazer isso funcionar devem ter cuidado, dependendo do que estão fazendo.

Isso não se aplica a todos, mas eu tive um erro semelhante durante as instalações de pip usando um Dockerfile puxando de gliderlabs/alpine:3.1 - o contêiner Linux mínimo de progrium & crew. O problema é que eu não instalei o pacote de certificados do sistema. O problema foi resolvido instalando o pacote antes de instalar pip e executando o arquivo de requisitos:

RUN apk-install -X ca-certificates

As soluções sugeridas realmente não funcionaram para mim. Não foi possível mudar para nenhuma das versões 1.0.1 OpenSSL. No final, descobri que desinstalar todas as versões do docker-compose instaladas pelo pip e apenas fazer brew install docker-compose funciona de alguma forma.

As soluções acima funcionaram, mas foram muito complicadas para mim. Um rápido boot2docker upgrade consertou tudo do meu lado.

Já tenho a última versão do boot2docker e não funciona para mim sem as correções acima

Os desenvolvedores homebrew sugerem que docker-py e docker-compose devem ser atualizados para usar requests 2.6.0

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

Espero que isso ajude alguém ... não tenho certeza de uma solução, mas se você estiver usando Charles como um proxy do Mac OS X, isso vai causar esta mensagem.

FWIW, instalar docker-compose via pip fez o próprio docker-compose funcionar (instalar por meio de curl no OS X Mavericks resultou em um erro illegal operation ). Posteriormente, eu também estava recebendo o erro SSL. A execução de brew link --force openssl && brew switch openssl 1.0.1j parece ter corrigido isso para mim.

@rseymour sua resposta funcionou para mim

Para aqueles que não conseguem encontrar openssl-1.0.1j na bebida - você pode pegar uma versão mais antiga da receita do openssl no repositório github e usá-la:

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

Tentei 1.0.1m, mas não funcionou.
Então tentei o jeito @lazyval , funciona para mim
Isso é o que eu fiz.

brew install https://raw.githubusercontent.com/Homebrew/homebrew/62fc2a1a65e83ba9dbb30b2e0a2b7355831c714b/Library/Formula/openssl.rb
brew switch openssl 1.0.1j_1
brew unlink openssl101 // Porque eu vinculei 1.0.1m antes disso
brew link openssl --force
docker-compose ps

Obrigado!!

Atualmente estou investigando isso, pois agora precisamos construir os binários no Python 2.7.9+.

_Relocalizado de # 1427_

Servidor:

• CoreOS Stable
• Docker 1.5.0

Cliente:

• CentOS 6.6, 64 bits
• kernel 2.6.32-042stab105.14
• Cliente Docker 1.5.0
• docker-compose 1.2.0
• Certificados SSL colocados em ~/.docker/{ca.pem,cert.pem,key.pem}
• DOCKER_HOST=tcp://docker-builder:2376
• DOCKER_TLS_VERIFY=1

Usando o seguinte Makefile para construir os certificados 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

Aqui está o script de dados do usuário (reconhecidamente menos do que ideal) para provisionar esta máquina:

#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

Usando o cliente docker tive sucesso ao acessar o servidor docker remoto. Chamamos o servidor remoto até cem mil vezes por dia com bom êxito.

Tentando usar docker-compose , instalado via curl OU pip install --upgrade com python 2.7, obtemos um erro SSL:

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

Este é o caso após especificar manualmente DOCKER_CERT_PATH=/home/user/.docker/ , bem como REQUESTS_CA_BUNDLE=/home/user/.docker/ca.pem , individualmente e juntos.

Para ser claro: esta configuração funciona muito bem apenas com o daemon do docker, mas algo sobre -compose está errado.

Algumas notas:

1. O binário Compose 1.3.0 RC1 para OSX tem esse bug. Provavelmente não por coincidência, esta é a primeira vez que ele foi construído com o Python 2.7.9 - antes, era 2.7.6.
2. Estranhamente, posso reproduzir em uma VM boot2docker, mas não em uma VM Virtualbox fornecida pela Máquina. @ehazlett , @nathanleclaire , @tianon - algum insight?
3. Para qualquer pessoa que tiver isso quando o Compose for instalado com o Pip, relate a saída dos seguintes comandos:

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

Em minha máquina local, onde posso reproduzir o erro, tenho Python 2.7.10 e OpenSSL 1.0.2a 19 Mar 2015 .

1. Isso foi relatado ao Homebrew, e algumas pessoas dizem que tiveram sucesso ao reinstalar o Python e o OpenSSL, mas não funcionou para mim. https://github.com/Homebrew/homebrew/issues/38226

Hmm, isso é muito estranho. Qual versão do b2d você está usando vs. a versão
da máquina? Nós dois usamos b2d, então não tenho certeza do que seria diferente
além da versão.

Vou instalar via pip na minha máquina OS X e ver o que obtenho.

Na quinta-feira, 28 de maio de 2015 às 9h19, Aanand Prasad [email protected]
escrevi:

Algumas notas:

1

O binário Compose 1.3.0 RC1 para OSX tem esse bug. Provavelmente não
coincidentemente, esta é a primeira vez que ele foi construído com o Python 2.7.9

• antes, era 2.7.6.
  2

Estranhamente, posso reproduzir em uma VM boot2docker, mas não em uma
Virtualbox VM provisionado pela máquina. @ehazlett
https://github.com/ehazlett , @nathanleclaire
https://github.com/nathanleclaire , @tianon
https://github.com/tianon - alguma ideia lá?
3 -

Para qualquer pessoa que experimente isso quando o Compose for instalado com o Pip, por favor
relatar a saída dos seguintes comandos:

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

Na minha máquina local, onde posso reproduzir o erro, tenho Python
2.7.10 e OpenSSL 1.0.2a 19 de março de 2015.
4 -

Isso foi relatado ao Homebrew, e algumas pessoas dizem que tiveram
sucesso reinstalando Python e OpenSSL, mas não funcionou para mim.
Homebrew / homebrew # 38226
https://github.com/Homebrew/homebrew/issues/38226

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/compose/issues/890#issuecomment -106306690.

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

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

Há algo diferente na geração de certificados, talvez? Parece que tenho mais arquivos no diretório cert da minha máquina do que no 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

Está bem. O cliente usará apenas ca.pem, cert.pem e key.pem
(o servidor é apenas uma cópia local do host na máquina). Vou criar como
bem e inspecione os certificados para ver qual pode ser a diferença.

Em quinta-feira, 28 de maio de 2015 às 9h30, Aanand Prasad [email protected]
escrevi:

versão $ boot2docker
Versão Boot2Docker-cli: v1.6.2
Git commit: cb2c3bc

$ docker-machine --version
docker-machine versão 0.2.0 (8b9eaf2)

Há algo diferente na geração de certificados, talvez? Parece que tenho mais
arquivos no meu diretório cert da máquina do que no meu boot2docker.

$ $ (boot2docker shellinit)
$ ls -l $ DOCKER_CERT_PATH / *. pem
-rw-r - r-- 1 aanand staff 1042 28 de maio 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
-rw-r - r-- 1 aanand staff 1070 28 de maio 14:27 /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
-rw-r - r-- 1 aanand staff 1675 28 de maio 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 de maio 12h15 /Users/aanand/.docker/machine/machines/dev/ca.pem
-rw-r - r-- 1 aanand staff 1054 11 de maio 12h15 /Users/aanand/.docker/machine/machines/dev/cert.pem
-rw-r - r-- 1 aanand staff 1679 11 de maio 12:15 /Users/aanand/.docker/machine/machines/dev/key.pem
-rw ------- 1 aanand staff 1679 11 de maio 12:15 /Users/aanand/.docker/machine/machines/dev/server-key.pem
-rw-r - r-- 1 aanand staff 1086 11 de maio 12h15 /Users/aanand/.docker/machine/machines/dev/server.pem

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/compose/issues/890#issuecomment -106309885.

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

Consulte também https://github.com/docker/docker-py/issues/465. O script de teste de @garethr reproduz o erro para mim também, após fazer uma modificação para desativar a verificação de nome de host:

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)

Ele ainda funciona com a VM provisionada por máquina, embora:

$ 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'}

Se eu reativar a verificação do nome do host (comentando a linha assert_hostname no script de teste), ele falhará com o mesmo erro na VM boot2docker-cli, mas um erro diferente na VM da máquina, que pode ou pode não ser relevante:

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

Além disso, tentei usar v1.3.0-rc1 via curl (a versão binária, não por meio de pip) e recebi o mesmo erro de antes em um daemon docker 1.6.2:

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

Sim - o binário RC1 foi construído com Python 2.7.9 e OpenSSL 1.0.2a, o que parece ser uma das combinações problemáticas.

Isso faz sentido porque acredito que a geração cert em b2d está na VM
enquanto a máquina os gera na máquina. Podemos detectar e adicionar o
nome da máquina para os SANs, se necessário. Na verdade, isso provavelmente seria bom
especialmente para VMs b2d. Acho que funciona agora porque você
acesse o mecanismo usando o IP que a máquina adiciona como IP SAN. Existe um
PR aberto para permitir SANs adicionais arbitrários que também funcionariam.

Na quinta-feira, 28 de maio de 2015, Aanand Prasad [email protected] escreveu:

Consulte também docker / docker-py # 465
https://github.com/docker/docker-py/issues/465. @garethr
https://github.com/garethr o script de teste reproduz o erro para
eu também, depois de fazer uma modificação para desativar a verificação de nome de host:

from docker.client import Clientfrom 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
Escrevendo /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
Escrevendo /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
Escrevendo /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem
Traceback (última chamada mais recente):
Arquivo "test.py", linha 8, em
print client.version ()
Arquivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", linha 1108, na versão
return self._result (self._get (url), json = True)
Arquivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", linha 106, em _get
return self.get (url, * _self._set_request_timeout (kwargs))
Arquivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", linha 477, em get
return self.request ('GET', url, * _kwargs)
Arquivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", linha 465, na solicitação
resp = self.send (prep, * _send_kwargs)
Arquivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", linha 573, em envio
r = adapter.send (request, * _kwargs)
Arquivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", linha 431, em envio
aumentar SSLError (e, solicitação = solicitação)
request.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] falha na verificação do certificado (_ssl.c: 590)

Ele ainda funciona com a VM provisionada por máquina, embora:

$ 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'}

Se eu reativar a verificação do nome do host (comentando o assert_hostname
linha no script de teste), ele falha com o _mesmo erro_ contra o
boot2docker-cli VM, mas um _erro diferente_ contra a máquina VM, que
pode ou não ser relevante:

Traceback (última chamada mais recente):
Arquivo "test.py", linha 8, em
print client.version ()
Arquivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", linha 1108, na versão
return self._result (self._get (url), json = True)
Arquivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", linha 106, em _get
return self.get (url, * _self._set_request_timeout (kwargs))
Arquivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", linha 477, em get
return self.request ('GET', url, * _kwargs)
Arquivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", linha 465, na solicitação
resp = self.send (prep, * _send_kwargs)
Arquivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", linha 573, em envio
r = adapter.send (request, * _kwargs)
Arquivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", linha 431, em envio
aumentar SSLError (e, solicitação = solicitação)
request.exceptions.SSLError: nenhum campo commonName ou subjectAltName apropriado foi encontrado

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/compose/issues/890#issuecomment -106363305.

OK, acredito que cheguei a uma correção para o OS X: https://github.com/docker/compose/pull/1474

Corrigir para Linux envolverá atualizar o Dockerfile para fixar no Python 2.7.9 e OpenSSL 1.0.1, o que será um esforço divertido, já que começa em debian:wheezy (o que acontece para garantir que estamos usando um glibc antigo - consulte https://github.com/docker/compose/pull/505).

Mudar para 1.0.1k conforme descrito no comentário de @kretz e instalar 1.3.0 RC1 via pip funcionou para mim.

Antes de trocar o python relatado 1.0.2a:

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

Depois de trocar, ele relatou 1.0.1k e docker-compose parece funcionar conforme o esperado:

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

uma solução que removeu este erro foi instalar os seguintes pacotes no meu virtualenv
pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7

No ambiente descrito em https://github.com/docker/compose/issues/890#issuecomment -106289821 que fornece Python 2.7.6 (via snap-ci.com, que você pode obter uma conta gratuita em)

com o seguinte script que usa a solução alternativa de @ jsh2134 em uma instalação pip (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

Recebo a seguinte saída:

+ 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')]

Observe especialmente o erro (que parece novo):

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

Criei https://github.com/docker/compose/issues/1484 para despejar minhas descobertas até agora.

Eu construí alguns binários com a correção em # 1474. Experimente-os se estiver enfrentando problemas de SSL:

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

+ 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)

@ jsh2134 por que exatamente você está fixando pyOpenSSL em 0,14?

+1 para @kretz resposta :)

+1 mesmo problema :( parece que o docker está completamente quebrado no osx?

A solução

Lidar com um dos erros variantes em uma VM Centos7, que atua como um cliente para iniciar contêineres em uma máquina docker:

[ root @ xxxx cm] # docker-compose ps
Erro SSL: nenhum campo commonName ou subjectAltName apropriado foi encontrado

Isso costumava ser transitório; Eu poderia fazer logout, ssh novamente e não ver o erro por um tempo. Agora vendo isso sempre.

[ root @ xxxx cm] # python -c 'import ssl; imprimir (ssl.OPENSSL_VERSION) '
OpenSSL 1.0.1e-fips 11 de fevereiro de 2013

[ root @ xxxx cm] # versão do docker
Versão do cliente: 1.6.2
Versão da API do cliente: 1.18
Versão Go (cliente): go1.4.2
Git commit (cliente): ba1f6c3 / 1.6.2
OS / Arch (cliente): linux / amd64
Versão do servidor: swarm / 0.2.0
Versão Go (servidor): go1.3.3
Git commit (servidor): 48fd993
OS / Arch (servidor): linux / amd64

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

Não tenho certeza de como aplicar algumas das correções observadas acima em meu ambiente. Não estou usando boot2docker; lidar com o docker 1.6.2 diretamente na linha de comando do bash.

Olá. Na verdade, eu abri um problema para essa causa e não consigo corrigi-lo. Eu tentei muitas coisas, por exemplo, instalar compose com versões pip / brew / newst. O mesmo que o openssl tentou as versões 0.x 1.0.2x etc e ainda não funciona.

PS: Eu não uso boot2docker. Eu tenho minha própria VM que faço via vagrant, gerei os certs e iniciei o daemon do docker com eles. Aparentemente, ele funciona com o docker, então o problema não vem dos meus certificados.

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

também recebi este erro uma vez:

/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

Depois de ler aqui e mexer na instalação dos pacotes sugeridos:

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

A mensagem de erro de docker-compose mudou:

[ root @ xxx cm] # docker-compose up -d
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:251: SecurityWarning: O certificado não tem subjectAltName , voltando para verificar se há commonName para agora. Este recurso está sendo removido pelos principais navegadores e descontinuado pelo RFC 2818. (Consulte https://github.com/shazow/urllib3/issues/497 para obter detalhes.)
Aviso de segurança
Erro SSL: nome do host 'xx.xx.xx.xx' não corresponde a Nenhum

(O quadrante pontilhado I xx'd out é do host mestre / docker do swarm).

Esse problema também pode ser resolvido editando ou gerando novamente o certificado?

Adendo: Os certificados foram criados nessas VMs por "docker-machine create."

Será que estamos lidando com um bug na docker-machine que resulta em um certificado insuficientemente detalhado?

Só estou vendo esse erro com hosts Docker criados por docker-machine. Eu acredito que os certificados SSL não estão sendo criados corretamente.

Alguém tem uma solução alternativa ou solução para consertar isso? Isso é um pouco bloqueador para mim agora: /

@prologic Você está recebendo o erro com o binário ou com um Compose instalado pelo Pip? Se for o último, tente instalar requests[security] também.

@aanand Obrigado! Vou tentar isso e relatar se funciona ou não!

@prologic Queremos empacotar requests[security] vez de depender do módulo SSL bugado do Python; estamos monitorando o esforço em # 1530.

@aanand Obrigado! Funcionou perfeitamente :)

@coderfi sua solução funcionou para mim, obrigado

@aanand a compilação de 2 de junho funciona bem para mim. boa sorte para esmagar esse bug doloroso.

@neilsarkar Por acaso eu estava executando o proxy charles, seu comentário me salvou. : +1:

Estou usando o OS X 10.9.5, esta é minha seleção:

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

Minha solução alternativa:

comente as linhas 246: 253 em
/usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connection.py

esta é a parte que está lançando a exceção de segurança

O problema para mim é que mesmo eu especificando brew link --force openssl, fig / docker-compose ainda usa / usr / bin / openssl.

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

Isso funcionou para mim. Agora eu não entendo mais a mensagem irritante.

Para sua informação, a receita do brew fig / docker-compose usa o sistema python, então mesmo se você instalar o python via pyenv ou brew, o brew install fig / docker-compose ainda usará o sistema openssl lib se disponível, caso contrário, ele instalará alguma outra versão.

No meu MAC no trabalho, resolvi com pyenv install 2.7.8, em seguida, easy_install pip e pip install docker-compose.

mas no meu mac em casa, "ambos executando o yosemite" fiz o mesmo e ainda recebo o aviso.

Vou continuar cavando.

@dtunes - a causa raiz (como @aanand mencionado acima) é https://github.com/boot2docker/boot2docker/issues/808. A coisa do system-python / homebrew-python é uma pista falsa, porque depende apenas se você está vinculado a um OpenSSL novo ou antigo.

Sim, eu vi aquele bilhete. O que está me incomodando é que no meu Mac no trabalho, depois de tentar as diferentes abordagens acima, nenhuma funcionou.
Então movi / usr / bin / openssl para / usr / bin / openssl_old, instalei o último openssl usando home brew e forcei o link. só então fiz o seguinte:

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

Isso funcionou no trabalho, mas no meu Mac em casa não funcionou. Mas vou tentar novamente, caso tenha cometido um erro, e informarei os resultados.

@dtunes - Para reconstruir todas as suas dependências, você precisa remover ~/Library/Caches/pip para que a roda binária em cache construída contra o OpenSSL errado não seja reutilizada.

@glyph escreveu :

a causa raiz (como @aanand referenciado acima) é boot2docker / boot2docker # 808. A coisa do system-python / homebrew-python é uma pista falsa, porque depende apenas se você está vinculado a um OpenSSL novo ou antigo.

@glyph ou @aanand , isso sugere que a correção de @aanand (solução @aanand , se boot2docker / boot2docker # 808 for endereçado adequadamente, o # 1474 deve ser restaurado? Ter esperança no próximo lançamento de criptografia (veja isto e isto ) também é uma pista falsa?

@aanand escreveu :

Observe que não posso reproduzir este erro em uma VM Boot2Docker provisionada com docker-machine - isso só acontece em uma VM provisionada com o comando boot2docker.

@ehazlett escreveu :

Isso faz sentido porque acredito que a geração de certificados em b2d está na VM, enquanto a máquina os gera na máquina.

Eu posso ter entendido mal, mas há muita conversa culpando várias combinações de Python / OpenSSL do lado do host por isso e por questões relacionadas. Se a origem do problema for um OpenSSL quebrado distribuído com b2d, não tenho certeza se a melhor abordagem é garantir que o OpenSSL do lado do host do Compose também seja danificado. Pelo que vale a pena, esses tipos de contorções do lado do host provavelmente não resolverão esse problema para aqueles que executam o b2d via (por exemplo) Vagrant e o acessam fora do Compose (consulte, por exemplo, docker / docker-py # 465 ).

Se este comentário for mais apropriado em boot2docker / boot2docker # 808, posso movê-lo para lá.

Sou um mantenedor do Homebrew e ajudei o glifo a controlar isso.

Os DNs de Assunto e Emissor do certificado do servidor gerado pelo boot2docker são definidos de forma idêntica como /O=Boot2Docker . Acredito que o certificado do servidor está realmente assinado pelo certificado CA, mas o AFAICT OpenSSL 1.0.2 usa essas informações (ou seja, DNs de assunto e emissor idênticos) para rejeitar o certificado do servidor como autoassinado em vez de tentar verificar o certificado do servidor em relação ao fornecido CA cert. As versões do OpenSSL anteriores a 1.0.2 validam o certificado do servidor em relação ao certificado CA fornecido, que é bem-sucedido.

Acredito, mas não testei, que dar ao servidor e aos certificados de CA DNs de Assunto distintos (de modo que o certificado do servidor tenha DNs de Assunto e Emissor distintos) permitirá que os certificados sejam validados em todas as versões do OpenSSL. Eu suspeito (com base na minha leitura deste guia de sobrevivência X.509, mas não em quaisquer especificações relacionadas), mas não tenho certeza, que o comportamento do OpenSSL 1.0.2 é razoável e não representa uma regressão que deve ser resolvida pelos desenvolvedores do OpenSSL.

1474 faz duas coisas distintas:

• definir uma versão mínima do Python em 2.7.9: isso permite que urllib3 conclua solicitações sem emitir um InsecurePlatformWarning, que é emitido ao fazer conexões HTTPS se as duas condições forem atendidas: a versão Python é anterior a 2.7.9 e o módulo PyOpenSSL não está presente. Agrupar PyOpenSSL seria igualmente eficaz, mas entendi da discussão que não é compatível com PyInstaller. De qualquer forma, o InsecurePlatformWarning do urllib3 não está relacionado ao problema do certificado boot2docker e corrigir os certificados não elimina a necessidade dessa solução alternativa.
• definir uma versão máxima do OpenSSL em 1.0.1j. Eu acredito que isso deve ser desnecessário depois que os certificados boot2docker forem corrigidos.

Se a fonte do problema for um OpenSSL quebrado distribuído com b2d

Não é; os certificados boot2docker (gerados por este código ) são inválidos de acordo com clientes que usam OpenSSL ≥ 1.0.2; a biblioteca OpenSSL distribuída com boot2docker não está envolvida.

@glyph ou @aanand , isso sugere que a correção de @aanand (solução @aanand , se boot2docker / boot2docker # 808 for endereçado adequadamente, o # 1474 deve ser restaurado? Ter esperança no próximo lançamento de criptografia (veja isto e isto) também é uma pista falsa?

Acho que sim. Acredito que o OpenSSL com o problema é 1.0.2 e, ao restringi-lo a 1.0.1, evitaria qualquer lógica de verificação que esteja causando a falha do certificado. Ainda não sei _o que_ há no certificado de que ele não gosta, já que as mensagens de erro são tão obtusas.

Além disso, acho que o que # 1474 está fazendo é específico demais; pelo menos da minha leitura, não está definindo uma versão _minimum_ do python, mas especificando uma versão _exata_. Ele também parece falhar na verificação de que você tem algum 1.0.1 diferente de j, o que significa que as atualizações de segurança não serão aplicadas nem mesmo ao 1.0.1, o que é _definitivamente_ um problema.

Acredito, mas não testei, que dar ao servidor e aos certificados de CA DNs de Assunto distintos (de modo que o certificado do servidor tenha DNs de Assunto e Emissor distintos) permitirá que os certificados sejam validados em todas as versões do OpenSSL. Eu suspeito (com base na minha leitura deste guia de sobrevivência X.509, mas não em quaisquer especificações relacionadas), mas não tenho certeza, que o comportamento do OpenSSL 1.0.2 é razoável e não representa uma regressão que deve ser resolvida pelos desenvolvedores do OpenSSL.

Vou investigar o certificado gerado por docker-machine e ver se ele tem essa propriedade. Por que você diz que esse comportamento seria aceitável / não uma regressão no OpenSSL? Confiar em um certificado autoassinado é perfeitamente aceitável e não há restrições específicas sobre o que o assunto ou emissor pode conter. Folheei um pouco esse guia e parece que estou apenas apontando que os certificados autoassinados não terão a confiança do cartel de CA, portanto, seu navegador não confiará neles sem configuração adicional.

Olhando para o certificado em minha docker-machine VM, vejo:

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

então você pode estar certo sobre isso ...

Vou investigar o certificado gerado pela máquina docker e ver se ele tem [DNs de Assunto e Emissor correspondentes].

Você pode ver que os certificados da máquina docker da aanand também têm DNs distintos: https://gist.github.com/aanand/3d865623481ba8ae66ee#file -docker-machine-log-L30-L32

Confiar em um certificado autoassinado é perfeitamente normal

Mas um certificado autoassinado não é válido a menos que você confie no certificado autoassinado. Não instruímos o OpenSSL a confiar no certificado do servidor; instruímos o OpenSSL a confiar na CA que emitiu o certificado do servidor.

Por que você diz que esse comportamento seria aceitável / não uma regressão no OpenSSL?

IANAL, mas meu raciocínio é derivado da linguagem "Em um nível estrito [autoassinatura] significa que o emissor e os campos de assunto no certificado são os mesmos." Esse é o caso do certificado do servidor boot2docker. Quando o OpenSSL tenta validar o certificado do servidor boot2docker, é possível construir uma cadeia de confiança completa sem considerar o certificado CA, uma vez que o certificado do servidor parece ser assinado por si mesmo, mas não é explicitamente confiável e, portanto, não pode ser válido. Não tenho certeza de que esse comportamento seja estritamente correto ou obrigatório e não estou qualificado para decidir, mas acho que parece "razoável".

Obrigado pela escavação, pessoal.

Além disso, acho que o que # 1474 está fazendo é específico demais; pelo menos pela minha leitura, não está definindo uma versão mínima do python, mas especificando uma versão exata. Ele também parece falhar na verificação de que você tem algum 1.0.1 diferente de j, o que significa que as atualizações de segurança não serão aplicadas mesmo ao 1.0.1, o que é definitivamente um problema.

Acordado. Supondo que seja o OpenSSL 1.0.2 que discorda dos certificados do boot2docker, essa parte deve pelo menos ser corrigível - vou procurar obter um OpenSSL 1.0.1 atualizado no.

@tdsmith , obrigado pela explicação e desculpas pelo mal-entendido. @glyph , obrigado pelo esclarecimento.

FWIW, eu tentei testar a teoria de @tdsmith e generate_cert (é feio, me perdoe) para criar valores distintos para Issuer e Subject . Ele _pode_ parecer conter água (mas veja as advertências abaixo). Aqui está o que eu obtenho ao executar o b2d com certificados gerados a partir da atual generate_cert versus minha versão hackeada:

0.9.8zd trabalha com orig 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 (instalado via MacPorts) _não_ funciona com orig 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 funciona com generate_cert hackeado (0.1.1; não é surpreendente)

% /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: com hackeado 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

Ressalvas

No interesse de tentar controlar todas as alterações, observe que quando o generate_cert (0.1) original foi lançado, ele foi criado quando a imagem golang:1.3-cross Docker usada para criá-lo tinha acesso a um pacote chamado ssh . Esse pacote foi substituído por openssh-client . A versão OpenSSL usada ao construir meu generate_cert hackeado é 1.0.1k . Isso parece estar estaticamente vinculado:

% 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)

Portanto, parece que uma de duas coisas pode estar acontecendo:

• As versões mais recentes do OpenSSL ficam confusas quando Issuer == Subject , como @tdsmith sugere; ou
• Há algo mais sobre a geração de certificados que mudou no OpenSSL, de forma que as versões posteriores do OpenSSL têm problemas para validar certificados gerados pelas anteriores

Uma maneira de testar isso é reconstruir generate_cert sem meu hack, mas com uma versão atualizada do OpenSSL. Eu farei isso a seguir.

Portanto, parece que @tdsmith está certo. Depois de voltar atrás em meu hack para garantir Issuer <> Subject , mas reconstruir generate_cert com a versão mais recente do OpenSSL de golang:1.3-cross , ele volta a falhar com versões posteriores do OpenSSL no lado do cliente:

0.9.8zd funciona com generate_cert (0.1.2) com OpenSSL atualizado

% /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 (instalado via MacPorts) _não_ funciona com generate_cert (0.1.2) com OpenSSL atualizado

% 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

Precisa de SvenDowideit / generate_cert # 10. A propósito, se alguém quiser construir imagens b2d que apontem para meus generate_cert s hackeados, você pode tentar até que uma correção oficial seja lançada.

Se bem entendi, isso _deve_ evitar a necessidade de jogar jogos da versão OpenSSL / Python no lado do cliente (pelo menos com relação a esse problema).

marcação de @SvenDowideit

Tive algumas idas e vindas com os caras do OpenSSL. Aqui está um resumo de Steve Henson:

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

Mudar a maneira como o b2d gera seus certificados para acomodar clientes OpenSSL com erros parece muito superior a aplicar patches e instalar o OpenSSL no lado do cliente. Não tenho certeza de qual abordagem específica é mais apropriada (tornando o assunto! = Emissor vs. incluindo SKID / ADID em todos os certificados). Vou passar esse dinheiro para @SvenDowideit. :sorriso pretensioso:

Para os curiosos (mais uma vez, não acho que devamos seguir esse caminho), aqui está o patch do OpenSSL de Steve:

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);

Histórico completo: http://rt.openssl.org/Ticket/History.html?user=guest&pass=guest&id=3979.

Espere ... _less_ estrito? Estou confuso como uma verificação _less_ estrita falha onde uma mais estrita passa?

Espere ... _less_ estrito? Estou confuso como uma verificação _less_ estrita falha onde uma mais estrita passa?

Sim, também tive problemas com essa escolha de idioma. Olhando para a diferença, eu acho que ele quis dizer incorretamente varrer mais certificados como autoassinados por não realizar tantas verificações (ou seja, menos estrito na determinação do que _não_ se qualifica como autoassinado). Mas você está certo. É uma frase estranha.

Não gastei muito tempo investigando as fontes OpenSSL, mas as considero bastante impenetráveis ​​em muitos lugares. Talvez seja necessária uma mentalidade "especial" para trabalhar nesse projeto. : sorriso:

Não gastei muito tempo investigando as fontes OpenSSL, mas as considero bastante impenetráveis ​​em muitos lugares. Talvez seja necessária uma mentalidade "especial" para trabalhar nesse projeto.

Um eufemismo, eu acho: wink:.

De qualquer forma, obrigado por entrar em contato com o pessoal da OpenSSL, fico feliz em saber que será resolvido ali. Enquanto isso, trabalhar com ele no b2d parece ser a coisa certa a fazer. Eu não acho que haja nada para escrever aqui, mas espere.

Conforme mencionado aqui , isso corrige as coisas para mim:

pip install requests[security]

@iffy Isso é uma

Para sua informação, PR com correção enviada como boot2docker / boot2docker # 1029.

A correção para isso (obrigado @posita!) Está disponível na versão mais recente do boot2docker. Para fazer upgrade:

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

Isso resolveu o problema para mim. Por favor, tente e relate de volta.

Alternativamente, mude para Docker Machine , que agora vem como padrão como parte da nova Docker Toolbox .

Ainda estou tendo esse problema ...

❯ 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 Sua chamada docker-compose está sendo bem-sucedida; o aviso que você está vendo é inofensivo. Você deve atualizar para o OS X 10.10.5 se preferir evitar vê-lo.

@tdsmith não é inofensivo para mim, deixando meu TOC louco: sorria: obrigado pela dica, irei atualizar agora.

Desinstalar a versão python instalada via brew resolveu esse problema para mim. brew remove --force python

Desinstalei a versão brew, mas ainda tenho Python 2.7.10 e ainda tenho o
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) erro.

Tenho a próxima configuração:

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
você resolveu seu problema?

O anybode sabe se os caras do docker-compose estão trabalhando para resolver o problema ou basicamente não é o problema deles?

Saudações,

@PavelPolyakov
não. em ambos os meus macs (10.9.xe 10.10.x), tentei várias coisas sem alterações. Eu não acho que isso seja uma coisa de docker-compose e mais do Python FWIW.

@chiefy
Eu concordo, mas não encontrei nenhuma variante de como fazê-lo funcionar :(

Parece que todo mundo já resolveu esse problema, mas eu não :)

Instalei o python usando o brew uma vez e acho que removi o do sistema, então não tenho a opção de voltar ao antigo.

Tentei instalar o docker por meio de várias variantes:

1. do binário (baixando a caixa de ferramentas do docker)
2. da própria cerveja

no entanto, ainda tenho:

alguém tem um guia completo de como superar esse comportamento?

Saudações,

@PavelPolyakov - O bug é que o boot2docker (e em alguns casos, eu acho, docker-machine) estava construindo alguns certificados que eram inutilizáveis ​​pelo suporte SSL do python. Se você atualizou todo o seu software, mas ainda tem os certificados antigos inválidos, as coisas ainda estarão danificadas. Portanto, neste ponto, eu recomendaria provisionar novamente quaisquer VMs de desenvolvimento que você tenha, com uma versão atual do docker-machine, para que novos certificados SSL sejam provisionados. Isso pode envolver mover de lado ~/.docker em seu host.

@PavelPolyakov e @chiefy , além do conselho de @glyph , você também pode tentar isso (se não quiser reprovisionar completamente seu ambiente 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] é específico para seu ambiente de VM. Pode haver métodos mais fáceis (por exemplo, vagrant ssh , se você estiver usando o Vagrant). Em seguida, reinicie sua instância boot2docker e veja se o erro SSL ainda ocorre.

@glyph

Obrigado pelo conselho, para mim não é um problema reprovisionar a docker-machine. No entanto, isso não ajuda.

Quando eu instalo o docker & co com:
brew install docker docker-machine docker-compose

Então, default máquina não é criada. E não tenho ideia de como criá-lo usando docker-machine create .

Quando eu instalo o docker-toolbelt usando o arquivo * .pkg, a máquina é criada, mas eu tenho um erro de SSL.
Eu até tentei fazer:

docker-machine regenerate-certs default

Mas isso não ajuda.

@posita
Obrigado pelo conselho também.
Em seu guia, você sugere mv ~/.docker ~/.docker-bak - por que motivo? Assim que fizermos isso, não poderemos iniciar a máquina novamente, porque os arquivos são movidos.
Sim, consigo fazer o login na máquina e remover tls/* , em seguida, desligá-la, mas como reiniciá-la?

Como reprovisionar do zero?

@todos
Qual é a sua maneira de instalar o docker (com docker-compose funcionando), é via brew install ou via toolbelt .pkg?
Como posso ter certeza de que os certificados, que estão em minha máquina docker são válidos e úteis por python, como posso atualizar o python e o openssl ainda mais do que o brew pode, etc?

Obrigado por ajudar.

Saudações,

@PavelPolyakov - docker-machine não tem a noção de uma máquina "padrão". Você pode executar docker-machine create --driver virtualbox my-docker-machine .

@PavelPolyakov Depois de fazer isso, você precisa fazer eval "$(docker-machine env my-docker-machine)" , ou o que você escolheu para chamar sua máquina de desenvolvimento local.

@glyph
Correto, essa era a parte que faltava em executar tudo de brew . Provisionei com sucesso uma máquina com o nome default (o mesmo que é feito durante a instalação a partir de * .pkg).

No entanto, como sempre, termino com:

:(

No seu guia, você sugere mv ~ / .docker ~ / .docker-bak - por que motivo? Assim que fizermos isso, não poderemos iniciar a máquina novamente, porque os arquivos são movidos.

@PavelPolyakov , não tenho certeza. Eu não uso docker-machine . Eu estava supondo com base em outros ambientes. Desconsidere se isso não funcionar.

Sim, consigo fazer o login na máquina e remover tls/* , em seguida, desligá-la, mas como reiniciá-la?

docker-machine restart não funciona?

Meu comentário foi baseado em minha própria experiência executando boot2docker com o Vagrant. Pode não se aplicar muito bem a docker-machine . Parece que @glyph tem mais experiência com esse ambiente. Eu tentaria suas sugestões.

Qual é a sua maneira de instalar o docker (com docker-compose funcionando), é via brew install ou via toolbelt .pkg?

Isso está um pouco fora do escopo deste problema (que lida especificamente com um problema de certificado com boot2docker manifestado em docker-compose ), mas no OS X, eu uso compilações binárias .

@PavelPolyakov , o que acontece quando você faz o seguinte?

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

Qual é a versão de boot2docker que é exibida quando você faz o seguinte?

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

Sinta-se à vontade para substituir shiny-new-machine-74d5a19e pelo que quiser, desde que não faça referência a uma instância existente (ou seja, o nome não deve aparecer quando você faz docker-machine ls antes de executar os comandos acima .).

@posita

Hmmm ....: confused: @PavelPolyakov , o que isso dá a você?

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
Obrigado por continuar a ajudar.

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

Tentei fazer o mesmo em outra máquina OSX.
Com todas as atualizações mais recentes (sistemas operacionais e pacotes de cerveja), e enfrentou o mesmo problema com SSL.

@PavelPolyakov , estou olhando isso de seu openssl s_client ... dump:

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

Estes não são os boot2docker padrões, que (agora) deveriam ser:

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

Sem saber mais, meu palpite é que docker-machine está substituindo os padrões (de alguma forma) quando provisiona a máquina virtual. Mas a chamada openssl parece ter funcionado, então não tenho certeza se isso é um problema e não entendo por que docker-compose falharia. : confundido:

Qual é a sua saída para o seguinte?

(
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

Isso deve criar um arquivo como ~/Desktop/docker-compose-890-outerr-2015-09-18T14:45:29Z.txt adequado para colar / enviar.

@posita
Aqui está:
http://pastebin.com/vWqZgVKi

Tenho certeza de que isso não tem nada a ver com o seu problema, mas suas versões docker-compose e docker-py estão para trás. Estes são os lançamentos mais recentes:

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

Além disso (e posso estar interpretando mal), parece que ca.pem e cert.pem compartilham o mesmo Subject (que foi a causa do boot2docker questão, mas vindo de outra direção). Uma vez que esses certificados parecem ter sido criados / mantidos por docker-machine , suspeito que o problema esteja lá? Encontrei docker / machine # 1335 e docker / machine # 1767, que podem estar relacionados, mas nenhum parece estar diretamente no ponto.

FWIW, estou usando docker-compose (instalado via pip em um virtualenv ) com OpenSSL e Python 2.7 instalado de MacPorts. Essa versão do OpenSSL está sujeita ao problema identificado neste problema (e contornado pela atualização para boot2docker ). Para mim, essa combinação funciona sem problemas com boot2docker 1.8.1+ e Vagrant (meu Vagrantfile copia os certificados boot2docker volta para o host por meio de alguma mágica de provisionamento):

% 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
------------------------------

Sei que você pode não ter essa opção. Estou postando apenas para ajudar a esclarecer as diferenças, o que pode ajudar no diagnóstico do seu problema. Compare o acima com seus certificados criados em 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
...

Observe que Subject de ca.pem é igual a Subject de cert.pem .

Não acho que seu problema seja com docker-compose . ( @aanand , talvez você possa comentar?) Vendo como esse problema é bastante confuso, considere preencher um novo problema para a docker / máquina . Eu faria referência a este, começando com seu comentário inicial .

Se você decidir registrar um novo problema para docker / máquina , considere adicionar onde houver algo interessante em /var/log/docker.log ou /var/log/boot2docker.log em sua instância de VM. Por exemplo, tente isto:

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

Ou:

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

Obtendo isso no OSX el capitain,

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

Olá @DaveBlooman ,

só por curiosidade, você também tem python e outras coisas instaladas usando o brew? Ou o contrário.
E você tem o erro exato ao fazer docker-compose build ?

Via homebrew, Python 2.7.10

Então, definitivamente algo acontece por causa do brew :(

@DaveBlooman , consulte também docker / machine # 1910. Se você pode reproduzir o problema de @PavelPolyakov , talvez vocês dois possam colaborar em um diagnóstico?

Tive o mesmo problema e foi devido ao fato de que tinha uma conexão vpn aberta instalada por outro aplicativo (Astrill no meu caso) que provavelmente estava bagunçando algo com a configuração da rede. Espero que isso possa ajudar alguém que tenha o mesmo problema.

Recebo erros no OSX 10.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 versão 0.5.0
versão docker-compose: 1.5.0

tudo instalado via Homebrew

@anthonygreen , parece um problema substancialmente diferente. Não vejo a mesma mensagem de erro que o que está sendo discutido aqui. Parece que os usuários do Homebrew estão enfrentando um número substancial de problemas não relacionados a este. Considere apresentar um novo problema.

Não li toda a postagem, mas vi o mesmo erro em uma configuração recente no OS X Yosemite usando o Docker Toolbox 1.9.1a.

$ 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

Acontece que eu tinha uma variável de ambiente CURL_CA_BUNDLE personalizada definida (com alguns certificados internos personalizados), e desarmar esta var env antes de executar docker-compose permitiu que ela passasse do erro [SSL: CERTIFICATE_VERIFY_FAILED] .

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

editar: oops, pretendia comentar aqui https://github.com/docker/machine/issues/1880

@pmahoney , obrigado por avisar o resto de nós! Eu nunca teria imaginado isso. Para sua informação, você provavelmente também pode fazer algo assim (se não quiser o subshell):

$ CURL_CA_BUNDLE= docker-compose up

@posita Definir o env var para a string vazia resulta em avisos:

$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

Embora eu não receba o erro SSL.

@pmahoney , interessante. Portanto, parece que um CURL_CA_BUNDLE definido-mas-vazio tem uma semântica diferente (ou seja, uma substituição nula) do que não defini-lo (que provavelmente olha para algum local padrão). Tentei encontrar esse comportamento nos documentos, mas não tive sucesso. A coisa mais próxima que encontrei foi isso .

@neilsarkar meu problema também era o proxy Charles rodando! Obrigado!

oh Deus, eu também tenho CURL_CA_BUNDLE personalizado nas duas máquinas onde estava testando.

obrigado

erf nada para mim, nenhuma variável CURL_CA_BUNDLE :(
Tentei definir um valor sem sucesso, mas se definir CURL_CA_BUNDLE como nada (CURL_CA_BUNDLE =), recebo um aviso, como
Espero que haja uma solução melhor para mim :)

Se você sabe qual é o bom valor para a variável CURL_CA_BUNDLE, eu pego :)

THX

Eu tive o mesmo problema com o webkit-patch. Observando os documentos python no módulo SSL / TLS , o ssl.get_default_verify_paths() nos mostra onde o Python / OpenSSL espera um arquivo de certificado CA. Então, se você executar isso em seu terminal:

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

devemos ver que sem SSL_CERT_FILE sendo definido, o módulo SSL do Python espera um arquivo de certificado CA em /usr/local/ssl/cert.pem (para aqueles que instalaram OpenSSL em /usr/local/ssl ). Portanto, você define SSL_CERT_FILE como um arquivo de certificado com certificados de CA raiz ou coloca um arquivo com certificados de CA raiz em /usr/local/ssl/cert.pem . Se você precisar dos certificados de CA raiz, baixe curl e, na árvore de origem, execute lib/mk-ca-bundle.pl e um arquivo ca-bundle.crt será gerado. Posso confirmar que a configuração SSL_CERT_FILE funcionará com OpenSSL 1.0.2d com Python 2.7.11 e Python 3.5.0.

@grahamc Por acaso você resolveu o problema? Tenho uma configuração semelhante à sua, que funciona muito bem com o daemon docker remoto, mas falha com docker-compose

O erro que recebo é ERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

Não, só tive que abandonar os hosts docker remotos, infelizmente :(

Acabei de ter este problema em que CURL_CA_BUNDLE causou a falha de docker-compose com:

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

enquanto docker estava funcionando bem. Seria bom fazer docker-compose ignorar a variável de ambiente ou pelo menos registrar um aviso de que não estará usando os certificados esperados.

@buckett , considere registrar uma nova edição para adicioná-la como uma solicitação de recurso. Considere também registrar uma questão irmã com docker-py e peça a eles que consultem um ao outro. Não tenho certeza de qual camada seria a mais apropriada.

editar: Novo problema criado # 3114

Todo mundo já consertou isso? Ainda obtenho o mesmo erro. Meu 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

Isso é o que eu obtive de 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)

Instalei docker, docker-mahine e docker-compose por meio da caixa de ferramentas do Docker.

Tentei todas as sugestões acima, mas não tive sorte. Não tenho experiência em docker então não consegui descobrir sozinho.

Alguém tem uma causa raiz ou uma solução alternativa para isso? Estou vendo isso no Compose 1.7.0 com uma versão mais recente do openssl.
Tudo isso é construído e executado em alpine, então o ambiente deve ser puro:

/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
no meu caso, foi causado pela variável CURL_CA_BUNDLE env redefinida. Você deve verificar se você tem esse caso também.

@PavelPolyakov verifique meu despejo de env ... sem CURL_CA_BUNDLE

@PavelPolyakov ok, isso é estranho, eu

@jmmills huh… mesmo aqui. Talvez o python trate set-as-empty de forma diferente para não set?

Mac OS, homebrew docker-compose e docker-machine, usando sistema python. Máquina recém-criada com: docker-machine create --driver=vmwarefusion --vmwarefusion-memory-size 1536 dev

env | grep CURL não retorna nada
docker-compose ps retorna

ERROR: SSL error: hostname '172.16.129.133' não corresponde a 'localhost'

CURL_CA_BUNDLE='' docker-compose ps retorna:

/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 
------------------------------

Eu tive exatamente o mesmo - CURL_CA_BUNDLE não estava sendo definido em meu env, e defini-lo como uma string vazia me deu a mesma saída que @inanimatt.

Definitivamente cheira a um bug de upstream, meu palpite seria algum código de compatibilidade de ambiente para curl, no qual "definido" e "vazio" estão sendo tratados de forma diferente.

Obrigado,
Jason Mills

• Enviado de celular.

Em 24 de abril de 2016, às 6h14, Alex Wilson [email protected] escreveu:

Eu tive exatamente o mesmo - CURL_CA_BUNDLE não estava sendo definido em meu env e defini-lo como uma string vazia me deu a mesma saída que @inanimatt.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub

Parece afetar apenas a versão homebrew - instalar o homebrew Python e depois instalar o docker-compose via pip resolve todos os erros.

Em 24 de abril de 2016, às 14:14, Alex Wilson [email protected] escreveu:

Eu tive exatamente o mesmo - CURL_CA_BUNDLE não estava sendo definido em meu env e defini-lo como uma string vazia me deu a mesma saída que @inanimatt.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub

Acredito que colei a replicação do problema no Linux anteriormente. Posso verificar amanhã quando estiver em uma estação de trabalho

Obrigado,
Jason Mills

• Enviado de celular.

Em 24 de abril de 2016, às 12h22, Matt Robinson [email protected] escreveu:

Parece afetar apenas a versão homebrew - instalar o homebrew Python e depois instalar o docker-compose via pip resolve todos os erros.

Em 24 de abril de 2016, às 14:14, Alex Wilson [email protected] escreveu:

Eu tive exatamente o mesmo - CURL_CA_BUNDLE não estava sendo definido em meu env e defini-lo como uma string vazia me deu a mesma saída que @inanimatt.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub

O mesmo problema aqui, desde que atualizei docker-compose para a versão 1.7 usando o brew.

$ 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

Esvaziar a variável env CURL_CA_BUNDLE resolve o problema:

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

O downgrade para 1.6.2 também resolve o problema.

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

Em vez de desativar o CURL_CA_BUNDLE, você pode executar usando:
CURL_CA_BUNDLE = ~ / .docker / machine / machines / default / ca.pem docker-compose ps

Provavelmente não sou o primeiro a trazer isso à tona, mas não é contra intuitivo que uma variável de ambiente curl tenha qualquer efeito em um aplicativo Python não relacionado?

Obrigado,
Jason Mills

• Enviado de celular.

Em 7 de maio de 2016, às 15:22, Lorenzo Sicilia [email protected] escreveu:

Em vez de desativar o CURL_CA_BUNDLE, você pode executar usando:
CURL_CA_BUNDLE = ~ / .docker / machine / machines / default / ca.pem docker-compose ps

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub

Encontrei esse problema e o problema era com a variável de ambiente REQUESTS_CA_BUNDLE apontando para um local personalizado para certificados autoassinados. Encase isso ajuda qualquer pessoa.

• Michael Housh

@aboutlo Isso funciona - não funcionou com outro arquivo ca.pem , apenas com este. Também estou no Windows, então tenho uma configuração mais vodu, obrigado!

Desinstalar o ndg-httpsclient (com pip - era a versão 0.4.0) resolveu o problema para mim, veja minha postagem aqui: https://github.com/docker/compose/issues/3365

Eu depurei docker-compose e docker-py e descobri que você deve usar variáveis ​​de ambiente ou opções no comando. Você não deve misturar estes. Se você especificar --tls no comando, você terá que especificar todas as opções como o objeto TLSConfig, já que agora o objeto TLSConfig é criado completamente a partir das opções de comando e opera o objeto TFSConfig criado a partir da variável de ambiente.

@ m-housh OMG, obrigado por essa dica! Exatamente a mesma coisa aconteceu comigo! Removeu REQUESTS_CA_BUNDLE do meu ambiente e resolveu este problema para mim.

Eu encontrei o mesmo problema. Em primeiro lugar, pensei que fosse por causa das diferenças de versão do OpenSSL (Pyhton tinha 1.0.2, mas o SO tinha 0.9.8), criei os dois 1.0.2, mas ainda não funcionou.
Resolvi meu problema simplesmente ssh para docker e depois verifiquei meu certificado nas chaves autorizadas e atualizei-o. Curiosamente, de alguma forma, havia um certificado errado ali.

Siga estas etapas:

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

Verifique se este certificado é realmente o certificado do seu computador. Se não, apenas copie o seu para este arquivo e salve-o. Depois é só executar:

docker-compose up

Isso funcionou para mim e espero que ajude.

Tratamento de problemas: parece haver uma variedade de modos de falha diferentes e cenários de erro / configuração incorreta do usuário (todos amplamente históricos) descritos aqui.

Não estou vendo nada que pareça apontar para um problema ativo em andamento na composição, então estou encerrando o problema. Se você ainda estiver vendo um erro relacionado com as versões modernas, abra um novo problema com todos os detalhes do seu cenário, etc.