Je pense que je vis la même chose en essayant d'utiliser le candidat à la version docker-compose ...

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

Mais fig fonctionne bien ...

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

Je suis sous OSX, j'utilise toutes les mêmes versions que go1.3.3 . Mon python / openssl est également installé via Homebrew. Cela pourrait-il avoir quelque chose à voir avec ça?

Edit: En fait, il semble que Homebrew ne lie pas openssl, donc j'utilise la version OSX par défaut: OpenSSL 0.9.8za 5 Jun 2014 .

Le problème était le python Homebrew.

docker-compose fonctionne maintenant après la désinstallation de l'homebrew python / openssl, l'installation de pip avec easy_install et la réinstallation de docker-composer utilisant le système python.

@adambiggs Votre solution fonctionne! Merci!

Cela a fonctionné pour moi aussi, j'utilise un tout nouveau mac et je le configure avec homebrew python. Avait cette erreur avec fig communiquant avec docker. J'ai suivi les conseils de

Cela m'arrive aussi. Et je ne veux pas utiliser le python du système, quelqu'un a une autre solution de contournement?

Avez-vous essayé d'utiliser le binaire? Avez-vous le même problème?

Non, je n'ai pas essayé le binaire.
Si vous ne souhaitez pas l'installer dans vos systèmes python, une autre solution de contournement consiste à utiliser virtualenv (wrapper).

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

Nous avons trouvé une meilleure solution en utilisant pyenv pour revenir à python 2.7.8:

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

Edit: Nevermind, pyenv introduit un tas de ses propres problèmes ...

Ce qui a causé cette erreur pour moi, c'est que l'openssl home-brew n'était pas lié à / usr / local / bin / openssl.

openssl version

a renvoyé OpenSSL 0.9.8zc le 15 octobre 2014 pas OpenSSL 1.0.1j le 15 octobre 2014

Fonctionnement

brew link --force openssl

et la réinstallation de fig a résolu le problème.

Intéressant, mais ma version OpenSSL est

@aanand dans mon cas, le binaire n'a pas ce problème.

J'ai eu cette erreur lorsque j'ai installé fig via pip, pas homebrew. sudo pip uninstall fig et brew install fig corrigé pour moi.

+1 pour la solution @NotBobTheBuilder , a également fonctionné pour moi

: +1: pour @NotBobTheBuilder

@NotBobTheBuilder belle solution pour fig, mais docker-compose n'est malheureusement pas encore disponible sur homebrew.

@ocasta qu'en est-il de cet avertissement effrayant de l'homebrew sur la liaison d'OpenSSL?

Cette formule est uniquement en fût.
Mac OS X fournit déjà ce logiciel et installe une autre version dans
parallèle peut causer toutes sortes de problèmes.

Apple a abandonné l'utilisation d'OpenSSL au profit de ses propres bibliothèques TLS et cryptographiques

Thumbs up @NotBobTheBuilder - Cela a aussi résolu le

quelqu'un connaît la source de ce problème? ça m'arrive avec la figue. Je préfère m'en tenir à pip install fig comme je l'ai maintenant. Tout a bien fonctionné il y a quelques semaines, je ne sais pas ce qui a changé sur mon système

Mon système OpenSSL est OpenSSL 0.9.8zc 15 Oct 2014 , mon homebrew openssl est plus récent mais pas lié.

... Je suppose que cela s'est cassé lorsque j'ai mis à niveau vers Python 2.7.9, il semble qu'il y ait des bogues liés à SSL avec cela ... ressemble beaucoup à ceci:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196431
http://bugs.python.org/issue23052

exécuter brew link --force openssl et réinstaller fig n'a rien fait pour moi.

La fig a-t-elle besoin d'une mise à jour pour contourner les changements SSL dans Py 2.7.9?
https://www.python.org/dev/peps/pep-0476/#opting -out

J'utilise boot2docker. Je viens de passer à la version 1.5.0 mais aucun changement.

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}

Le code fig semble correct, il tente d'utiliser les certificats installés par boot2docker ... Je suppose que ces certificats sont corrects car ils fonctionnaient toujours et j'ai juste mis à jour b2d pour qu'ils n'aient pas dû expirer.

Hmm, mon Python (installé via homebrew) semble utiliser la version homebrew d'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

... exécuter /usr/local/opt/openssl/bin/c_rehash n'a pas aidé :)

J'ai essayé une version précédemment installée de python (2.7.8_2) via $ brew switch python 2.7.8_2 avec le même problème (même si le message d'erreur était légèrement différent). La version python 2.7.9 ne semble donc pas être le problème.

Ensuite, j'ai essayé de passer à une ancienne version openssl, de 1.0.2 à 1.0.1j_1, qui semble fonctionner.

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

Pour moi, j'obtiens simplement une erreur différente, mais cela aide peut-être à préciser ce qui ne va pas:

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

Revenir à OpenSSL 1.0.2 produit l'erreur CERTIFICATE_VERIFY_FAILED précédente, donc changer de version a certainement un effet

Une solution de contournement consiste à exécuter docker-compose dans un conteneur:

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

Cela nécessite d'exposer le port 2376 dans VirtualBox:

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

La réponse de @kretz a fonctionné pour moi.

+1 interrupteur d' infusion @kretz openssl 1.0.1j_1
fait le tour

brew switch openssl 1.0.1j fonctionne pour moi (notez le manque de _1)

Je n'aime pas ça, mais désinstaller fig de mon virtualenv et installer via homebrew a corrigé des choses pour moi

Merci @kretz - votre réponse l'a résolu pour moi!

Cela ne fonctionne pas pour moi car:

$ 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

Ma solution de contournement était de créer un virtualenv avec python 2.7.8, plutôt que le 2.7.9 que j'ai obtenu de brew.

diverses solutions de contournement ... est-ce que quelqu'un a un aperçu du vrai problème?

qu'est-ce que App Engine a à voir avec quoi que ce soit?

Le 11 mars 2015 à 18h09, Ryan Small [email protected] a écrit:

Je suis à peu près sûr qu'aucun des éléments du moteur d'application ne fonctionne avec python 2.7.9

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/docker/compose/issues/890#issuecomment -78329652.

@anentropic Vous devez installer l'ancienne version openssl avant de pouvoir l'utiliser (basculer vers).

# 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

J'ai fait brew install openssl101 mais cela ne m'a pas donné la possibilité de passer à 1.0.1j ... cela m'a donné un 1.0.1l et je craignais que cela ne perturbe mon système depuis ce sont des paquets de bière séparés et j'avais déjà 1.0.2 en parallèle

n'a pas semblé aider mais peut-être que je ne suis pas allé assez loin avec ça

Désolé, j'ai répondu au mauvais problème de github (j'ai rapidement supprimé mon commentaire)
Le mer 11 mars 2015 à 11h30 anentropic [email protected]
a écrit:

J'ai fait brew install openssl101 mais cela ne m'a pas donné la possibilité de
passer à 1.0.1j ... cela m'a donné un 1.0.1l et je craignais qu'il ne
confondre mon système car ce sont des paquets de bière séparés et j'avais déjà
1.0.2 en parallèle

n'a pas semblé aider mais peut-être que je ne suis pas allé assez loin avec ça

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/docker/compose/issues/890#issuecomment -78340580.

Il semble donc que je reçoive également ce problème, sous Mac OSX. En utilisant docker-compose, c'est mon fichier .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

Lors de l'exécution de docker-compose pull j'obtiens la sortie suivante qui a échoué.

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

J'ai vérifié certaines choses.
which openssl; openssl version

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

@psykzz devrait fonctionner si vous installez avec brew

brew install docker-compose

@arvindtest qu'est-ce qui vous fait penser que c'est lié à ce problème?

Pour info, après avoir beaucoup lutté avec cela, il semble que ce soit un problème de boot2docker.
Ce qui a fonctionné pour moi, c'est de désactiver TLS. Il n'existe pas encore de moyen convivial de le faire, mais les instructions sont décrites ici:
https://github.com/deis/deis/issues/2230

Fondamentalement, vous devez:

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

