Creo que estoy experimentando lo mismo al intentar usar el candidato de lanzamiento docker-compose ...

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

Pero fig funciona bien ...

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

Estoy en OSX, ejecutando todas las mismas versiones que @gkostyanikov , excepto que mi versión de cliente Go es go1.3.3 . Mi python / openssl también se instala a través de Homebrew. ¿Podría tener algo que ver con eso?

Editar: En realidad, parece que Homebrew no vincula openssl, así que estoy usando la versión predeterminada de OSX: OpenSSL 0.9.8za 5 Jun 2014 .

El problema era Python Homebrew.

docker-compose ahora funciona después de desinstalar homebrew python / openssl, instalar pip con easy_install y reinstalar docker-composer usando el sistema python.

@adambiggs ¡ Tu solución funciona! ¡Gracias!

Esto también funcionó para mí, estoy usando una nueva Mac y la configuro con homebrew python. Tuve este error con fig comunicándose con Docker. Seguí los consejos de @adambiggs textualmente y

Esto también me está pasando a mí. Y no quiero usar Python del sistema, ¿alguien tiene otra solución?

¿Ha intentado usar el binario? ¿Tiene el mismo problema?

No, no he probado el binario.
Si no desea instalarlo en su sistema Python, otra solución es usar virtualenv (envoltorio).

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

Encontré una mejor solución usando pyenv para volver a Python 2.7.8:

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

Editar: No importa, pyenv introdujo un montón de sus propios problemas ...

Lo que me causó este error fue que el openssl de preparación casera no estaba vinculado a / usr / local / bin / openssl.

openssl version

devuelto OpenSSL 0.9.8zc 15 de octubre de 2014 no OpenSSL 1.0.1j 15 de octubre de 2014

Corriendo

brew link --force openssl

y reinstalar fig resolvió el problema.

Interesante, sin embargo, mi versión de OpenSSL es

@aanand en mi caso el binario no tiene este problema.

Recibí este error cuando instalé fig a través de pip, no homebrew. sudo pip uninstall fig y brew install fig me lo arreglaron.

+1 para la solución @NotBobTheBuilder , también funcionó para mí

: +1: para @NotBobTheBuilder

@NotBobTheBuilder es una buena solución para fig pero, desafortunadamente, docker-compose aún no está disponible en homebrew.

@ocasta ¿qué pasa con esta advertencia que suena aterradora de homebrew sobre vincular OpenSSL?

Esta fórmula es solo de barril.
Mac OS X ya proporciona este software e instala otra versión en
El paralelo puede causar todo tipo de problemas.

Apple ha desaprobado el uso de OpenSSL en favor de sus propias bibliotecas TLS y cripto

Pulgares arriba @NotBobTheBuilder - Eso también lo solucionó conmigo.

¿Alguien sabe la fuente de este problema? me está pasando con la fig. Prefiero ceñirme a pip install fig como lo hago ahora. Todo funcionó bien hace un par de semanas, no sé qué ha cambiado en mi sistema

Mi sistema OpenSSL es OpenSSL 0.9.8zc 15 Oct 2014 , mi openssl casero es más nuevo pero no está vinculado.

... Supongo que se rompió cuando actualicé a Python 2.7.9, parece que hay algunos errores relacionados con SSL ... se parece mucho a esto:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196431
http://bugs.python.org/issue23052

ejecutar brew link --force openssl y reinstalar fig no hizo nada por mí.

¿Es necesario actualizar fig para solucionar los cambios de SSL en Py 2.7.9?
https://www.python.org/dev/peps/pep-0476/#opting -out

Estoy usando boot2docker. Acabo de actualizar a 1.5.0 pero sin cambios.

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}

El código fig parece correcto, está intentando usar los certificados instalados por boot2docker ... Supongo que estos certificados están bien porque siempre solían funcionar y acabo de actualizar b2d para que no deberían haber expirado.

Hmm, mi Python (instalado a través de homebrew) parece estar usando la versión homebrew de 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

... ejecutar /usr/local/opt/openssl/bin/c_rehash no ayudó :)

Probé una versión previamente instalada de python (2.7.8_2) a través de $ brew switch python 2.7.8_2 con el mismo problema (incluso si el mensaje de error era ligeramente diferente). Entonces, la versión de Python 2.7.9 parece no ser el problema.

Luego intenté cambiar a una versión de openssl anterior, de 1.0.2 a 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 mí, solo recibo un error diferente, pero tal vez ayude a reducir lo que está mal:

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

Volver a OpenSSL 1.0.2 produce el error CERTIFICATE_VERIFY_FAILED por lo que cambiar las versiones definitivamente tiene algún efecto

Una solución es ejecutar docker-compose en un contenedor:

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

Esto requiere exponer el puerto 2376 en VirtualBox:

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

La respuesta de @kretz funcionó para mí.

+1 @kretz brew switch openssl 1.0.1j_1
hizo el truco

brew switch openssl 1.0.1j funciona para mí (tenga en cuenta la falta de _1)

No me gusta, pero desinstalar fig de mi virtualenv e instalarlo a través de homebrew solucionó las cosas para mí

Gracias @kretz , ¡tu respuesta me lo resolvió!

No me funciona 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

Mi solución fue crear un virtualenv con python 2.7.8, en lugar del 2.7.9 que obtuve de brew.

varias soluciones ... ¿Alguien tiene una idea del problema real?

¿Qué tiene que ver App Engine con todo?

El 11 de marzo de 2015 a las 18:09, Ryan Small [email protected] escribió:

Estoy bastante seguro de que ninguna de las cosas del motor de la aplicación funciona con Python 2.7.9

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/compose/issues/890#issuecomment -78329652.

@anentropic Necesita instalar la versión anterior de openssl antes de poder usarla (cambiar a).

# 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

Hice brew install openssl101 pero no me dio la posibilidad de cambiar a 1.0.1j ... me dio un 1.0.1l y me preocupaba que pudiera confundir mi sistema ya son paquetes de preparación separados y ya tenía 1.0.2 en paralelo

no pareció ayudar, pero tal vez no fui lo suficientemente lejos con eso

Lo siento, respondí al problema de github incorrecto (eliminé rápidamente mi comentario)
El miércoles 11 de marzo de 2015 a las 11:30 a. M. Anentropic [email protected]
escribió:

Hice la instalación de openssl101 pero no me dio la posibilidad de
cambiar a 1.0.1j ... me dio un 1.0.1l y me preocupaba que fuera a
confundir mi sistema, ya que son paquetes de preparación separados y ya tenía
1.0.2 en paralelo

no pareció ayudar, pero tal vez no fui lo suficientemente lejos con eso

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/compose/issues/890#issuecomment -78340580.

Así que parece que también tengo este problema, ejecutándome en Mac OSX. Usando docker-compose, este es mi archivo .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

Cuando ejecuto docker-compose pull obtengo el siguiente resultado que falló.

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

Verifiqué algunas cosas.
which openssl; openssl version

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

@psykzz Debería funcionar si lo instala con brew

brew install docker-compose

@arvindtest ¿qué te hace pensar que está relacionado con este tema?

FYI, después de luchar mucho con esto, parece que se trata de un problema de boot2docker.
Lo que funcionó para mí fue deshabilitar TLS. Todavía no existe una forma fácil de usar para hacer esto, pero las instrucciones se describen aquí:
https://github.com/deis/deis/issues/2230

Básicamente, necesitas:

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

luego reinicie boot2docker, es decir
parada de boot2docker
arranque boot2docker