puis redémarrez boot2docker, ie
arrêt boot2docker
démarrage de boot2docker

et quelque chose comme ça dans votre ~ / .bashrc (assurez-vous que l'adresse IP est correcte)

export DOCKER_HOST = tcp: //192.168.59.103 : 2375
désactiver DOCKER_CERT_PATH
désactiver DOCKER_TLS_VERIFY

Dans votre bashrc, pourquoi ne pas simplement avoir $ (boot2docker shellinit)

Devrait aider avec tout ce qu'il faut?

Je veux dire que vous devez toujours faire la solution TLS.
Le 21 mars 2015 à 23h05, "coderfi" [email protected] a écrit:

Pour info, après avoir beaucoup lutté avec ça, il semble que ce soit un
problème boot2docker.
Ce qui a fonctionné pour moi, c'est de désactiver TLS. Il n'y a pas encore de moyen convivial
pour ce faire, mais les instructions sont décrites ici:
deis / deis # 2230 https://github.com/deis/deis/issues/2230

Fondamentalement, vous devez:

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

puis redémarrez boot2docker, ie
arrêt boot2docker
démarrage de boot2docker

et quelque chose comme ça dans votre ~ / .bashrc
assurez-vous que l'adresse IP est correcte

export DOCKER_HOST = tcp: //192.168.59.103 : 2375
désactiver DOCKER_CERT_PATH
désactiver DOCKER_TLS_VERIFY

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/docker/compose/issues/890#issuecomment -84468058.

@kretz ça marche! Merci.

@psykzz voulez-vous dire $(boot2docker shellinit) ?

oui je l'ai fait, mis à jour mon commentaire. derp.

Je peux confirmer que la solution de @coderfi pour désactiver TLS fonctionne pour moi!

Heureux que cela fonctionne pour vous. :)

@Matt oui, vous avez raison sur le conseil d'expansion du shell init.
Cependant, cela peut ne pas fonctionner si boot2docker n'a pas encore démarré, donc je viens de
a rendu l'exemple explicite.

Fi
Le 26 mars 2015 à 10 h 18, "anentropic" [email protected] a écrit:

Je peux confirmer que la solution de @coderfi https://github.com/coderfi pour
désactiver TLS fonctionne pour moi!

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/docker/compose/issues/890#issuecomment -86630313.

C'est peut-être évident, mais ceux qui désactivent TLS ou rétrogradent OpenSSL juste pour que cela fonctionne devraient faire preuve de prudence en fonction de ce qu'ils font.

Cela ne concernera pas tout, mais une erreur similaire s'est produite lors des installations de pip utilisant un Dockerfile tirant de gliderlabs/alpine:3.1 - le conteneur Linux minimal de progrium & crew. Le problème était que je n'avais pas installé le package de certificats système, le problème a été résolu en installant le package avant d'installer pip et en exécutant le fichier des exigences:

RUN apk-install -X ca-certificates

Les sollutions suggérées n'ont pas vraiment fonctionné pour moi. Impossible de passer à l'une des versions 1.0.1 d'OpenSSL. En fin de compte, j'ai trouvé que la désinstallation de toutes les versions de docker-compose installées par pip et le simple fait brew install docker-compose faire brew install docker-compose autre.

Les solutions ci-dessus ont fonctionné mais étaient trop lourdes pour moi. Un rapide boot2docker upgrade tout réglé de mon côté.

J'ai déjà la dernière version de boot2docker et cela ne fonctionne pas pour moi sans les correctifs ci-dessus

Les développeurs de Homebrew suggèrent que docker-py et docker-compose devraient passer à l'utilisation de requests 2.6.0

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

Espérons que cela aide quelqu'un ... pas sûr d'une solution, mais si vous utilisez Charles comme proxy Mac OS X, cela provoquera ce message.

FWIW, l'installation de docker-compose via pip a fait fonctionner docker-compose lui-même (l'installation via curl sur OS X Mavericks a entraîné une erreur illegal operation ). Par la suite, j'ai également reçu l'erreur SSL. Lancer brew link --force openssl && brew switch openssl 1.0.1j semble l'avoir résolu pour moi.

@rseymour réponse a fonctionné pour moi

Pour ceux qui ne parviennent pas à trouver openssl-1.0.1j dans brew - vous pouvez récupérer une ancienne version de la recette openssl à partir du dépôt github et l'utiliser:

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

J'ai essayé 1.0.1m mais cela n'a pas fonctionné.
J'ai donc essayé @lazyval façon, ça marche pour moi.
C'est ce que j'ai fait.

brew install https://raw.githubusercontent.com/Homebrew/homebrew/62fc2a1a65e83ba9dbb30b2e0a2b7355831c714b/Library/Formula/openssl.rb
interrupteur d'infusion openssl 1.0.1j_1
brew unlink openssl101 // Parce que j'ai lié 1.0.1m avant cela
lien de brassage openssl --force
docker-compose ps

Je vous remercie!!

J'étudie actuellement ceci, car nous devons maintenant construire les binaires sur Python 2.7.9+.

_Déplacé de # 1427_

Serveur:

• CoreOS stable
• Docker 1.5.0

Client:

• CentOS 6.6, 64 bits
• noyau 2.6.32-042stab105.14
• Client Docker 1.5.0
• docker-compose 1.2.0
• Certificats SSL placés à ~/.docker/{ca.pem,cert.pem,key.pem}
• DOCKER_HOST=tcp://docker-builder:2376
• DOCKER_TLS_VERIFY=1

Utilisation du Makefile suivant pour créer les certificats 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

Voici le script de données utilisateur (certes moins qu'idéal) pour provisionner cette machine:

#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

En utilisant le client docker j'ai bien réussi à accéder au serveur Docker distant. Nous appelons le serveur distant jusqu'à cent mille fois par jour avec un bon succès.

En essayant d'utiliser docker-compose , installé soit via curl OU pip install --upgrade avec python 2.7, nous obtenons une erreur SSL:

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

C'est le cas après avoir spécifié manuellement DOCKER_CERT_PATH=/home/user/.docker/ ainsi que REQUESTS_CA_BUNDLE=/home/user/.docker/ca.pem , individuellement et ensemble.

Pour être clair: cette configuration fonctionne très bien avec juste le démon docker, mais quelque chose à propos de -compose ne va pas.

Quelques notes:

1. Le binaire Compose 1.3.0 RC1 pour OSX a ce bogue. Probablement pas par hasard, c'est la première fois qu'il est construit avec Python 2.7.9 - avant, c'était 2.7.6.
2. Bizarrement, je peux reproduire contre une VM boot2docker, mais pas contre une VM Virtualbox provisionnée par Machine. @ehazlett , @nathanleclaire , @tianon - des idées là-bas?
3. À toute personne confrontée à ce problème lorsque Compose est installé avec Pip, veuillez signaler la sortie des commandes suivantes:

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

Sur ma machine locale, où je peux reproduire l'erreur, j'ai Python 2.7.10 et OpenSSL 1.0.2a 19 Mar 2015 .

1. Cela a été rapporté à Homebrew, et certaines personnes disent avoir réussi à réinstaller Python et OpenSSL, mais cela n'a pas fonctionné pour moi. https://github.com/Homebrew/homebrew/issues/38226

Hmm c'est vraiment étrange. Quelle version de b2d utilisez-vous par rapport à la version
de machine? Nous utilisons tous les deux b2d donc je ne sais pas ce qui serait différent
outre la version.

Je vais installer via pip sur ma machine OS X et voir ce que j'obtiens.

Le jeu 28 mai 2015 à 9h19, Aanand Prasad [email protected]
a écrit:

Quelques notes:

1.

Le binaire Compose 1.3.0 RC1 pour OSX a ce bogue. Probablement pas
par coïncidence, c'est la première fois qu'il est construit avec Python 2.7.9

• avant, c'était 2.7.6.
  2.

Bizarrement, je peux reproduire contre une VM boot2docker, mais pas contre un
Virtualbox VM provisionnée par la machine. @ehazlett
https://github.com/ehazlett , @nathanleclaire
https://github.com/nathanleclaire , @tianon
https://github.com/tianon - des informations là-bas?
3.

À toute personne confrontée à ce problème lorsque Compose est installé avec Pip, veuillez
signaler la sortie des commandes suivantes:

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

Sur ma machine locale, où je peux reproduire l'erreur, j'ai Python
2.7.10 et OpenSSL 1.0.2a 19 mars 2015.
4.

Cela a été signalé à Homebrew, et certaines personnes disent avoir
succès de la réinstallation de Python et d'OpenSSL, mais cela n'a pas fonctionné pour moi.
Homebrew / homebrew # 38226
https://github.com/Homebrew/homebrew/issues/38226

-
Répondez directement à cet e-mail ou affichez-le sur 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)