y algo como esto en tu ~ / .bashrc (asegúrate de que la ip sea correcta)

exportar DOCKER_HOST = tcp: //192.168.59.103 : 2375
desarmado DOCKER_CERT_PATH
desarmado DOCKER_TLS_VERIFY

En su bashrc, ¿por qué no tener $ (boot2docker shellinit)

¿Debería ayudar con todo bien?

Quiero decir que todavía tienes que hacer la solución TLS.
El 21 de marzo de 2015 a las 23:05, "coderfi" [email protected] escribió:

Para su información, después de luchar mucho con esto, parece que este es un
Problema de boot2docker.
Lo que funcionó para mí fue deshabilitar TLS. Todavía no existe una forma fácil de usar
para hacer esto, pero las instrucciones se describen aquí:
deis / deis # 2230 https://github.com/deis/deis/issues/2230

Básicamente, necesitas:

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

luego reinicie boot2docker, es decir
parada de boot2docker
arranque boot2docker

y algo como esto en tu ~ / .bashrc
asegúrese de que la ip sea correcta

exportar DOCKER_HOST = tcp: //192.168.59.103 : 2375
desarmado DOCKER_CERT_PATH
desarmado DOCKER_TLS_VERIFY

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/compose/issues/890#issuecomment -84468058.

@kretz ¡funciona! Gracias.

@psykzz, ¿te refieres a $(boot2docker shellinit) ?

sí lo hice, actualicé mi comentario. derp.

¡Puedo confirmar que la solución de @coderfi para deshabilitar TLS funciona para mí!

Me alegra que funcione para ti. :)

@ Matt , sí, tiene razón sobre la sugerencia de expansión de shell de inicio de shell.
Sin embargo, es posible que eso no funcione si boot2docker aún no se ha iniciado, así que simplemente
hizo explícito el ejemplo.

Fi
El 26 de marzo de 2015 a las 10:18 a.m., "anentropic" [email protected] escribió:

Puedo confirmar que la solución de @coderfi https://github.com/coderfi para
deshabilitar TLS funciona para mí!

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/compose/issues/890#issuecomment -86630313.

Tal vez esto sea obvio, pero aquellos que deshabilitan TLS o degradan OpenSSL solo para que esto funcione deben actuar con cuidado dependiendo de lo que estén haciendo.

Esto no se relacionará con todos, pero tuve un error similar durante las instalaciones de pip usando Dockerfile extrayendo de gliderlabs/alpine:3.1 , el contenedor Linux mínimo de progrium & crew. El problema era que no había instalado el paquete de certificados del sistema, el problema se solucionó instalando el paquete antes de instalar pip y ejecutando el archivo de requisitos:

RUN apk-install -X ca-certificates

Las soluciones sugeridas realmente no funcionaron para mí. No se pudo cambiar a ninguna de las versiones 1.0.1 de OpenSSL. Al final, descubrí que desinstalar todas las versiones de docker-compose instaladas con pip y simplemente hacer brew install docker-compose alguna manera funciona.

Las soluciones anteriores funcionaron pero eran demasiado engorrosas para mí. Un rápido boot2docker upgrade arregló todo por mi parte.

Ya tengo la última versión de boot2docker y no me funciona sin las correcciones anteriores

Los desarrolladores de Homebrew sugieren que docker-py y docker-compose deberían actualizarse para usar requests 2.6.0

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

Espero que esto ayude a alguien ... no estoy seguro de una solución, pero si está utilizando Charles como un Proxy de Mac OS X, este mensaje se generará.

FWIW, la instalación de docker-compose a través de pip hizo que docker-compose funcionara (la instalación a través de curl en OS X Mavericks resultó en un error illegal operation ). Posteriormente también recibí el error SSL. Ejecutar brew link --force openssl && brew switch openssl 1.0.1j parece haberlo solucionado.

@rseymour respuesta funcionó para mí

Para aquellos que no pueden encontrar openssl-1.0.1j en brew, pueden tomar la versión anterior de la receta de openssl del repositorio de github y usarla:

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

Intenté 1.0.1m pero no funcionó.
Así que probé la forma @lazyval , funciona para mí.
Esto es lo que hice.

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

¡¡Gracias!!

Actualmente estoy investigando esto, ya que ahora necesitamos compilar los binarios en Python 2.7.9+.

_Reubicado de # 1427_

Servidor:

• CoreOS estable
• 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 en ~/.docker/{ca.pem,cert.pem,key.pem}
• DOCKER_HOST=tcp://docker-builder:2376
• DOCKER_TLS_VERIFY=1

Usando el siguiente Makefile para construir los 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

Aquí está el script de datos de usuario (ciertamente menos que ideal) para aprovisionar 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

Al usar el cliente docker , tengo éxito al acceder al servidor Docker remoto. Llamamos al servidor remoto hasta cien mil veces al día con buen éxito.

Al intentar usar docker-compose , instalado a través de curl O pip install --upgrade con python 2.7, obtenemos un error de SSL:

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

Este es el caso después de especificar manualmente DOCKER_CERT_PATH=/home/user/.docker/ así como REQUESTS_CA_BUNDLE=/home/user/.docker/ca.pem , individualmente y juntos.

Para ser claros: esta configuración funciona muy bien solo con el demonio docker, pero algo sobre -compose está mal.

Algunas notas:

1. El binario Compose 1.3.0 RC1 para OSX tiene este error. Probablemente no sea una coincidencia, esta es la primera vez que se construye contra Python 2.7.9; antes, era 2.7.6.
2. Extrañamente, puedo reproducir contra una máquina virtual boot2docker, pero no contra una máquina virtual Virtualbox aprovisionada por la máquina. @ehazlett , @nathanleclaire , @tianon : ¿alguna información allí?
3. Para cualquiera que experimente esto cuando Compose esté instalado con Pip, informe el resultado de los siguientes comandos:

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

En mi máquina local, donde puedo reproducir el error, tengo Python 2.7.10 y OpenSSL 1.0.2a 19 Mar 2015 .

1. Esto se ha informado a Homebrew, y algunas personas dicen que han tenido éxito reinstalando Python y OpenSSL, pero no me ha funcionado. https://github.com/Homebrew/homebrew/issues/38226

Hmm, eso es realmente extraño. ¿Qué versión de b2d estás usando frente a la versión?
de la máquina? Ambos usamos b2d, así que no estoy seguro de qué sería diferente
además de la versión.

Lo instalaré a través de pip en mi máquina OS X y veré lo que obtengo.

El jueves 28 de mayo de 2015 a las 9:19 a.m., Aanand Prasad [email protected]
escribió:

Algunas notas:

1.

El binario Compose 1.3.0 RC1 para OSX tiene este error. Probablemente no
casualmente, esta es la primera vez que se construye contra Python 2.7.9

• antes, era 2.7.6.
  2.

Extrañamente, puedo reproducir contra una máquina virtual boot2docker, pero no contra una
Virtualbox VM aprovisionada por Machine. @ehazlett
https://github.com/ehazlett , @nathanleclaire
https://github.com/nathanleclaire , @tianon
https://github.com/tianon : ¿alguna información allí?
3.

Para cualquiera que experimente esto cuando Compose está instalado con Pip, por favor
reportar el resultado de los siguientes comandos:

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

En mi máquina local, donde puedo reproducir el error, tengo Python
2.7.10 y OpenSSL 1.0.2a 19 de marzo de 2015.
4.