Y a-t-il quelque chose de différent dans la génération de certificats, peut-être? Je semble avoir plus de fichiers dans mon répertoire de cert machine que dans mon répertoire 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

C'est bon. Le client utilisera simplement ca.pem, cert.pem et key.pem
(le serveur est juste une copie locale de l'hôte dans la machine). Je vais créer comme
et inspectez les certificats pour voir quelle pourrait être la différence.

Le jeu.28 mai 2015 à 9h30, Aanand Prasad [email protected]
a écrit:

Version de $ boot2docker
Version de Boot2Docker-cli: v1.6.2
Commit Git: cb2c3bc

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

Y a-t-il quelque chose de différent dans la génération de certificats, peut-être? Il me semble avoir plus
fichiers dans mon répertoire de certificat de machine que dans mon boot2docker.

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

-
Répondez directement à cet e-mail ou affichez-le sur 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

Voir également https://github.com/docker/docker-py/issues/465. Le script de test de @garethr reproduit l'erreur pour moi aussi, après avoir fait une modification pour désactiver la vérification du nom d'hôte:

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)

Cela fonctionne toujours avec la machine virtuelle approvisionnée par la machine, cependant:

$ 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 je réactive la vérification du nom d'hôte (en commentant la ligne assert_hostname dans le script de test), elle échoue avec la même erreur contre la machine virtuelle boot2docker-cli, mais une erreur différente contre la machine virtuelle machine, qui peut ou peut ne pas être pertinent:

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

De plus, j'ai essayé d'utiliser v1.3.0-rc1 via curl (la version binaire, pas via pip) et j'ai eu la même erreur que précédemment sur un démon docker 1.6.2:

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

Ouais - le binaire RC1 a été construit avec Python 2.7.9 et OpenSSL 1.0.2a, ce qui semble être l'une des combinaisons problématiques.

Cela a du sens car je pense que la génération de cert dans b2d est sur la VM
alors que la machine les génère en machine. Nous pourrions détecter et ajouter le
nom de la machine aux SAN si nécessaire. En fait, ce serait probablement bien
en particulier pour les VM b2d. La raison pour laquelle ça marche maintenant, je pense, c'est parce que tu
accéder au moteur en utilisant l'adresse IP que la machine ajoute en tant que SAN IP. Il y a un
PR ouvert pour autoriser des SAN supplémentaires arbitraires qui fonctionneraient également.

Le jeudi 28 mai 2015, Aanand Prasad [email protected] a écrit:

Voir aussi docker / docker-py # 465
https://github.com/docker/docker-py/issues/465. @garethr
Le script de test de https://github.com/garethr reproduit l'erreur pour
moi aussi, après avoir fait une modification pour désactiver la vérification du nom d'hôte:

depuis docker.client import Clientfrom docker.utils import kwargs_from_env

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

client = client (** kwargs) impression client.version ()

$ eval "$ (boot2docker shellinit)" && python test.py
Écriture /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
Écriture /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
Écriture /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem
Traceback (dernier appel le plus récent):
Fichier "test.py", ligne 8, dans
print client.version ()
Fichier "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", ligne 1108, dans la version
retourne self._result (self._get (url), json = True)
Fichier "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", ligne 106, dans _get
retourne self.get (url, * _self._set_request_timeout (kwargs))
Fichier "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", ligne 477, dans get
return self.request ('GET', url, * _kwargs)
Fichier "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", ligne 465, dans la requête
resp = self.send (prep, * _send_kwargs)
Fichier "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", ligne 573, dans send
r = adapter.send (requête, * _kwargs)
Fichier "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", ligne 431, dans send
lever SSLError (e, request = request)
demandes.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] vérification du certificat a échoué (_ssl.c: 590)

Cela fonctionne toujours avec la machine virtuelle approvisionnée par la machine, cependant:

$ 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 je réactive la vérification du nom d'hôte (en commentant l'assert_hostname
ligne dans le script de test), il échoue avec la _même erreur_ contre le
boot2docker-cli VM, mais une _ erreur différente_ contre la machine VM, qui
peut être pertinent ou non:

Traceback (dernier appel le plus récent):
Fichier "test.py", ligne 8, dans
print client.version ()
Fichier "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", ligne 1108, dans la version
retourne self._result (self._get (url), json = True)
Fichier "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", ligne 106, dans _get
retourne self.get (url, * _self._set_request_timeout (kwargs))
Fichier "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", ligne 477, dans get
return self.request ('GET', url, * _kwargs)
Fichier "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", ligne 465, dans la requête
resp = self.send (prep, * _send_kwargs)
Fichier "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", ligne 573, dans send
r = adapter.send (requête, * _kwargs)
Fichier "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", ligne 431, dans send
lever SSLError (e, request = request)
request.exceptions.SSLError: aucun champ commonName ou subjectAltName approprié n'a été trouvé

-
Répondez directement à cet e-mail ou affichez-le sur GitHub
https://github.com/docker/compose/issues/890#issuecomment -106363305.

OK, je crois que je suis arrivé à un correctif pour OS X: https://github.com/docker/compose/pull/1474

La fixation pour Linux implique la mise à jour du Dockerfile à la broche à Python 2.7.9 et OpenSSL 1.0.1, qui sera un effort amusant donné commence à partir de debian:wheezy (ce qu'il fait pour assurer que nous utilisons une suffisamment ancienne glibc - voir https://github.com/docker/compose/pull/505).

Le passage à 1.0.1k comme décrit dans le commentaire de @kretz et l'installation de 1.3.0 RC1 via pip ont fait l'affaire pour moi.

Avant de changer de python, rapportait la version 1.0.2a:

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

Après avoir changé, il a signalé 1.0.1k et docker-compose semble fonctionner comme prévu:

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

une solution de contournement qui a supprimé cette erreur était d'installer les packages suivants dans mon virtualenv
pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7

Dans l'environnement décrit sur https://github.com/docker/compose/issues/890#issuecomment -106289821 qui fournit Python 2.7.6 (via snap-ci.com, sur lequel vous pouvez obtenir un compte gratuit sur)

avec le script suivant qui utilise la solution de contournement de @ jsh2134 dans une installation 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

J'obtiens la sortie suivante:

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

Notez surtout l'erreur (qui semble nouvelle):

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

Créé https://github.com/docker/compose/issues/1484 pour faire un brain-dump de mes découvertes jusqu'à présent.

J'ai construit des binaires avec le correctif dans # 1474. Veuillez les essayer si vous rencontrez des problèmes 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 pourquoi

+1 pour la réponse @kretz :)