Esto se ha informado a Homebrew, y algunas personas dicen que han tenido
éxito reinstalando Python y OpenSSL, pero no me ha funcionado.
Homebrew / Homebrew # 38226
https://github.com/Homebrew/homebrew/issues/38226

-
Responda a este correo electrónico directamente o véalo en 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)

¿Hay algo diferente en la generación de certificados, tal vez? Parece que tengo más archivos en el directorio de certificados de mi máquina que en mi 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

Eso está bien. El cliente solo usará ca.pem, cert.pem y key.pem
(el servidor es solo una copia local para el host en la máquina). Voy a crear como
bien e inspeccione los certificados para ver cuál podría ser la diferencia.

El jueves 28 de mayo de 2015 a las 9:30 a. M., Aanand Prasad [email protected]
escribió:

$ boot2docker versión
Boot2Docker-cli versión: v1.6.2
Confirmación de Git: cb2c3bc

$ docker-machine --version
docker-machine versión 0.2.0 (8b9eaf2)

¿Hay algo diferente en la generación de certificados, tal vez? Parece que tengo mas
archivos en mi directorio cert de máquina que en mi boot2docker uno.

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

-
Responda a este correo electrónico directamente o véalo en 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 también https://github.com/docker/docker-py/issues/465. El script de prueba de @garethr allí también reproduce el error para mí, después de hacer una modificación para deshabilitar la verificación del nombre 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)

Sin embargo, todavía funciona con la máquina virtual aprovisionada por máquina:

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

Si vuelvo a habilitar la comprobación del nombre de host (comentando la línea assert_hostname en el script de prueba), falla con el mismo error en la máquina virtual boot2docker-cli, pero con un error diferente en la máquina virtual, que puede o puede no 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

Además, intenté usar v1.3.0-rc1 a través de curl (la versión binaria, no a través de pip) y obtuve el mismo error que antes en un demonio de Docker 1.6.2:

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

Sí, el binario RC1 se creó con Python 2.7.9 y OpenSSL 1.0.2a, que parece ser una de las combinaciones problemáticas.

Esto tiene sentido porque creo que la generación de certificados en b2d está en la VM
mientras que la máquina los genera en la máquina. Podríamos detectar y agregar el
nombre de la máquina a las SAN si es necesario. En realidad eso probablemente sería bueno
especialmente para máquinas virtuales b2d. Creo que la razón por la que funciona ahora es porque tú
acceder al motor utilizando la IP que la máquina agrega como IP SAN. Hay un
PR abierto para permitir SAN adicionales arbitrarias que también funcionarían.

El jueves 28 de mayo de 2015, Aanand Prasad [email protected] escribió:

Consulte también docker / docker-py # 465
https://github.com/docker/docker-py/issues/465. @garethr
El script de prueba de https://github.com/garethr reproduce el error para
yo también, después de hacer una modificación para deshabilitar la verificación del nombre de host:

desde docker.client import Clientfrom docker.utils import kwargs_from_env

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

cliente = Cliente (** kwargs) cliente de impresión.version ()

$ eval "$ (boot2docker shellinit)" && python test.py
Escribiendo /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
Escribiendo /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
Escribiendo /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem
Rastreo (llamadas recientes más última):
Archivo "test.py", línea 8, en
print client.version ()
Archivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", línea 1108, en la versión
return self._result (self._get (url), json = True)
Archivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", línea 106, en _get
return self.get (url, * _self._set_request_timeout (kwargs))
Archivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", línea 477, en get
return self.request ('OBTENER', url, * _kwargs)
Archivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", línea 465, en solicitud
resp = self.send (preparación, * _send_kwargs)
Archivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", línea 573, en enviar
r = adapter.send (solicitud, * _kwargs)
Archivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", línea 431, en enviar
elevar SSLError (e, solicitud = solicitud)
request.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] error en la verificación del certificado (_ssl.c: 590)

Sin embargo, todavía funciona con la máquina virtual aprovisionada por máquina:

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

Si vuelvo a habilitar la comprobación del nombre de host (comentando el valor de assert_hostname
línea en el script de prueba), falla con el mismo error contra el
boot2docker-cli VM, pero un _ error diferente_ contra la máquina VM, que
puede o no ser relevante:

Rastreo (llamadas recientes más última):
Archivo "test.py", línea 8, en
print client.version ()
Archivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", línea 1108, en la versión
return self._result (self._get (url), json = True)
Archivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", línea 106, en _get
return self.get (url, * _self._set_request_timeout (kwargs))
Archivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", línea 477, en get
return self.request ('OBTENER', url, * _kwargs)
Archivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", línea 465, en solicitud
resp = self.send (preparación, * _send_kwargs)
Archivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", línea 573, en enviar
r = adapter.send (solicitud, * _kwargs)
Archivo "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", línea 431, en enviar
elevar SSLError (e, solicitud = solicitud)
request.exceptions.SSLError: no se encontraron los campos commonName o subjectAltName apropiados

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/compose/issues/890#issuecomment -106363305.

OK, creo que he llegado a una solución para OS X: https://github.com/docker/compose/pull/1474

Arreglarlo para Linux implicará actualizar el Dockerfile para anclarlo a Python 2.7.9 y OpenSSL 1.0.1, lo cual será un esfuerzo divertido dado que comienza desde debian:wheezy (lo que hace para asegurarnos de que estamos usando un antiguo glibc: consulte https://github.com/docker/compose/pull/505).

Cambiar a 1.0.1k como se describe en el comentario de @kretz e instalar 1.3.0 RC1 a través de pip me funcionó.

Antes de cambiar Python informó 1.0.2a:

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

Después de cambiar, informó 1.0.1k y docker-compose parece funcionar como se esperaba:

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

una solución que eliminó este error fue instalar los siguientes paquetes en mi virtualenv
pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7

En el entorno descrito en https://github.com/docker/compose/issues/890#issuecomment -106289821 que proporciona Python 2.7.6 (a través de snap-ci.com, en el que puede obtener una cuenta gratuita)

con la siguiente secuencia de comandos que utiliza la solución alternativa de @ jsh2134 en una instalación 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

Obtengo el siguiente resultado:

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

Tenga en cuenta especialmente el error (que parece nuevo):

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

Creé https://github.com/docker/compose/issues/1484 para deshacerme de mis hallazgos hasta ahora.

He creado algunos binarios con la corrección en # 1474. Pruébelos si ha tenido problemas con 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 ¿

+1 para la respuesta de @kretz :)

+1 mismo problema :( ¿parece que Docker está completamente roto en osx?

La solución

Lidiar con uno de los errores variantes en una máquina virtual Centos7, que actúa como un cliente para iniciar contenedores en una máquina acoplable:

[ root @ xxxx cm] # docker-compose ps
Error de SSL: no se encontraron los campos commonName o subjectAltName adecuados

Esto solía ser transitorio; Podría cerrar la sesión, volver a iniciar sesión y no ver el error por un tiempo. Ahora viéndolo siempre.

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

[ root @ xxxx cm] # versión de Docker
Versión del cliente: 1.6.2
Versión de la API del cliente: 1.18
Go versión (cliente): go1.4.2
Confirmación de Git (cliente): ba1f6c3 / 1.6.2
OS / Arch (cliente): linux / amd64
Versión del servidor: swarm / 0.2.0
Go versión (servidor): go1.3.3
Confirmación de Git (servidor): 48fd993
OS / Arch (servidor): linux / amd64

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

No estoy seguro de cómo aplicar algunas de las correcciones mencionadas anteriormente en mi entorno. No estoy usando boot2docker; lidiando con Docker 1.6.2 directamente en la línea de comandos de bash.

Hola. De hecho, abrí un problema porque no puedo solucionarlo. Probé muchas cosas, es decir, instalar componer con las versiones pip / brew / newst. Lo mismo que openssl probó las versiones 0.x 1.0.2x, etc. y aún no funciona.

PD: no uso boot2docker. Tengo mi propia VM que hago a través de vagrant, genero los certificados y lanzo el demonio docker con ellos. Aparentemente, funciona con Docker, por lo que el problema no proviene de mis 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

obtuve este error también en un momento:

/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

Después de leer aquí y jugar con la instalación de los paquetes sugeridos:

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

El mensaje de error de docker-compose ha cambiado:

[ root @ xxx cm] # docker-compose up -d
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:251: SecurityWarning: El certificado no tiene subjectAltName , retrocediendo para comprobar un commonName para ahora. Esta función está siendo eliminada por los principales navegadores y obsoleta por RFC 2818. (Consulte https://github.com/shazow/urllib3/issues/497 para obtener más detalles).
Advertencia de seguridad
Error de SSL: el nombre de host 'xx.xx.xx.xx' no coincide con Ninguno

(El cuadrante punteado que vi es del host maestro / acoplador de enjambre).

¿Este problema también se puede solucionar editando o regenerando el certificado?

Anexo: Los certificados se crearon en estas máquinas virtuales mediante "docker-machine create".

¿Podríamos estar lidiando con un error en la máquina acoplable que da como resultado un certificado insuficientemente detallado?

Solo veo este error con los hosts de Docker creados por la máquina docker. Creo que los certificados SSL no se crean correctamente.

¿Alguien tiene una solución alternativa para solucionar este problema? Esto es un poco bloqueador para mí en este momento: /

@prologic ¿Está recibiendo el error con el binario o con un Compose instalado con Pip? Si es lo último, intente instalar requests[security] también.

@aanand ¡Gracias! ¡Lo intentaré e informaré si funciona o no!

@prologic Queremos empaquetar requests[security] lugar de confiar en el módulo SSL con errores de Python; estamos rastreando el esfuerzo en el n. ° 1530.

@aanand ¡ Gracias! Esto funcionó perfectamente :)

@coderfi su solución funcionó para mí, gracias

@aanand la construcción del 2 de junio funciona bien para mí. mucha suerte aplastando este doloroso error.

@neilsarkar Sucedió que estaba ejecutando Charles Proxy, tu comentario me salvó. : +1:

Estoy usando OS X 10.9.5, aquí está mi propia identidad:

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

Mi solución:

comentar líneas 246: 253 en
/usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connection.py

esta es la parte que lanza la excepción de seguridad

El problema para mí fue que incluso si especificaba brew link --force openssl, fig / docker-compose todavía 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

Esto funcionó para mí. Ahora ya no recibo el mensaje molesto.

Para su información, la receta brew fig / docker-compose usa system python, por lo que incluso si instala python a través de pyenv o brew, brew install fig / docker-compose seguirá usando el sistema openssl lib si está disponible, de lo contrario, está instalando alguna otra versión.

En mi MAC en el trabajo, lo resolví con pyenv install 2.7.8, luego easy_install pip y pip install docker-compose.

pero en mi Mac en casa, "ambos ejecutan yosemite", hice lo mismo y todavía recibo la advertencia.

Seguirá cavando.

@dtunes : la causa raíz (como @aanand mencionado anteriormente) es https://github.com/boot2docker/boot2docker/issues/808. Lo de system-python / homebrew-python es una pista falsa, porque solo depende de si está vinculado con OpenSSL nuevo o antiguo.

Sí, vi ese boleto. Lo que me molesta es que en mi Mac en el trabajo, después de probar los diferentes enfoques anteriores, ninguno funcionó.
Luego moví / usr / bin / openssl a / usr / bin / openssl_old, instalé el último openssl usando home brew y forcé el enlace. solo entonces hice lo siguiente:

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

Esto funcionó en el trabajo, en mi Mac en casa, sin embargo, no funcionó. Pero intentaré de nuevo en caso de que haya cometido un error e informaré los resultados.

@dtunes : para reconstruir todas sus dependencias, debe eliminar ~/Library/Caches/pip para que la rueda binaria en caché construida contra el OpenSSL incorrecto no se vuelva a utilizar.

@glyph escribió :

la causa raíz (como @aanand mencionado anteriormente) es boot2docker / boot2docker # 808. Lo de system-python / homebrew-python es una pista falsa, porque solo depende de si está vinculado con OpenSSL nuevo o antiguo.

@glyph o @aanand , ¿sugiere eso que la solución de alternativa ) combinada de # 1474 simplemente se adapta a un b2d roto? @aanand , si boot2docker / boot2docker # 808 se direcciona correctamente, ¿se debe restituir # 1474? ¿Es poner esperanza en el próximo lanzamiento de criptografía (ver esto y esto ) también una pista falsa?

@aanand escribió :

Tenga en cuenta que no puedo reproducir este error en una máquina virtual Boot2Docker aprovisionada con docker-machine; solo ocurre contra una máquina virtual aprovisionada con el comando boot2docker.

@ehazlett escribió :

Esto tiene sentido porque creo que la generación de certificados en b2d está en la máquina virtual, mientras que la máquina los genera en la máquina.

Puede que lo haya entendido mal, pero hay muchas charlas que culpan a varias combinaciones de Python / OpenSSL del lado del host por esto y problemas relacionados. Si la fuente del problema es un OpenSSL roto distribuido con b2d, no estoy seguro de que el mejor enfoque sea asegurarse de que el OpenSSL del lado del host de Compose esté igualmente roto. Por lo que vale, es poco probable que esos tipos de contorsiones del lado del host resuelvan este problema para aquellos que ejecutan b2d a través de (por ejemplo) Vagrant y acceden a él fuera de Compose (ver, por ejemplo, docker / docker-py # 465 ).

Si este comentario es más apropiado en boot2docker / boot2docker # 808, puedo moverlo allí.

Soy un mantenedor de Homebrew y ayudé a glyph a resolver esto.

Los DN de sujeto y emisor del certificado de servidor generado por boot2docker se establecen de forma idéntica en /O=Boot2Docker . Creo que el certificado del servidor está realmente firmado por el certificado de CA, pero AFAICT OpenSSL 1.0.2 usa esta información (es decir, DN idénticos de sujeto y emisor) para rechazar el certificado del servidor como autofirmado en lugar de intentar verificar el certificado del servidor con el proporcionado Certificado de CA Las versiones de OpenSSL anteriores a la 1.0.2 validan el certificado del servidor con el certificado de CA proporcionado, que tiene éxito.

Creo, pero no he probado, que otorgar al servidor y los certificados de CA distintos DN de sujeto (de modo que el certificado de servidor tenga distintos DN de sujeto y emisor) permitirá que los certificados se validen en todas las versiones de OpenSSL. Sospecho (según mi lectura de esta guía de supervivencia X.509, pero no de ninguna especificación relacionada), pero no estoy seguro, de que el comportamiento de OpenSSL 1.0.2 es razonable y no representa una regresión que los desarrolladores de OpenSSL deberían resolver.

1474 hace dos cosas distintas:

• establecer una versión mínima de Python en 2.7.9: esto permite que urllib3 complete solicitudes sin emitir un InsecurePlatformWarning, que se emite al realizar conexiones HTTPS si se cumplen dos condiciones: la versión de Python es anterior a 2.7.9 y el módulo PyOpenSSL no es presente. Empaquetar PyOpenSSL sería igualmente efectivo, pero entiendo por la discusión que no es compatible con PyInstaller. De cualquier manera, InsecurePlatformWarning de urllib3 no está relacionado con el problema del certificado boot2docker, y arreglar los certificados no elimina la necesidad de esta solución.
• estableciendo una versión máxima de OpenSSL en 1.0.1j. Creo que esto debería ser innecesario una vez que se corrijan los certificados boot2docker.

Si la fuente del problema es un OpenSSL roto distribuido con b2d

No lo es; los certificados boot2docker (generados por este código ) no son válidos según los clientes que usan OpenSSL ≥ 1.0.2; la biblioteca OpenSSL distribuida con boot2docker no está implicada.

@glyph o @aanand , ¿sugiere eso que la solución de alternativa ) combinada de # 1474 simplemente se adapta a un b2d roto? @aanand , si boot2docker / boot2docker # 808 se direcciona correctamente, ¿se debe restituir # 1474? ¿Poner esperanza en el próximo lanzamiento de criptografía (ver esto y esto) también es una pista falsa?