+1 même problème: (semble que docker est complètement cassé sur osx?

La solution

Traiter l'une des erreurs de variante sur une machine virtuelle Centos7, qui agit en tant que client pour démarrer des conteneurs sur une machine docker:

[ root @ xxxx cm] # docker-compose ps
Erreur SSL: aucun champ commonName ou subjectAltName approprié n'a été trouvé

C'était autrefois transitoire; Je pourrais me déconnecter, me reconnecter en ssh et ne pas voir l'erreur pendant un moment. Maintenant, je le vois toujours.

[ racine @ xxxx cm] # python -c 'import ssl; imprimer (ssl.OPENSSL_VERSION) '
OpenSSL 1.0.1e-fips 11 février 2013

[ root @ xxxx cm] # version de docker
Version du client: 1.6.2
Version de l'API client: 1.18
Version Go (client): go1.4.2
Git commit (client): ba1f6c3 / 1.6.2
OS / Arch (client): linux / amd64
Version du serveur: swarm / 0.2.0
Version Go (serveur): go1.3.3
Git commit (serveur): 48fd993
OS / Arch (serveur): linux / amd64

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

Je ne sais pas comment appliquer certains des correctifs mentionnés ci-dessus dans mon environnement. Je n'utilise pas boot2docker; traitant de docker 1.6.2 directement sur la ligne de commande bash.

Bonjour. J'ai en fait ouvert un problème pour cette raison que je ne peux pas le résoudre. J'ai essayé beaucoup de choses, par exemple installer compose avec les versions pip / brew / newst. Identique à openssl a essayé les versions 0.x 1.0.2x, etc. et ne fonctionne toujours pas.

PS: je n'utilise pas boot2docker. J'ai ma propre VM que je crée via vagrant, je génère les certificats et lance le démon docker avec eux. Apparemment, cela fonctionne avec docker, donc le problème ne vient pas de mes certifs.

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

a également eu cette erreur à un moment donné:

/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

Après avoir lu ici et avoir installé les packages suggérés:

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

Le message d'erreur de docker-compose a changé:

[ root @ xxx cm] # docker-compose up -d
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:251: SecurityWarning: le certificat n'a pas de subjectAltName , revenant pour vérifier un commonName pour maintenant. Cette fonctionnalité est supprimée par les principaux navigateurs et obsolète par la RFC 2818 (voir https://github.com/shazow/urllib3/issues/497 pour plus de détails.)
Avertissement de sécurité
Erreur SSL: le nom d'hôte 'xx.xx.xx.xx' ne correspond à aucun

(Le quad en pointillé I xx'd out est de l'hôte de l'essaim maître / docker)

Ce problème pourrait-il également être résolu en modifiant ou en régénérant le certificat?

Addendum: Les certificats ont été créés sur ces VM par "docker-machine create".

Pourrions-nous avoir affaire à un bogue dans docker-machine qui se traduit par un certificat insuffisamment détaillé?

Je ne vois cette erreur qu'avec les hôtes Docker créés par docker-machine. Je pense que les certificats SSL ne sont pas créés correctement?

Quelqu'un a-t-il une solution ou une solution pour résoudre ce problème? C'est un peu un bloqueur pour moi en ce moment: /

@prologic Obtenez -vous l'erreur avec le binaire ou avec un Compose installé par Pip? Si c'est le cas, essayez également d'installer requests[security] .

@aanand Merci! Je vais essayer et vous rapporter si cela fonctionne ou non!

@prologic Nous voulons empaqueter requests[security] au lieu de nous fier au module SSL buggy de Python; nous suivons l'effort dans # 1530.

@aanand Merci! Cela a parfaitement fonctionné :)

@coderfi votre solution a fonctionné pour moi, merci

@aanand la

@neilsarkar J'utilisais le proxy charles, votre commentaire m'a sauvé. : +1:

J'utilise OS X 10.9.5, voici ma sélection:

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

Ma solution de contournement:

commentez les lignes 246: 253 dans
/usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connection.py

c'est la partie qui lance l'exception de sécurité

Le problème pour moi était que même si j'avais spécifié brew link --force openssl, fig / docker-compose utilise toujours / usr / bin / openssl.

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

Cela a fonctionné pour moi. Maintenant, je ne reçois plus le message ennuyeux.

Pour info, la recette brew fig / docker-compose utilise le système python, donc même si vous installez python via pyenv ou brew, brew install fig / docker-compose utilisera toujours la bibliothèque system openssl si disponible, sinon, il installera une autre version.

Sur mon MAC au travail, je l'ai résolu avec pyenv install 2.7.8, puis easy_install pip et pip install docker-compose.

mais sur mon mac à la maison, "les deux exécutant yosemite" j'ai fait la même chose et je reçois toujours l'avertissement.

Continuera à creuser.

@dtunes - la cause racine (comme @aanand référencé ci-dessus) est https://github.com/boot2docker/boot2docker/issues/808. Le truc system-python / homebrew-python est un hareng rouge, car cela dépend juste de savoir si vous êtes lié à un nouvel OpenSSL ou à l'ancien.

Oui, j'ai vu ce billet. Ce qui me dérange, c'est que sur mon Mac au travail, après avoir essayé les différentes approches ci-dessus, aucune n'a fonctionné.
J'ai ensuite déplacé / usr / bin / openssl vers / usr / bin / openssl_old, installé le dernier openssl en utilisant home brew et l'ai lié de force. alors seulement j'ai fait ce qui suit:

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

Cela a fonctionné au travail, mais sur mon Mac à la maison, cela n'a pas fonctionné. Mais j'essaierai à nouveau au cas où je ferais une erreur et rapporterai les résultats.

@dtunes - Afin de reconstruire toutes vos dépendances, vous devez supprimer ~/Library/Caches/pip afin que la roue binaire mise en cache construite contre le mauvais OpenSSL ne soit pas réutilisée.

@glyph a écrit :

la cause principale (comme @aanand référencé ci-dessus) est boot2docker / boot2docker # 808. Le truc system-python / homebrew-python est un hareng rouge, car cela dépend juste de savoir si vous êtes lié à un nouvel OpenSSL ou à l'ancien.

@glyph ou @aanand , cela suggère- t-il que le correctif (contournement) de @aanand fusionné à partir de # 1474 ne contient qu'un b2d cassé? @aanand , si boot2docker / boot2docker # 808 est adressé correctement, # 1474 doit-il être annulé? Placer de l'espoir dans la prochaine version de la cryptographie (voir ceci et cela ) est-il également un hareng rouge?

@aanand a écrit :

Notez que je ne peux pas reproduire cette erreur contre une VM Boot2Docker provisionnée avec docker-machine - cela ne se produit que contre une VM provisionnée avec la commande boot2docker.

@ehazlett a écrit :

Cela a du sens car je pense que la génération de cert dans b2d est sur la machine virtuelle alors que la machine les génère dans la machine.

J'ai peut-être mal compris, mais il y a beaucoup de bavardages qui blâment diverses combinaisons Python / OpenSSL côté hôte pour cela et des problèmes connexes. Si la source du problème est un OpenSSL cassé distribué avec b2d, je ne suis pas sûr que la meilleure approche soit de s'assurer que l'OpenSSL côté hôte de Compose est également cassé? Pour ce que cela vaut, il est peu probable que ces types de contorsions côté hôte résolvent ce problème pour ceux qui exécutent b2d via (par exemple) Vagrant et y accèdent en dehors de Compose (voir, par exemple, docker / docker-py # 465 ).

Si ce commentaire est plus approprié dans boot2docker / boot2docker # 808, je peux le déplacer là-bas.

Je suis un mainteneur de Homebrew et j'ai aidé glyph à gérer cela.

Les DN du sujet et de l'émetteur du certificat de serveur généré par boot2docker sont définis de manière identique sur /O=Boot2Docker . Je crois que le certificat du serveur est en fait signé par le certificat CA, mais AFAICT OpenSSL 1.0.2 utilise ces informations (c'est-à-dire les DN identiques du sujet et de l'émetteur) pour rejeter le certificat du serveur comme auto-signé au lieu de tenter de vérifier le certificat du serveur par rapport à celui fourni. CA cert. Les versions d'OpenSSL antérieures à 1.0.2 valident le certificat de serveur par rapport au certificat CA fourni, ce qui réussit.

Je crois, mais je n'ai pas testé, que donner au serveur et aux certificats CA des DN de sujet distincts (afin que le certificat de serveur ait des DN de sujet et d'émetteur distincts) permettra aux certificats de se valider sous toutes les versions d'OpenSSL. Je soupçonne (d'après ma lecture de ce guide de survie X.509 mais pas de spécifications connexes), mais je ne suis pas convaincu, que le comportement d'OpenSSL 1.0.2 est raisonnable et ne représente pas une régression qui devrait être résolue par les développeurs OpenSSL.

1474 fait deux choses distinctes:

• définir une version minimale de Python à 2.7.9: cela permet à urllib3 de compléter les requêtes sans émettre un InsecurePlatformWarning, qui est émis lors de l'établissement de connexions HTTPS si les deux conditions sont remplies: la version Python est antérieure à 2.7.9 et le module PyOpenSSL n'est pas présent. Le regroupement de PyOpenSSL serait tout aussi efficace, mais je comprends de la discussion qu'il n'est pas compatible avec PyInstaller. Quoi qu'il en soit, InsecurePlatformWarning d'urllib3 n'est pas lié au problème de certificat boot2docker, et la correction des certificats ne supprime pas la nécessité de cette solution de contournement.
• définir une version OpenSSL maximale à 1.0.1j. Je pense que cela devrait être inutile une fois que les certificats boot2docker sont corrigés.

Si la source du problème est un OpenSSL cassé distribué avec b2d

Ce n'est pas; les certificats boot2docker (générés par ce code ) sont invalides selon les clients utilisant OpenSSL ≥ 1.0.2; la bibliothèque OpenSSL distribuée avec boot2docker n'est pas impliquée.

@glyph ou @aanand , cela suggère- t-il que le correctif (contournement) de @aanand fusionné à partir de # 1474 ne contient qu'un b2d cassé? @aanand , si boot2docker / boot2docker # 808 est adressé correctement, # 1474 doit-il être annulé? Placer de l'espoir dans la prochaine version de la cryptographie (voir ceci et cela) est-il également un hareng rouge?

Oui, je pense. Je crois que l'OpenSSL avec le problème est 1.0.2, et en le limitant à 1.0.1, cela éviterait toute logique de vérification qui provoque l'échec du certificat. Je ne sais toujours pas quel est le certificat qu'il n'aime pas, car les messages d'erreur sont si obtus.

De plus, je pense que ce que fait # 1474 est beaucoup trop spécifique; au moins d'après ma lecture, il ne s'agit pas de définir une version _minimum_ de python, mais de spécifier une version _exact_. Il semble également échouer à sa vérification, il se trouve que vous avez une version 1.0.1 différente de j, ce qui signifie que les mises à jour de sécurité ne seront pas appliquées même à la version 1.0.1, ce qui est _definiment_ un problème.

Je crois, mais je n'ai pas testé, que donner au serveur et aux certificats CA des DN de sujet distincts (afin que le certificat de serveur ait des DN de sujet et d'émetteur distincts) permettra aux certificats de se valider sous toutes les versions d'OpenSSL. Je soupçonne (d'après ma lecture de ce guide de survie X.509 mais pas de spécifications connexes), mais je ne suis pas convaincu, que le comportement d'OpenSSL 1.0.2 est raisonnable et ne représente pas une régression qui devrait être résolue par les développeurs OpenSSL.

Je vais enquêter sur le certificat généré par docker-machine et voir s'il possède cette propriété. Pourquoi dites-vous que ce comportement serait acceptable / pas une régression dans OpenSSL? Faire confiance à un certificat auto-signé est parfaitement acceptable, et il n'y a aucune restriction particulière sur ce que le sujet ou l'émetteur peut contenir que je sache. J'ai parcouru un peu ce guide et il semble simplement souligner que les certificats auto-signés n'auront pas la confiance de CA-cartel, donc votre navigateur Web ne leur fera pas confiance sans configuration supplémentaire.

En regardant le certificat dans ma docker-machine VM, je vois:

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

alors vous avez peut-être raison à ce sujet ...

J'examinerai le certificat généré par la machine docker et verrai s'il a [les DN correspondants du sujet et de l'émetteur].

Vous pouvez voir que les certificats docker-machine d'aanand ont également des DN distincts: https://gist.github.com/aanand/3d865623481ba8ae66ee#file -docker-machine-log-L30-L32

Faire confiance à un certificat auto-signé est parfaitement bien

Mais un certificat auto-signé n'est valide que si vous faites confiance au certificat auto-signé. Nous ne demandons pas à OpenSSL de faire confiance au certificat de serveur; nous demandons à OpenSSL de faire confiance à l'autorité de certification qui a émis le certificat de serveur.

Pourquoi dites-vous que ce comportement serait acceptable / pas une régression dans OpenSSL?

IANAL, mais mon raisonnement est dérivé du langage "A un niveau strict [l'auto-signature] signifie que les champs émetteur et sujet du certificat sont les mêmes." C'est le cas du certificat de serveur boot2docker. Lorsque OpenSSL tente de valider le certificat du serveur boot2docker, il est possible de créer une chaîne de confiance complète sans tenir compte du certificat de l'autorité de certification car le certificat de serveur semble être signé par lui-même, mais n'est pas explicitement approuvé et ne peut donc pas être valide. Je ne suis pas convaincu que ce soit un comportement strictement correct ou requis et je ne suis pas qualifié pour décider, mais je pense que cela semble «raisonnable».

Merci pour le creusement, les amis.

De plus, je pense que ce que fait # 1474 est beaucoup trop spécifique; au moins d'après ma lecture, il ne s'agit pas de définir une version minimale de python, mais de spécifier une version exacte. Il semble également échouer à sa vérification, vous avez une version 1.0.1 différente de j, ce qui signifie que les mises à jour de sécurité ne seront pas appliquées même à la version 1.0.1, ce qui est certainement un problème.

D'accord. En supposant que c'est OpenSSL 1.0.2 qui n'est pas d'accord avec les certificats de boot2docker, cette partie devrait au moins être réparable - je vais chercher à obtenir un OpenSSL 1.0.1 à jour dans.

@tdsmith , merci pour l'explication et excuses pour le malentendu. @glyph , merci pour la clarification.

FWIW, j'ai essayé de tester la théorie de l » @tdsmith et piraté generate_cert (il est laid, pardonnez - moi) pour créer des valeurs distinctes pour Issuer et Subject . Il _peut_ sembler retenir l'eau (mais voir les mises en garde ci-dessous). Voici ce que j'obtiens en exécutant b2d avec des certificats générés à partir de la version actuelle de generate_cert rapport à ma version piratée:

0.9.8zd fonctionne avec 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 (installé via MacPorts) ne fonctionne _pas_ avec 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 fonctionne avec generate_cert piraté (0.1.1; pas surprenant)

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

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

1.0.2d _works (!) _: Tada:: see_no_evil:: hear_no_evil:: speak_no_evil: avec piraté generate_cert (0.1.1)

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

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

Mises en garde

Dans l'intérêt d'essayer de contrôler toutes les modifications, notez que lorsque le generate_cert (0.1) original a été publié, il a été construit lorsque l'image golang:1.3-cross Docker utilisée pour la construire avait accès à un package appelé ssh . Ce paquet a depuis été remplacé par openssh-client . La version OpenSSL utilisée lors de la construction de mon generate_cert piraté est 1.0.1k . Cela semble être lié statiquement:

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

Il semble donc que l'une des deux choses suivantes puisse se produire:

• Les versions tardives d'OpenSSL sont confuses lorsque Issuer == Subject , comme le suggère @tdsmith ; ou
• Il y a autre chose à propos de la génération de certificats qui a changé dans OpenSSL de sorte que les versions ultérieures d'OpenSSL ont du mal à valider les certificats générés par les précédentes

Une façon de tester cela est de reconstruire generate_cert sans mon hack, mais avec une version mise à jour d'OpenSSL. Je vais le faire ensuite.

Il semble donc que @tdsmith a raison. Après avoir annulé mon hack pour assurer Issuer <> Subject , mais reconstruire generate_cert avec la nouvelle version d'OpenSSL à partir de golang:1.3-cross , cela revient à échouer avec versions ultérieures d'OpenSSL côté client:

0.9.8zd fonctionne avec generate_cert (0.1.2) avec OpenSSL mis à jour

% /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 (installé via MacPorts) ne fonctionne _pas_ avec generate_cert (0.1.2) avec OpenSSL mis à jour

% 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

Nécessite SvenDowideit / generate_cert # 10. Au fait, si quelqu'un veut créer des images b2d qui pointent vers mes generate_cert s piratés, vous pouvez les essayer jusqu'à ce qu'un correctif officiel soit publié.

Si je comprends bien, cela devrait éviter d'avoir à jouer à des jeux en version OpenSSL / Python côté client (au moins en ce qui concerne ce problème).

balisage @SvenDowideit

J'ai eu un peu de va-et-vient avec les gars d'OpenSSL. Voici un résumé 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

Changer la façon dont b2d génère ses certificats afin de prendre en charge les clients OpenSSL bogués semble bien supérieur à l'application de correctifs et à l'installation d'OpenSSL côté client. Je ne suis pas sûr de l'approche spécifique la plus appropriée (en faisant l'objet! = Émetteur vs en incluant SKID / ADID dans tous les certificats). Je vais passer cet argent à @SvenDowideit. :petit sourire satisfait:

Pour les curieux (encore une fois, je ne pense pas que nous devrions emprunter cette voie), voici le patch 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);

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

Attendez ... _less_ strict? Je ne sais pas comment une vérification stricte _less_ échoue là où une vérification plus stricte réussit?

Attendez ... _less_ strict? Je ne sais pas comment une vérification stricte _less_ échoue là où une vérification plus stricte réussit?

Ouais, j'ai également eu des problèmes avec ce choix de langue. En regardant le diff, je pense qu'il veut dire balayer incorrectement plus de certificats comme auto-signés en n'effectuant pas autant de contrôles (c'est-à-dire, moins stricts pour déterminer ce qui ne peut pas être qualifié d'auto-signé). Mais tu as raison. C'est un tour de phrase étrange.

Je n'ai pas passé beaucoup de temps à me plonger dans les sources OpenSSL, mais je les trouve assez impénétrables dans de nombreux endroits. Peut-être faut-il un état d'esprit «spécial» pour travailler sur ce projet. :sourire:

Je n'ai pas passé beaucoup de temps à me plonger dans les sources OpenSSL, mais je les trouve assez impénétrables dans de nombreux endroits. Peut-être faut-il un état d'esprit «spécial» pour travailler sur ce projet.

Un euphémisme, je pense: wink:.

Dans tous les cas, merci d'avoir contacté les gens d'OpenSSL, heureux ici, cela sera résolu là-bas. En attendant, contourner ce problème dans b2d semble être la bonne chose à faire. Je ne pense pas qu'il y ait quelque chose à faire ici mais attendez.

Comme mentionné ici , cela corrige les choses pour moi:

pip install requests[security]

@iffy C'est un hareng rouge; il le corrige probablement pour vous parce que vous aviez une roue binaire mise en cache qui était liée à un OpenSSL différent.

FYI, PR avec le correctif soumis en tant que boot2docker / boot2docker # 1029.

Le correctif pour cela (merci @posita!) Est disponible dans la dernière version de boot2docker. Mettre à niveau:

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

Cela a résolu le problème pour moi. Veuillez l'essayer et faire un rapport.

Vous pouvez également passer à Docker Machine , qui fait désormais partie de la nouvelle boîte à outils Docker .

J'ai toujours ce problème ...

❯ 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 Votre appel docker-compose réussit; l'avertissement que vous voyez est inoffensif. Vous devez mettre à niveau vers OS X 10.10.5 si vous préférez éviter de le voir.

@tdsmith pas inoffensif pour moi, rendant fou mon TOC: sourire: merci pour le conseil, va mettre à niveau tout de suite.

La désinstallation de la version python installée via brew a résolu ce problème pour moi. brew remove --force python

J'ai désinstallé la version brew, mais j'ai toujours Python 2.7.10 et j'ai toujours le
Erreur SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) .