Sí, eso creo. Creo que el OpenSSL con el problema es 1.0.2, y al restringirlo a 1.0.1, evitaría cualquier lógica de verificación que esté causando que el certificado falle. Todavía no sé _qué_ tiene el certificado que no le gusta, ya que los mensajes de error son tan obtusos.

Además, creo que lo que está haciendo # 1474 es demasiado específico; al menos según mi lectura, no establece una versión _minimum_ python, sino que especifica una versión _exact_. También parece fallar su verificación, usted tiene un 1.0.1 diferente de j, lo que significa que las actualizaciones de seguridad no se aplicarán ni siquiera a 1.0.1, lo cual es _definitivamente_ un problema.

Creo, pero no he probado, que otorgar al servidor y los certificados de CA distintos DN de sujeto (de modo que el certificado de servidor tenga distintos DN de sujeto y emisor) permitirá que los certificados se validen en todas las versiones de OpenSSL. Sospecho (según mi lectura de esta guía de supervivencia X.509, pero no de ninguna especificación relacionada), pero no estoy seguro, de que el comportamiento de OpenSSL 1.0.2 es razonable y no representa una regresión que los desarrolladores de OpenSSL deberían resolver.

Investigaré el certificado generado por docker-machine y veré si tiene esta propiedad. ¿Por qué dice que este comportamiento sería aceptable / no una regresión en OpenSSL? Confiar en un certificado autofirmado está perfectamente bien, y no existen restricciones particulares sobre lo que el sujeto o el emisor puede contener que yo sepa. Leí un poco de esa guía y parece que solo está señalando que los certificados autofirmados no tendrán la confianza del cartel de CA, por lo que su navegador web no confiará en ellos sin una configuración adicional.

Mirando el certificado en mi docker-machine VM, veo:

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

así que puede que tengas razón en esto ...

Investigaré el certificado generado por la máquina acoplable y veré si tiene [DN de sujeto y emisor coincidentes].

Puede ver que los certificados de docker-machine de aanand también tienen DN distintos: https://gist.github.com/aanand/3d865623481ba8ae66ee#file -docker-machine-log-L30-L32

Confiar en un certificado autofirmado está perfectamente bien

Pero un certificado autofirmado no es válido a menos que confíe en el certificado autofirmado. No indicamos a OpenSSL que confíe en el certificado del servidor; le indicamos a OpenSSL que confíe en la CA que emitió el certificado de servidor.

¿Por qué dice que este comportamiento sería aceptable / no una regresión en OpenSSL?

IANAL, pero mi razonamiento se deriva del lenguaje "En un nivel estricto [autofirma] significa que los campos de emisor y asunto en el certificado son los mismos". Ese es el caso del certificado del servidor boot2docker. Cuando OpenSSL intenta validar el certificado del servidor boot2docker, es posible construir una cadena de confianza completa sin considerar el certificado CA, ya que el certificado del servidor parece estar firmado por sí mismo, pero no es de confianza explícita y, por lo tanto, no puede ser válido. No estoy seguro de que este sea un comportamiento estrictamente correcto o requerido y no estoy calificado para decidir, pero creo que parece "razonable".

Gracias por la excavación, amigos.

Además, creo que lo que está haciendo # 1474 es demasiado específico; al menos según mi lectura, no establece una versión mínima de Python, sino que especifica una versión exacta. También parece fallar su verificación, usted tiene un 1.0.1 diferente de j, lo que significa que las actualizaciones de seguridad no se aplicarán ni siquiera a 1.0.1, lo que definitivamente es un problema.

Convenido. Suponiendo que OpenSSL 1.0.2 no está de acuerdo con los certificados de boot2docker, esa parte debería al menos ser reparable; buscaré obtener un OpenSSL 1.0.1 actualizado en.

@tdsmith , gracias por la explicación y disculpas por el malentendido. @glyph , gracias por la aclaración.

FWIW, intenté probar la teoría de @tdsmith y generate_cert (es feo, perdóname) para crear valores distintos para Issuer y Subject . Puede parecer que retiene el agua (pero vea las advertencias a continuación). Esto es lo que obtengo cuando ejecuto b2d con certificados generados a partir del actual generate_cert frente a mi versión pirateada:

0.9.8zd funciona con 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 a través de MacPorts) _no_ funciona con 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 con generate_cert pirateados (0.1.1; no es sorprendente)

% /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:: listen_no_evil:: speak_no_evil: con generate_cert pirateado (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

Advertencias

Con el fin de intentar controlar todos los cambios, tenga en cuenta que cuando se lanzó el generate_cert (0.1) original, se creó cuando la imagen golang:1.3-cross Docker utilizada para compilarlo tenía acceso a un paquete llamado ssh . Desde entonces, ese paquete ha sido reemplazado por openssh-client . La versión de OpenSSL utilizada al construir mi generate_cert pirateado es 1.0.1k . Esto parece estar vinculado estáticamente:

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

Por tanto, parece que puede estar pasando una de dos cosas:

• O las últimas versiones de OpenSSL se confunden cuando Issuer == Subject , como sugiere @tdsmith ; o
• Hay algo más sobre la generación de certificados que cambió en OpenSSL, de modo que las versiones posteriores de OpenSSL tienen problemas para validar los certificados generados por las anteriores.

Una forma de probar esto es reconstruir generate_cert sin mi truco, pero con una versión actualizada de OpenSSL. Lo haré a continuación.

Entonces parece que @tdsmith tiene razón. Después de retirar mi truco para asegurar Issuer <> Subject , pero reconstruir generate_cert con la versión más reciente de OpenSSL de golang:1.3-cross , vuelve a fallar con versiones posteriores de OpenSSL en el lado del cliente:

0.9.8zd funciona con generate_cert (0.1.2) con OpenSSL actualizado

% /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 a través de MacPorts) _no_ funciona con generate_cert (0.1.2) con OpenSSL actualizado

% 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

Necesita SvenDowideit / generate_cert # 10. Por cierto, si alguien quiere crear imágenes b2d que apunten a mis generate_cert s pirateados, puede probarlos hasta que se publique una solución oficial.

Si entiendo correctamente, esto _debería_ obviar la necesidad de jugar juegos de la versión OpenSSL / Python en el lado del cliente (al menos con respecto a este problema).

etiquetado @SvenDowideit

He tenido un poco de ida y vuelta con los chicos de OpenSSL. Aquí hay un resumen 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

Cambiar la forma en que b2d genera sus certificados para adaptarse a los clientes de OpenSSL con errores parece muy superior a parchear e instalar OpenSSL en el lado del cliente. Sin embargo, no estoy seguro de qué enfoque específico es más apropiado (¡hacer sujeto! = Emisor frente a incluir SKID / ADID en todos los certificados). Pasaré ese dinero a @SvenDowideit. :sonrisa afectada:

Para los curiosos (de nuevo, no creo que debamos tomar esta ruta), aquí está el parche 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);

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

Espera ... ¿menos estricto? Estoy confundido, ¿cómo falla un cheque _less_ estricto cuando pasa uno más estricto?

Espera ... ¿menos estricto? Estoy confundido, ¿cómo falla un cheque _less_ estricto cuando pasa uno más estricto?

Sí, también tuve problemas con esa elección de idioma. En cuanto a la diferencia, creo que se refiere a barrer incorrectamente más certificados como autofirmados al no realizar tantas comprobaciones (es decir, menos estricto a la hora de determinar qué _no_ califica como autofirmado). Pero estás en lo correcto. Es una expresión extraña.

No he pasado tanto tiempo profundizando en las fuentes OpenSSL, pero las encuentro bastante impenetrables en muchos lugares. Quizás se necesite una mentalidad "especial" para trabajar en ese proyecto. :mueca:

No he pasado tanto tiempo profundizando en las fuentes OpenSSL, pero las encuentro bastante impenetrables en muchos lugares. Quizás se necesite una mentalidad "especial" para trabajar en ese proyecto.

Un eufemismo, creo: guiño:.

En cualquier caso, gracias por comunicarse con la gente de OpenSSL, me alegro de que aquí se resuelva. Mientras tanto, solucionarlo en b2d parece lo correcto. No creo que haya nada que hacer aquí para componer, pero espera.

Como se mencionó aquí , esto soluciona las cosas para mí:

pip install requests[security]

@iffy Eso es una

FYI, PR con corrección enviada como boot2docker / boot2docker # 1029.

La solución para esto (¡gracias @posita!) Está disponible en la última versión de boot2docker. Para actualizar:

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

Eso solucionó el problema para mí. Inténtelo y vuelva a informar.

Alternativamente, cambie a Docker Machine , que ahora viene de serie como parte de la nueva Docker Toolbox .

Sigo teniendo este 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 Tu llamada de docker-compose se está

@tdsmith no es inofensivo para mí, volviendo loco a mi TOC: sonrisa: gracias por el consejo, se actualizará ahora mismo.

La desinstalación de la versión de Python instalada a través de brew resolvió este problema para mí. brew remove --force python

He desinstalado la versión de preparación, pero todavía tengo Python 2.7.10 y todavía tengo el
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) error.

Tengo la siguiente configuración:

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
has resuelto tu problema?

¿Alguien sabe si los chicos de docker-compose están trabajando para resolver el problema, o básicamente no es su problema?

Saludos,

@PavelPolyakov
No. en mis dos Mac (10.9.xy 10.10.x), he intentado varias cosas sin cambios. No creo que esto sea docker-compose y más de Python FWIW.

@chiefy
Estoy de acuerdo, pero no he encontrado ninguna variante de cómo hacerlo funcionar :(

Parece que todos ya han resuelto este problema, pero yo no :)

Instalé Python usando brew una vez, y creo que eliminé el del sistema, por lo que no tengo la opción de volver al anterior.

He intentado instalar Docker mediante varias variantes:

1. desde binario (descargando la caja de herramientas de la ventana acoplable)
2. de la propia cerveza

sin embargo todavía tengo:

¿Alguien tiene una guía completa de cómo superar este comportamiento?

Saludos,

@PavelPolyakov : el error es que boot2docker (y en algunos casos, creo, docker-machine) estaba creando algunos certificados que no se podían usar con el soporte SSL de Python. Si ha actualizado todo su software, pero aún tiene los certificados antiguos defectuosos, las cosas aún estarán dañadas. Entonces, en este punto, recomendaría reaprovisionar cualquier VM de desarrollo que tenga, con una versión actual de docker-machine, para que se aprovisionen nuevos certificados SSL. Esto puede implicar apartar ~/.docker en su host.

@PavelPolyakov y @chiefy , además de los consejos de @glyph , también puedes probar esto (si no quieres reaprovisionar completamente tu entorno 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] es específico para su entorno de VM. Puede haber métodos más fáciles (por ejemplo, vagrant ssh , si está usando Vagrant). Luego reinicie su instancia boot2docker y vea si el error SSL aún ocurre.

@glifo

Gracias por el consejo, para mí no es un problema reaprovisionar la máquina acoplable. Sin embargo, no ayuda.

Cuando instalo docker & co con:
brew install docker docker-machine docker-compose

Entonces, no se crea la máquina default . Y no tengo idea de cómo crearlo usando docker-machine create .

Cuando instalo docker-toolbelt usando el archivo * .pkg, se crea la máquina, pero tengo un error de SSL.
Incluso he intentado hacer:

docker-machine regenerate-certs default

Pero eso no ayuda.