J'ai la configuration suivante:

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
avez-vous résolu votre problème?

anybode sait-il si les gars de docker-compose travaillent pour résoudre le problème, ou ce n'est fondamentalement pas leur problème?

Cordialement,

@PavelPolyakov
non. sur mes deux mac (10.9.x et 10.10.x), j'ai essayé diverses choses sans changement. Je ne pense pas que ce soit une chose docker-compose et plus de chose Python FWIW.

@chiefy
Je suis d'accord, mais je n'ai trouvé aucune variante pour le faire fonctionner :(

On dirait que tout le monde a déjà résolu ce problème, mais pas moi :)

J'ai installé python en utilisant brew une fois, et je pense avoir supprimé celui du système, donc je n'ai pas la possibilité de revenir à l'ancien.

J'ai essayé d'installer docker par plusieurs variantes:

1. depuis le binaire (téléchargement de la boîte à outils docker)
2. du brassage lui-même

cependant j'ai toujours:

Quelqu'un a-t-il un guide complet sur la façon de surmonter ce comportement?

Cordialement,

@PavelPolyakov - Le bogue est que boot2docker (et dans certains cas, je pense, docker-machine) construisait des certificats qui étaient inutilisables par le support SSL de python. Si vous avez mis à niveau tous vos logiciels mais que vous avez toujours les mauvais anciens certificats, les choses seront toujours cassées. Donc, à ce stade, je recommanderais de réapprovisionner les VM de développement que vous avez, avec une version actuelle de docker-machine, afin que les nouveaux certificats SSL soient provisionnés. Cela peut impliquer de déplacer ~/.docker sur votre hôte.

@PavelPolyakov et @chiefy , en plus des conseils de @glyph , vous pouvez également essayer ceci (si vous ne voulez pas réapprovisionner complètement votre environnement 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] est spécifique à votre environnement de VM. Il peut y avoir des méthodes plus simples (par exemple, vagrant ssh , si vous utilisez Vagrant). Redémarrez ensuite votre instance boot2docker et voyez si l'erreur SSL persiste.

@glyphe

Merci pour les conseils, pour moi ce n'est pas un problème de réapprovisionner la docker-machine. Cependant, cela n'aide pas.

Lorsque j'installe docker & co avec:
brew install docker docker-machine docker-compose

Ensuite, la machine default n'est pas créée. Et je n'ai aucune idée de comment le créer en utilisant docker-machine create .

Lorsque j'installe docker-toolbelt en utilisant le fichier * .pkg, la machine est créée, mais j'ai une erreur SSL.
J'ai même essayé de faire:

docker-machine regenerate-certs default

Mais ça n'aide pas.