@posita
Gracias también por el consejo.
En su guía, sugiere mv ~/.docker ~/.docker-bak - ¿por qué razón? Tan pronto como hacemos esto, no podemos iniciar la máquina nuevamente, porque los archivos se mueven.
Sí, puedo iniciar sesión en la máquina y eliminar tls/* , luego apagarla, pero ¿cómo volver a iniciarla?

¿Cómo reaprovisionarlo desde cero?

@todas
¿Cuál es su forma de instalar docker (con docker-compose en funcionamiento), es a través de brew install o mediante toolbelt .pkg?
¿Cómo puedo estar seguro de que los certificados que están en mi máquina acoplable son válidos y útiles para Python? ¿Cómo puedo actualizar Python y openssl aún más que brew can, etc.?

Gracias por ayudar.

Saludos,

@PavelPolyakov - docker-machine no tiene la noción de una máquina "predeterminada". Puede ejecutar docker-machine create --driver virtualbox my-docker-machine .

@PavelPolyakov Una vez que hayas hecho eso, debes hacer eval "$(docker-machine env my-docker-machine)" , o lo que sea que hayas elegido para llamar a tu máquina de desarrollo local.

@glifo
Correcto, esa era la parte que faltaba para ejecutar todo desde brew . He aprovisionado con éxito la máquina con el nombre default (lo mismo que se hace durante la instalación desde * .pkg).

Sin embargo, como de costumbre, termino con:

:(

En su guía, sugiere mv ~ / .docker ~ / .docker-bak, ¿por qué motivo? Tan pronto como hacemos esto, no podemos iniciar la máquina nuevamente, porque los archivos se mueven.

@PavelPolyakov , no estoy seguro. No uso docker-machine . Estaba adivinando basándome en otros entornos. Haga caso omiso si esto no funciona.

Sí, puedo iniciar sesión en la máquina y eliminar tls/* , luego apagarla, pero ¿cómo volver a iniciarla?

¿ docker-machine restart no funciona?

Mi comentario se basó en mi propia experiencia al ejecutar boot2docker con Vagrant. Puede que no se aplique muy bien a docker-machine . Parece que @glyph tiene más experiencia con ese entorno. Probaría sus sugerencias.

¿Cuál es su forma de instalar docker (con docker-compose en funcionamiento), es a través de brew install o mediante toolbelt .pkg?

Esto está un poco fuera del alcance de este problema (que trata específicamente con un problema de certificado con boot2docker como se manifiesta en docker-compose ), pero en OS X, utilizo las compilaciones binarias .

@PavelPolyakov , ¿qué sucede cuando haces lo siguiente?

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

¿Cuál es la versión de boot2docker que se muestra cuando hace lo siguiente?

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

Siéntase libre de reemplazar shiny-new-machine-74d5a19e con lo que desee, siempre que no haga referencia a una instancia existente (es decir, el nombre no debería aparecer cuando haga docker-machine ls antes de ejecutar los comandos anteriores .).

@posita

Hmmm ....: confundido: @PavelPolyakov , ¿qué te da esto?

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
Gracias porque sigues ayudando.

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

He intentado hacer lo mismo en diferentes máquinas OSX.
Con todas las últimas actualizaciones (sistemas operativos y paquetes brew), y enfrentó el mismo problema con SSL.

@PavelPolyakov , estoy viendo esto de su openssl s_client ... dump:

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

Estos no son los valores predeterminados de boot2docker , que (ahora) deberían ser:

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

Sin saber más, supongo que docker-machine está sobrescribiendo los valores predeterminados (de alguna manera) cuando aprovisiona la máquina virtual. Pero la llamada openssl parece haber funcionado, por lo que no estoy seguro de que esto sea un problema y no entiendo por qué docker-compose fallaría. :aturdido:

¿Cuál es su salida para lo siguiente?

(
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

Esto debería crear un archivo como ~/Desktop/docker-compose-890-outerr-2015-09-18T14:45:29Z.txt adecuado para pegar / cargar.

@posita
Aquí está:
http://pastebin.com/vWqZgVKi

Estoy bastante seguro de que esto no tiene nada que ver con su problema, pero sus versiones docker-compose y docker-py están atrasadas. Estos son los últimos lanzamientos:

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

Además (y podría estar malinterpretando esto), parece que sus ca.pem y cert.pem comparten lo mismo Subject (que fue la causa del boot2docker problema, pero viniendo de la otra dirección). Dado que estos certificados parecen ser creados / mantenidos por docker-machine , sospecho que el problema está ahí. Encontré docker / machine # 1335 y docker / machine # 1767, que pueden estar relacionados, pero ninguno parece estar directamente en el punto.

FWIW, estoy usando docker-compose (instalado a través de pip en un virtualenv ) con OpenSSL y Python 2.7 instalados desde MacPorts. Esa versión de OpenSSL está sujeta al problema identificado en este problema (y se solucionó con la actualización a boot2docker ). Para mí, esta combinación funciona sin problemas con boot2docker 1.8.1+ y Vagrant (mi Vagrantfile encarga de copiar los certificados boot2docker al host a través de alguna magia de aprovisionamiento):

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

Me doy cuenta de que es posible que no tenga esa opción. Solo lo publico para ayudar a aclarar las diferencias, lo que puede ayudar a diagnosticar su problema. Compare lo anterior con sus certificados creados por 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
...

Tenga en cuenta que Subject de ca.pem es lo mismo que Subject de cert.pem .

No creo que su problema sea un problema con docker-compose . ( @aanand , ¿quizás pueda comentar?) nuevo problema para la ventana acoplable / máquina . Me gustaría hacer referencia a este, comenzando por su comentario inicial .

Si decide presentar un nuevo problema para la ventana acoplable / máquina , considere agregar dónde hay algo interesante en /var/log/docker.log o /var/log/boot2docker.log en su instancia de VM. Por ejemplo, intente esto:

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

O:

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

Conseguir esto en OSX el capitain,

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

Hola @DaveBlooman ,

solo por curiosidad, ¿también tienes Python y otras cosas instaladas usando brew? O al revés.
¿Y tiene el error exacto al hacer docker-compose build ?

A través de homebrew, Python 2.7.10

Así que definitivamente algo se lleva a cabo debido a la brew :(

@DaveBlooman , consulte también docker / machine # 1910. Si pueden reproducir el problema de @PavelPolyakov , ¿tal vez ustedes dos puedan colaborar en un diagnóstico?

Tuve el mismo problema y se debió al hecho de que tenía una conexión vpn abierta por otra aplicación (Astrill en mi caso) que probablemente estaba estropeando algo con la configuración de la red. Espero que esto pueda ayudar a alguien más que tenga el mismo problema.

Recibo errores en 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 versión 0.5.0
versión de docker-compose: 1.5.0

todo instalado a través de Homebrew

@anthonygreen , parece un problema sustancialmente diferente. No veo el mismo mensaje de error que se está discutiendo aquí. Parece que los usuarios de Homebrew están experimentando una cantidad sustancial de problemas no relacionados con este. Considere presentar un nuevo número.

No he leído toda esta publicación, pero vi el mismo error en una configuración reciente en OS X Yosemite usando 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

Resulta que tenía un conjunto de variables de entorno CURL_CA_BUNDLE personalizado (con algunos certificados internos personalizados), y desarmar esta var env antes de ejecutar docker-compose le permitió superar el error [SSL: CERTIFICATE_VERIFY_FAILED] .

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

editar: oops, quería comentar aquí https://github.com/docker/machine/issues/1880

@pmahoney , ¡gracias por

$ CURL_CA_BUNDLE= docker-compose up

@posita Establecer la var env a la cadena vacía da como resultado advertencias:

$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

Aunque no obtengo el error SSL.

@pmahoney , interesante. Por lo tanto, parece que un CURL_CA_BUNDLE configurado pero vacío tiene una semántica diferente (es decir, una anulación nula) que no configurarlo en absoluto (que probablemente se ve en una ubicación predeterminada). Intenté encontrar esto en el comportamiento en los documentos, pero no tuve éxito. Lo más cercano que encontré fue esto .

@neilsarkar ¡ mi problema también era Charles proxy ejecutándose! ¡Gracias!

oh Dios, también tengo CURL_CA_BUNDLE personalizado en las dos máquinas donde estaba probando.

Gracias

erf nada para mí, ninguna variable CURL_CA_BUNDLE :(
Así que traté de establecer un valor sin éxito en absoluto, pero si configuro un CURL_CA_BUNDLE en nada (CURL_CA_BUNDLE =), entonces tengo una advertencia como dijo @pmahoney y funciona, pero mi terminal iluminó totalmente los mensajes de advertencia.
Espero que haya una mejor solución para mí :)

Si sabe cuál es el buen valor para la variable CURL_CA_BUNDLE, lo tomo :)

Gracias

Tuve el mismo problema con webkit-patch. Al mirar los documentos de Python en el módulo SSL / TLS , ssl.get_default_verify_paths() nos muestra dónde Python / OpenSSL espera un archivo de certificado de CA. Entonces, si ejecuta esto en su terminal:

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

Deberíamos ver que sin SSL_CERT_FILE configurado, el módulo SSL de Python espera un archivo de certificado CA en /usr/local/ssl/cert.pem (para aquellos que instalaron OpenSSL en /usr/local/ssl ). Entonces, configura SSL_CERT_FILE en un archivo de certificado con certificados de CA raíz o coloca un archivo con certificados de CA raíz en /usr/local/ssl/cert.pem . Si necesita los certificados de la CA raíz, descargue curl y en el árbol de origen ejecute lib/mk-ca-bundle.pl y se generará un archivo ca-bundle.crt. Puedo confirmar que la configuración SSL_CERT_FILE funcionará con OpenSSL 1.0.2d con Python 2.7.11 y Python 3.5.0.

@grahamc ¿ docker-compose

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

No, solo tuve que abandonar los hosts de Docker remotos, desafortunadamente :(

Acabo de tener este problema donde CURL_CA_BUNDLE causó que docker-compose fallara con:

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

mientras que docker estaba funcionando bien. Sería bueno que docker-compose ignorara la variable ambiental o al menos registrara una advertencia de que no usará los certificados esperados.

@buckett , considere presentar un nuevo problema para agregarlo como una solicitud de función. Considere también presentar un problema hermano con docker-py y haga que se refieran entre sí. No estoy seguro de qué capa sería la más apropiada.

editar: Nuevo número creado # 3114

¿Todos han solucionado esto todavía? Sigo recibiendo el mismo error. Mi docker-compose version es:

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

Esto es lo que obtuve 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)

Instalé docker, docker-mahine y docker-compose a través de la caja de herramientas de Docker.

He intentado todas las sugerencias anteriores pero no tuve suerte. No tengo experiencia en docker así que no pude resolverlo por mí mismo.

¿Alguien tiene una causa raíz o una solución a esto? Lo estoy viendo en compose 1.7.0 con una versión más reciente de openssl.
Todo esto está construido y ejecutado desde alpine, por lo que el entorno debe 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
en mi caso, fue causado por la variable CURL_CA_BUNDLE env redefinida. También debe verificar si tiene tal caso.

@PavelPolyakov revisa mi volcado env ... no CURL_CA_BUNDLE

@PavelPolyakov está bien, esto es extraño, explícitamente desactivé esa variable env y funcionó, a pesar de no estar en mi entorno.

@jmmills eh ... lo mismo aquí. ¿Tal vez Python trata el conjunto como vacío de manera diferente a desarmado?

Mac OS, homebrew docker-compose y docker-machine, usando system python. Máquina recién creada con: docker-machine create --driver=vmwarefusion --vmwarefusion-memory-size 1536 dev

env | grep CURL no devuelve nada
docker-compose ps devoluciones

ERROR: Error de SSL: el nombre de host '172.16.129.133' no coincide con 'localhost'

CURL_CA_BUNDLE='' docker-compose ps devuelve:

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

Tuve exactamente lo mismo: CURL_CA_BUNDLE no se estaba configurando en mi entorno, y configurarlo en una cadena vacía me dio el mismo resultado que @inanimatt.

Definitivamente huele a un error de subida, supongo que sería un código de compatibilidad de entorno para curl, en el que "definido" y "vacío" se tratan de forma diferente.

Gracias,
Jason Mills

• enviado desde el móvil.

El 24 de abril de 2016, a las 6:14 a.m., Alex Wilson [email protected] escribió:

Tuve exactamente lo mismo: CURL_CA_BUNDLE no se estaba configurando en mi entorno, y configurarlo en una cadena vacía me dio el mismo resultado que @inanimatt.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub

Solo parece afectar la versión homebrew: instalar homebrew Python y luego instalar docker-compose a través de pip resuelve todos los errores.

El 24 de abril de 2016, a las 14:14, Alex Wilson [email protected] escribió:

Tuve exactamente lo mismo: CURL_CA_BUNDLE no se estaba configurando en mi entorno, y configurarlo en una cadena vacía me dio el mismo resultado que @inanimatt.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub

Creo que pegué la replicación del problema en Linux anteriormente. Puedo comprobarlo mañana cuando esté en una estación de trabajo

Gracias,
Jason Mills

• enviado desde el móvil.

El 24 de abril de 2016, a las 12:22 p.m., Matt Robinson [email protected] escribió:

Solo parece afectar la versión homebrew: instalar homebrew Python y luego instalar docker-compose a través de pip resuelve todos los errores.

El 24 de abril de 2016, a las 14:14, Alex Wilson [email protected] escribió:

Tuve exactamente lo mismo: CURL_CA_BUNDLE no se estaba configurando en mi entorno, y configurarlo en una cadena vacía me dio el mismo resultado que @inanimatt.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub

El mismo problema aquí desde que actualicé docker-compose a la versión 1.7 usando 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

Vaciar el tipo de var CURL_CA_BUNDLE env resuelve el 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
------------------------------------------------------------

La degradación a 1.6.2 también resuelve el 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
------------------------------------------------------------

En lugar de deshabilitar el CURL_CA_BUNDLE, puede ejecutarlo usando:
CURL_CA_BUNDLE = ~ / .docker / machine / machines / default / ca.pem docker-compose ps

Probablemente no soy el primero que ha mencionado esto, pero ¿no es contrario a la intuición que una variable de entorno curl tenga algún efecto en una aplicación de Python no relacionada?

Gracias,
Jason Mills

• enviado desde el móvil.

El 7 de mayo de 2016, a las 3:22 p.m., Lorenzo Sicilia [email protected] escribió:

En lugar de deshabilitar el CURL_CA_BUNDLE, puede ejecutarlo usando:
CURL_CA_BUNDLE = ~ / .docker / machine / machines / default / ca.pem docker-compose ps

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub

Me encontré con este problema y el problema fue con la variable de entorno REQUESTS_CA_BUNDLE que apunta a una ubicación personalizada para certificados autofirmados. Encase esto ayuda a cualquiera.

• Michael Housh

@aboutlo Esto funciona - no funcionó con otro archivo ca.pem , solo con este. También estoy en Windows, así que tengo una configuración más vudú, ¡gracias!

La desinstalación de ndg-httpsclient (con pip, era la versión 0.4.0) resolvió el problema para mí, vea mi publicación aquí: https://github.com/docker/compose/issues/3365

Depuraé docker-compose y docker-py y descubrí que debería usar variables de entorno u opciones en el comando. No debes mezclar estos. Si incluso especifica --tls en el comando, deberá especificar todas las opciones como el objeto TLSConfig, ya que ahora el objeto TLSConfig se crea completamente a partir de las opciones del comando y opera el objeto TFSConfig creado a partir de la variable de entorno.

@ m-housh ¡Dios mío, gracias por ese consejo! ¡A mí me pasó exactamente lo mismo! Se eliminó REQUESTS_CA_BUNDLE de mi entorno y me resolvió este problema.

Me he encontrado con el mismo problema. Primero pensé que es porque las diferencias de versión de OpenSSL (Pyhton tenía 1.0.2 pero OS tenía 0.9.8) las hice ambas 1.0.2 pero todavía no funcionó.
He resuelto mi problema simplemente ssh to docker y luego verifico mi certificado en claves autorizadas y actualizándolo. Curiosamente, de alguna manera, era un certificado incorrecto.

Siga estos pasos por favor:

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

Compruebe si este certificado es realmente el certificado de su computadora. Si no, copie el suyo en este archivo y guárdelo. Entonces simplemente ejecuta:

docker-compose up

Esto funcionó para mí y espero que ayude.

Preparación de problemas: parece haber una variedad de modos de falla diferentes y escenarios de error / mala configuración del usuario (todos en gran parte históricos) descritos aquí.

No veo nada que parezca apuntar a un problema activo en curso en la redacción, así que voy a cerrar el problema. Si todavía está viendo a un error relacionado con las versiones modernas, por favor, abrir una nueva emisión con todos los detalles de su escenario, etc.