@posita
Merci aussi pour les conseils.
Dans votre guide, vous suggérez de mv ~/.docker ~/.docker-bak - pour quelle raison? Dès que nous faisons cela, nous ne pouvons pas redémarrer la machine, car les fichiers sont déplacés.
Oui, je peux me connecter à la machine et supprimer tls/* , puis l'arrêter, mais comment la redémarrer?

Comment le réapprovisionner à partir de zéro?

@tout
Comment installez-vous docker (avec docker-compose), est-ce via brew install ou via toolbelt .pkg?
Comment puis-je être sûr que les certificats qui se trouvent sur ma machine docker sont valides et utiles par python, comment puis-je mettre à niveau python et openssl encore plus que brew can, etc.?

Merci pour ton aide.

Cordialement,

@PavelPolyakov - docker-machine n'a pas la notion de machine "par défaut". Vous pouvez exécuter docker-machine create --driver virtualbox my-docker-machine .

@PavelPolyakov Une fois que vous avez fait cela, vous devez faire eval "$(docker-machine env my-docker-machine)" , ou ce que vous avez choisi d'appeler votre machine de développement locale.

@glyphe
Correct, c'était la partie manquante de tout exécuter à partir de brew . J'ai provisionné avec succès la machine avec le nom default (le même que celui qui est fait lors de l'installation à partir de * .pkg).

Cependant, comme d'habitude, je termine par:

:(

Dans votre guide, vous suggérez de mv ~ / .docker ~ / .docker-bak - pour quelle raison? Dès que nous faisons cela, nous ne pouvons pas redémarrer la machine, car les fichiers sont déplacés.

@PavelPolyakov , je ne suis pas sûr. Je n'utilise pas docker-machine . Je devinais basé sur d'autres environnements. Veuillez ignorer si cela ne fonctionne pas.

Oui, je peux me connecter à la machine et supprimer tls/* , puis l'arrêter, mais comment la redémarrer?

Est-ce que docker-machine restart ne fonctionne pas?

Mon commentaire était basé sur ma propre expérience avec l'exécution de boot2docker avec Vagrant. Cela peut ne pas s'appliquer très bien à docker-machine . On dirait que @glyph a plus d'expérience avec cet environnement. J'essaierais ses suggestions.

Comment installer docker (avec docker-compose), est-ce via brew install ou via toolbelt .pkg?

Cela sort un peu du cadre de ce problème (qui traite spécifiquement d'un problème de certificat avec boot2docker comme manifesté dans docker-compose ), mais sous OS X, j'utilise les versions binaires .

@PavelPolyakov , que se passe-t-il lorsque vous faites ce qui suit?

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

Quelle est la version de boot2docker qui s'affiche lorsque vous effectuez les opérations suivantes?

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

N'hésitez pas à remplacer shiny-new-machine-74d5a19e par ce que vous voulez, tant qu'il ne fait pas référence à une instance existante (c'est-à-dire que le nom ne devrait pas déjà apparaître lorsque vous faites docker-machine ls avant d'exécuter les commandes ci-dessus .).

@posita

Hmmm ....: confus: @PavelPolyakov , qu'est-ce que cela vous donne?

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
Merci de continuer à aider.

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

J'ai essayé de faire la même chose sur la machine OSX différente.
Avec toutes les dernières mises à jour (packages OS et Brew), et confronté au même problème avec SSL.

@PavelPolyakov , je regarde ceci depuis votre openssl s_client ... dump:

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

Ce ne sont pas les valeurs par défaut de boot2docker , qui devraient (maintenant) être:

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

Sans en savoir plus, je suppose que docker-machine écrase les valeurs par défaut (d'une manière ou d'une autre) lorsqu'il provisionne la machine virtuelle. Mais l'appel openssl semble avoir fonctionné, donc je ne suis pas sûr que ce soit un problème, et je ne comprends pas pourquoi docker-compose échouerait. : confondu:

Quelle est votre sortie pour ce qui suit?

(
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

Cela devrait créer un fichier comme ~/Desktop/docker-compose-890-outerr-2015-09-18T14:45:29Z.txt adapté au collage / téléchargement.

@posita
C'est ici:
http://pastebin.com/vWqZgVKi

Je suis presque sûr que cela n'a rien à voir avec votre problème, mais vos versions docker-compose et docker-py sont en retard. Voici les dernières versions:

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

De plus (et je pourrais peut-être mal lire ceci), il semble que vos ca.pem et cert.pem partagent le même Subject (qui était la cause du boot2docker problème, mais venant de l'autre sens). Puisque ces certificats semblent être créés / maintenus par docker-machine , je soupçonne que le problème est là? J'ai trouvé docker / machine # 1335 et docker / machine # 1767, qui peuvent être liés, mais aucun ne semble être directement sur le point.

FWIW, j'utilise docker-compose (installé via pip dans un virtualenv ) avec OpenSSL et Python 2.7 installés à partir de MacPorts. Cette version d'OpenSSL est soumise au problème identifié dans ce problème (et contourné par la mise à jour vers boot2docker ). Pour moi, cette combinaison fonctionne sans problème avec boot2docker 1.8.1+ et Vagrant (mon Vagrantfile gère la copie des certificats boot2docker vers l'hôte grâce à une magie de provisionnement):

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

Je sais que vous n'avez peut-être pas cette option. Je le publie simplement pour éclairer les différences, ce qui peut aider à diagnostiquer votre problème. Comparez ce qui précède avec vos certificats créés par 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
...

Notez que Subject de ca.pem est le même que le Subject de cert.pem .

Je ne pense pas que votre problème soit un problème avec docker-compose . ( @aanand , peut-être pouvez-vous commenter?) Étant donné que ce problème est assez encombré, envisagez de déposer un nouveau problème pour docker / machine . Je ferais référence à celui-ci en commençant par votre commentaire initial .

Si vous décidez de déposer un nouveau problème pour docker / machine , pensez à ajouter là où il y a quelque chose d'intéressant dans /var/log/docker.log ou /var/log/boot2docker.log sur votre instance de VM. Par exemple, essayez ceci:

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

Ou:

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

Obtenir ceci sur OSX el capitain,

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

Salut @DaveBlooman ,

juste curieux, avez-vous également installé python et des trucs avec brew? Ou l'inverse.
Et avez-vous l'erreur exacte en faisant docker-compose build ?

Via homebrew, Python 2.7.10

Il se passe donc quelque chose à cause du brew :(

@DaveBlooman , voir aussi docker / machine # 1910. Si vous pouvez reproduire le problème de

J'ai eu le même problème et c'était dû au fait que j'avais une connexion VPN ouverte assise par une autre application (Astrill dans mon cas) qui gâchait probablement quelque chose avec la configuration du réseau. J'espère que cela peut aider quelqu'un d'autre qui a le même problème.

J'obtiens des erreurs sur 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 version 0.5.0
version de docker-compose: 1.5.0

tous installés via Homebrew

@anthonygreen , cela ressemble à un problème sensiblement différent. Je ne vois pas le même message d'erreur que ce qui est discuté ici. Il semble que les utilisateurs de Homebrew rencontrent un nombre important de problèmes sans rapport avec celui-ci. Veuillez envisager de soumettre un nouveau numéro.

Je n'ai pas lu l'intégralité de cet article, mais j'ai vu la même erreur sur une configuration récente sur OS X Yosemite à l'aide de 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

Il s'avère que j'avais une variable d'environnement personnalisée CURL_CA_BUNDLE définie (avec quelques certificats internes personnalisés), et la désactivation de cette variable d'environnement avant d'exécuter docker-compose lui a permis de dépasser l'erreur [SSL: CERTIFICATE_VERIFY_FAILED] .

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

edit: oups, destiné à commenter ici https://github.com/docker/machine/issues/1880

@pmahoney , merci de l'avoir fait savoir au reste d'entre nous! Je n'aurais jamais deviné ça. Pour info, vous pouvez probablement aussi faire quelque chose comme ça (si vous ne voulez pas le sous-shell):

$ CURL_CA_BUNDLE= docker-compose up

@posita La définition de la

$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

Bien que je n'obtienne pas l'erreur SSL.

@pmahoney , intéressant. Donc, il ressemble à un ensemble mais vide CURL_CA_BUNDLE a une sémantique différente (c'est-à-dire, un remplacement nul) que de ne pas le définir du tout (ce qui ressemble probablement à un emplacement par défaut). J'ai essayé de trouver cela dans le comportement dans les documents, mais sans succès. La chose la plus proche que j'ai trouvée était celle-ci .

@neilsarkar mon problème était aussi le fonctionnement du proxy Charles! Je vous remercie!

oh mon dieu, j'ai aussi CURL_CA_BUNDLE personnalisé sur les deux machines sur lesquelles je testais.

Merci

euh rien pour moi, pas de variable CURL_CA_BUNDLE :(
J'ai donc essayé de le définir sur une valeur sans succès du tout, mais si je définis un CURL_CA_BUNDLE sur rien (CURL_CA_BUNDLE =), alors j'ai un avertissement comme @pmahoney l'a dit et cela fonctionne mais mon terminal est totalement flod par les messages d'avertissement.
J'espère qu'il y a une meilleure solution pour moi :)

Si vous savez quelle est la bonne valeur de la variable CURL_CA_BUNDLE, je la prends :)

THX

J'ai eu le même problème avec webkit-patch. En regardant les documents python sur le module SSL / TLS , le ssl.get_default_verify_paths() nous montre où Python / OpenSSL attend un fichier de certificat CA. Donc, si vous exécutez ceci dans votre terminal:

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

nous devrions voir que sans SSL_CERT_FILE défini, le module SSL de Python attend un fichier de certificat CA à /usr/local/ssl/cert.pem (pour ceux qui ont installé OpenSSL sur /usr/local/ssl ). Donc, soit, vous définissez SSL_CERT_FILE sur un fichier de certificat avec des certificats CA racine, soit vous placez un fichier avec des certificats CA racine à /usr/local/ssl/cert.pem . Si vous avez besoin des certificats de l'autorité de certification racine, téléchargez curl et dans l'arborescence des sources, exécutez lib/mk-ca-bundle.pl et un fichier ca-bundle.crt sera généré. Je peux confirmer que le paramètre SSL_CERT_FILE fonctionnera avec OpenSSL 1.0.2d avec Python 2.7.11 et Python 3.5.0.

@grahamc Avez-vous résolu le problème? J'ai une configuration similaire à la vôtre qui fonctionne très bien avec le démon docker distant mais échoue avec docker-compose

L'erreur que j'obtiens est ERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

Non, j'ai juste dû abandonner les hôtes docker distants, malheureusement :(

Je viens d'avoir ce problème où CURL_CA_BUNDLE causé l'échec de docker-compose avec:

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

tandis que docker fonctionnait bien. Il serait bon que docker-compose ignore la variable d'environnement ou au moins enregistre un avertissement indiquant qu'il n'utilisera pas les certificats attendus.

@buckett , envisagez de déposer un nouveau problème pour l'ajouter en tant que demande de fonctionnalité. Envisagez également de déposer un problème de sœur avec docker-py et demandez-leur de se référencer. Je ne sais pas quelle couche serait la plus appropriée.

edit: Création d'un nouveau numéro # 3114

Tout le monde a-t-il encore résolu ce problème? Je reçois toujours la même erreur. Mon docker-compose version est:

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

Voici ce que j'ai obtenu 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)

J'ai installé docker, docker-mahine et docker-compose via la boîte à outils de Docker.

J'ai essayé toutes les suggestions ci-dessus mais pas de chance. Je n'ai aucune expérience dans docker donc je n'ai pas pu le comprendre moi-même.

Quelqu'un a-t-il une cause fondamentale ou une solution de contournement à ce sujet? Je le vois dans compose 1.7.0 avec une nouvelle version openssl.
Tout cela est construit et géré à partir d'alpin, donc l'environnement doit être pur:

/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
dans mon cas, cela a été causé par la variable CURL_CA_BUNDLE env redéfinie. Vous devriez également vérifier si vous avez un tel cas.

@PavelPolyakov vérifie mon vidage d'environnement ... non CURL_CA_BUNDLE

@PavelPolyakov ok c'est étrange, j'ai explicitement annulé cette variable env et cela a fonctionné, même si je ne suis pas dans mon environnement.

@jmmills hein… pareil ici. Peut-être que python traite set-as-empty différemment de unset?

Mac OS, homebrew docker-compose et docker-machine, utilisant le système python. Machine nouvellement créée avec: docker-machine create --driver=vmwarefusion --vmwarefusion-memory-size 1536 dev

env | grep CURL ne renvoie rien
docker-compose ps retours

ERREUR: Erreur SSL: le nom d'hôte '172.16.129.133' ne correspond pas à 'localhost'

CURL_CA_BUNDLE='' docker-compose ps renvoie:

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

J'ai eu exactement la même chose - CURL_CA_BUNDLE n'était pas défini dans mon env, et le définir sur une chaîne vide m'a donné le même résultat que @inanimatt.

Cela sent certainement comme un bogue en amont, je suppose que ce serait un code de compatibilité d'environnement pour curl, dans lequel «défini» et «vide» sont traités différemment.

Merci,
Jason Mills

• envoyé depuis un mobile.

Le 24 avril 2016, à 6 h 14, Alex Wilson [email protected] a écrit:

J'ai eu exactement la même chose - CURL_CA_BUNDLE n'était pas défini dans mon env, et le définir sur une chaîne vide m'a donné le même résultat que @inanimatt.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub

Ne semble affecter que la version homebrew - installer homebrew Python puis installer docker-compose via pip résout toutes les erreurs.

Le 24 avril 2016, à 14:14, Alex Wilson [email protected] a écrit:

J'ai eu exactement la même chose - CURL_CA_BUNDLE n'était pas défini dans mon env, et le définir sur une chaîne vide m'a donné le même résultat que @inanimatt.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub

Je crois que j'ai collé la réplication du problème sous Linux plus tôt. Je peux vérifier demain sur un poste de travail

Merci,
Jason Mills

• envoyé depuis un mobile.

Le 24 avril 2016 à 12 h 22, Matt Robinson [email protected] a écrit:

Ne semble affecter que la version homebrew - installer homebrew Python puis installer docker-compose via pip résout toutes les erreurs.

Le 24 avril 2016, à 14:14, Alex Wilson [email protected] a écrit:

J'ai eu exactement la même chose - CURL_CA_BUNDLE n'était pas défini dans mon env, et le définir sur une chaîne vide m'a donné le même résultat que @inanimatt.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub

Même problème ici depuis que j'ai mis à jour docker-compose vers la version 1.7 en utilisant 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

Vider le type de var env CURL_CA_BUNDLE résout le problème:

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 mise à niveau vers la version 1.6.2 résout également le problème.

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

Plutôt que de désactiver CURL_CA_BUNDLE, vous pouvez exécuter en utilisant:
CURL_CA_BUNDLE = ~ / .docker / machine / machines / default / ca.pem docker-compose ps

Je ne suis probablement pas le premier à avoir évoqué cela, mais n'est-il pas contre-intuitif qu'une variable d'environnement curl ait un effet quelconque sur une application Python non liée?

Merci,
Jason Mills

• envoyé depuis un mobile.

Le 7 mai 2016, à 15 h 22, Lorenzo Sicilia [email protected] a écrit:

Plutôt que de désactiver CURL_CA_BUNDLE, vous pouvez exécuter en utilisant:
CURL_CA_BUNDLE = ~ / .docker / machine / machines / default / ca.pem docker-compose ps

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail ou affichez-le sur GitHub

J'ai rencontré ce problème et le problème était avec la variable d'environnement REQUESTS_CA_BUNDLE pointant vers un emplacement personnalisé pour les certificats auto-signés. Encase cela aide tout le monde.

• Michael Housh

@aboutlo Cela fonctionne - cela ne fonctionnait pas avec d'autres fichiers ca.pem , uniquement avec celui-ci. Je suis aussi sous Windows donc j'ai une configuration plus vaudou, merci!

La désinstallation de ndg-httpsclient (avec pip - était la version 0.4.0) a résolu le problème pour moi, voir mon message ici: https://github.com/docker/compose/issues/3365

J'ai débogué docker-compose et docker-py et j'ai compris que vous devriez utiliser des variables d'environnement ou des options dans la commande. Vous ne devriez pas les mélanger. Si vous spécifiez même --tls dans la commande, vous devrez spécifier toutes les options comme objet TLSConfig, car maintenant l'objet TLSConfig est créé complètement à partir des options de commande et exploite l'objet TFSConfig créé à partir de la variable d'environnement.

@ m-housh OMG merci pour cette astuce! Il m'est arrivé exactement la même chose! Suppression de REQUESTS_CA_BUNDLE de mon environnement et cela a résolu ce problème pour moi.

J'ai rencontré le même problème. Tout d'abord, je pensais que c'était parce que les différences de version d'OpenSSL (Pyhton avait 1.0.2 mais OS avait 0.9.8) je les ai faites toutes les deux 1.0.2 mais cela ne fonctionnait toujours pas.
J'ai résolu mon problème simplement en ssh vers docker, puis en vérifiant mon certificat dans les clés autorisées et en le mettant à jour. Il est intéressant de noter que c'était là un mauvais certificat.

Suivez ces étapes s'il vous plaît:

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

Vérifiez si ce certificat est vraiment le certificat de votre ordinateur. Sinon, copiez simplement le vôtre dans ce fichier et enregistrez-le. Ensuite, lancez simplement:

docker-compose up

Cela a fonctionné pour moi et j'espère que cela aide.

Traitement des problèmes: il semble y avoir une variété de modes de défaillance différents et de scénarios d'erreur / mauvaise configuration utilisateur (tous en grande partie historiques) décrits ici.

Je ne vois rien qui semble indiquer un problème actif en cours dans la composition, donc je ferme le numéro. Si vous voyez encore une erreur liée avec les versions modernes puis ouvrez une nouvelle émission avec tous les détails de votre scénario , etc.