Ich glaube, ich erlebe das Gleiche beim Versuch, den Release-Kandidaten docker-compose ...

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

Aber fig funktioniert gut ...

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

Ich arbeite unter OSX und verwende dieselben Versionen wie @gkostyanikov , außer dass meine Go-Client-Version go1.3.3 . Mein Python / openssl wird auch über Homebrew installiert. Könnte etwas damit zu tun haben?

Bearbeiten: Eigentlich sieht es so aus, als würde Homebrew openssl nicht verknüpfen, daher verwende ich die Standard-OSX-Version: OpenSSL 0.9.8za 5 Jun 2014 .

Das Problem war Homebrew Python.

docker-compose funktioniert jetzt nach der Deinstallation von Homebrew Python / OpenSL, der Installation von pip mit easy_install und der Neuinstallation von docker-composer mit der Systempython.

@adambiggs Deine Lösung funktioniert! Vielen Dank!

Das hat auch bei mir funktioniert, ich benutze einen brandneuen Mac und richte ihn mit Homebrew Python ein. Hatte diesen Fehler mit fig Kommunikation mit Docker. Befolgen Sie den @ adambiggs- Rat wörtlich und kommen Sie an meinem Blocker vorbei. Es könnte auch ein Problem mit der Python-Version sein, aber unabhängig davon, ob dieser Computer für eine Weile Systempython verwendet.

Das passiert auch bei mir. Und ich möchte nicht die Python des Systems verwenden, hat jemand eine andere Problemumgehung?

Haben Sie versucht, die Binärdatei zu verwenden? Hast du das gleiche Problem?

Nein, ich habe die Binärdatei nicht ausprobiert.
Wenn Sie es nicht in Ihrem Systempython installieren möchten, können Sie auch virtualenv (Wrapper) verwenden.

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

Mit pyenv eine bessere Lösung gefunden, um ein Rollback auf Python 2.7.8 durchzuführen:

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

Edit: Nevermind, pyenv hat eine Reihe seiner eigenen Probleme eingeführt ...

Was diesen Fehler für mich verursacht hat, war, dass das selbstgebraute openssl nicht mit / usr / local / bin / openssl verknüpft war.

openssl version

zurückgegeben OpenSSL 0.9.8zc 15. Oktober 2014 nicht OpenSSL 1.0.1j 15. Oktober 2014

Laufen

brew link --force openssl

Durch die Neuinstallation von fig wurde das Problem behoben.

Interessant, aber meine OpenSSL-Version ist OpenSSL 1.0.1j, 15. Oktober 2014

@aanand in meinem Fall hat die Binärdatei dieses Problem nicht.

Ich habe diesen Fehler erhalten, als ich Feige durch Pip installiert hatte, nicht Homebrew. sudo pip uninstall fig und brew install fig es für mich behoben.

+1 für die @ NotBobTheBuilder- Lösung hat auch bei mir funktioniert

: +1: für @NotBobTheBuilder

@NotBobTheBuilder schöne Lösung für Feigen, aber Docker-Compose ist auf Homebrew leider noch nicht verfügbar.

@ocasta was ist mit dieser beängstigend klingenden Warnung von Homebrew über die Verknüpfung von OpenSSL?

Diese Formel ist nur für Fässer geeignet.
Mac OS X bietet diese Software bereits an und installiert eine andere Version in
Parallel kann alle Arten von Problemen verursachen.

Apple hat die Verwendung von OpenSSL zugunsten seiner eigenen TLS- und Kryptobibliotheken abgelehnt

Daumen hoch @NotBobTheBuilder - Das hat es auch bei mir behoben.

Kennt jemand die Ursache dieses Problems? es passiert mir mit fig. Ich halte mich lieber an pip install fig wie jetzt. Vor ein paar Wochen hat alles gut funktioniert. Ich weiß nicht, was sich auf meinem System geändert hat

Mein System OpenSSL ist OpenSSL 0.9.8zc 15 Oct 2014 , mein Homebrew openssl ist neuer, aber nicht verknüpft.

... Ich vermute, es ist kaputt gegangen, als ich auf Python 2.7.9 aktualisiert habe. Es scheint einige SSL-bezogene Fehler zu geben ... sieht sehr ähnlich aus:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196431
http://bugs.python.org/issue23052

brew link --force openssl laufen zu lassen und fig neu zu installieren hat nichts für mich getan.

Muss fig aktualisiert werden, um die SSL-Änderungen in Py 2.7.9 zu umgehen?
https://www.python.org/dev/peps/pep-0476/#opting -out

Ich benutze boot2docker. Ich habe gerade ein Upgrade auf 1.5.0 durchgeführt, aber keine Änderung.

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}

Der Feigencode sieht korrekt aus, es wird versucht, die von boot2docker installierten Zertifikate zu verwenden ... Ich gehe davon aus, dass diese Zertifikate in Ordnung sind, da sie immer funktionierten und ich gerade b2d aktualisiert habe, damit sie nicht abgelaufen sein sollten.

Hmm, mein Python (installiert über Homebrew) scheint die Homebrew-Version von OpenSSL zu verwenden:

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

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

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

... /usr/local/opt/openssl/bin/c_rehash laufen zu lassen hat nicht geholfen :)

Ich habe eine zuvor installierte Version von Python (2.7.8_2) über $ brew switch python 2.7.8_2 mit demselben Problem ausprobiert (auch wenn die Fehlermeldung etwas anders war). Die Python 2.7.9-Version scheint also nicht das Problem zu sein.

Dann habe ich versucht, zu einer älteren openssl-Version von 1.0.2 auf 1.0.1j_1 zu wechseln, was zu funktionieren scheint.

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

Für mich bekomme ich nur einen anderen Fehler, aber vielleicht hilft es, einzugrenzen, was falsch ist:

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

Das Zurückschalten auf OpenSSL 1.0.2 führt zu dem vorherigen Fehler CERTIFICATE_VERIFY_FAILED , sodass das Ändern von Versionen definitiv einige Auswirkungen hat

Eine Problemumgehung besteht darin, Docker-Compose in einem Container auszuführen:

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

Dazu muss Port 2376 in VirtualBox verfügbar gemacht werden:

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

@kretz 'Antwort hat bei mir funktioniert.

+1 @kretz Brühschalter
machte den Trick

Der Brühschalter openssl 1.0.1j funktioniert bei mir (beachten Sie das Fehlen von _1)

Ich mag es nicht, aber das Deinstallieren von fig von meiner virtuellen Umgebung und das Installieren über Homebrew hat für mich behoben

Danke @kretz - deine Antwort hat es für mich gelöst!

Es funktioniert bei mir nicht, weil:

$ 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

Meine Problemumgehung bestand darin, eine virtuelle Umgebung mit Python 2.7.8 zu erstellen, anstatt mit 2.7.9, die ich von Brew erhalten habe.

verschiedene Problemumgehungen ... hat jemand Einblick in das eigentliche Problem?

Was hat App Engine mit irgendetwas zu tun?

Am 11. März 2015 um 18:09 schrieb Ryan Small [email protected] :

Ich bin mir ziemlich sicher, dass keines der App-Engines mit Python 2.7.9 funktioniert

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/compose/issues/890#issuecomment -78329652.

@anentropic Sie müssen die ältere openssl-Version installieren, bevor Sie sie verwenden (zu ihr wechseln) können.

# 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

Ich habe brew install openssl101 aber es gab mir nicht die Möglichkeit, zu 1.0.1j zu wechseln ... es gab mir 1.0.1l und ich befürchtete, dass es mein System seitdem verwirren würde Es sind separate Brühpakete und ich hatte bereits 1.0.2 parallel

schien nicht zu helfen, aber vielleicht ging ich nicht weit genug damit

Entschuldigung, ich habe auf das falsche Github-Problem geantwortet (mein Kommentar wurde schnell gelöscht)
Am Mittwoch, den 11. März 2015 um 11:30 Uhr anentropic [email protected]
schrieb:

Ich habe openssl101 installiert, aber es gab mir nicht die Möglichkeit dazu
Wechseln Sie zu 1.0.1j ... es gab mir ein 1.0.1l und ich befürchtete, es würde gehen
Verwirren Sie mein System, da es sich um separate Brühpakete handelt, die ich bereits hatte
1.0.2 parallel

schien nicht zu helfen, aber vielleicht ging ich nicht weit genug damit

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/compose/issues/890#issuecomment -78340580.

Daher bekomme ich dieses Problem anscheinend auch unter Mac OSX. Mit Docker-Compose ist dies meine .yml-Datei.

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

Beim Ausführen von docker-compose pull die folgende Ausgabe angezeigt, die fehlgeschlagen ist.

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

Einige Dinge habe ich überprüft.
which openssl; openssl version

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

@psykzz Sollte funktionieren, wenn Sie mit

brew install docker-compose

@arvindtest Was lässt Sie denken, dass dies mit diesem Problem zusammenhängt?

Zu Ihrer Information, nachdem ich viel damit zu kämpfen habe, scheint es, dass dies ein Boot2docker-Problem ist.
Was für mich funktioniert hat, war TLS zu deaktivieren. Es gibt noch keine benutzerfreundliche Möglichkeit, dies zu tun, aber die Anweisungen sind hier aufgeführt:
https://github.com/deis/deis/issues/2230

Grundsätzlich müssen Sie:

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

Starten Sie dann boot2docker neu, dh
boot2docker stop
boot2docker starten

und so etwas zu deinem ~ / .bashrc (stelle sicher, dass die IP korrekt ist)

export DOCKER_HOST = tcp: //192.168.59.103 : 2375
Deaktivieren Sie DOCKER_CERT_PATH
Deaktivieren Sie DOCKER_TLS_VERIFY

Warum nicht einfach $ (boot2docker shellinit) in Ihrem Bashrc haben?

Sollte bei allem helfen helfen?

Ich meine, Sie müssen noch die TLS-Lösung machen.
Am 21. März 2015 um 23:05 Uhr schrieb "coderfi" [email protected] :

Zu Ihrer Information, nachdem ich viel damit zu kämpfen habe, scheint es, dass dies ein
boot2docker Problem.
Was für mich funktioniert hat, war TLS zu deaktivieren. Es gibt noch keinen benutzerfreundlichen Weg
Um dies zu tun, werden die Anweisungen hier beschrieben:
deis / deis # 2230 https://github.com/deis/deis/issues/2230

Grundsätzlich müssen Sie:

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

Starten Sie dann boot2docker neu, dh
boot2docker stop
boot2docker starten

und so etwas zu deinem ~ / .bashrc
Stellen Sie sicher, dass die IP korrekt ist

export DOCKER_HOST = tcp: //192.168.59.103 : 2375
Deaktivieren Sie DOCKER_CERT_PATH
Deaktivieren Sie DOCKER_TLS_VERIFY

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/compose/issues/890#issuecomment -84468058.

@kretz es funktioniert! Vielen Dank.

@psykzz meinst du $(boot2docker shellinit) ?

Ja, ich habe meinen Kommentar aktualisiert. derp.

Ich kann bestätigen, dass die Lösung von @coderfi zum Deaktivieren von TLS für mich funktioniert!

Ich bin froh, dass es für dich funktioniert. :) :)

@Matt Ja, Sie haben
Dies funktioniert jedoch möglicherweise nicht, wenn boot2docker noch nicht gestartet wurde, also habe ich nur
machte das Beispiel explizit.

Fi
Am 26. März 2015, 10:18 Uhr, schrieb "anentropic" [email protected] :

Ich kann bestätigen, dass @coderfi https://github.com/coderfi die Lösung für
TLS deaktivieren funktioniert bei mir!

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/compose/issues/890#issuecomment -86630313.

Vielleicht ist dies offensichtlich, aber diejenigen, die TLS deaktivieren oder OpenSSL herabstufen, um dies zum Laufen zu bringen, sollten vorsichtig vorgehen, je nachdem, was sie tun.

Dies bezieht sich nicht auf alle, aber ich hatte einen ähnlichen Fehler beim Installieren von pip mit einem Dockerfile , der von gliderlabs/alpine:3.1 - dem minimalen Linux-Container von Progrium & Crew. Das Problem war, dass ich das Systemzertifikatspaket nicht installiert hatte. Das Problem wurde behoben, indem das Paket vor der Installation von pip installiert und die Anforderungsdatei ausgeführt wurde:

RUN apk-install -X ca-certificates

Die vorgeschlagenen Lösungen haben bei mir nicht wirklich funktioniert. Konnte nicht zu einer der 1.0.1 OpenSSL-Versionen wechseln. Am Ende stellte ich fest, dass es irgendwie funktioniert, alle von Pip installierten Docker-Compose-Versionen zu deinstallieren und nur brew install docker-compose tun.

Die oben genannten Lösungen haben funktioniert, waren mir aber zu umständlich. Ein schnelles boot2docker upgrade alles an meinem Ende repariert.

Ich habe bereits die neueste boot2docker-Version und es funktioniert nicht für mich ohne die oben genannten Korrekturen

Homebrew-Entwickler schlagen vor, Docker-Py und Docker-Compose auf requests 2.6.0 zu aktualisieren

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

Hoffentlich hilft dies jemandem ... Sie sind sich einer Lösung nicht sicher, aber wenn Sie Charles als Mac OS X-Proxy verwenden, wird diese Meldung ausgelöst.

FWIW, die Installation von Docker-Compose über Pip hat Docker-Compose selbst zum Laufen gebracht (die Installation über Curl unter OS X Mavericks führte zu einem illegal operation -Fehler). Ich bekam später auch den SSL-Fehler. Das Ausführen von brew link --force openssl && brew switch openssl 1.0.1j scheint das Problem für mich behoben zu haben.

@ rseymour Antwort hat bei mir funktioniert

Für diejenigen, die openssl-1.0.1j in Brew nicht finden - Sie können eine ältere Version des OpenSSL-Rezepts von Github Repo herunterladen und verwenden:

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

Ich habe 1.0.1m ausprobiert, aber es hat nicht funktioniert.
Also habe ich @lazyval so
Das habe ich getan.

Brew-Installation https://raw.githubusercontent.com/Homebrew/homebrew/62fc2a1a65e83ba9dbb30b2e0a2b7355831c714b/Library/Formula/openssl.rb
Brühschalter openssl 1.0.1j_1
Brew Unlink openssl101 // Weil ich vorher 1.0.1m verlinkt habe
Brew Link openssl --force
Docker-Compose ps

Vielen Dank!!

Ich untersuche dies derzeit, da wir jetzt die Binärdateien auf Python 2.7.9+ erstellen müssen.

_Verlegt von # 1427_

Server:

• CoreOS Stable
• Docker 1.5.0

Klient:

• CentOS 6.6, 64-Bit
• Kernel 2.6.32-042stab105.14
• Docker-Client 1.5.0
• Docker-Compose 1.2.0
• SSL-Zertifikate werden bei ~/.docker/{ca.pem,cert.pem,key.pem}
• DOCKER_HOST=tcp://docker-builder:2376
• DOCKER_TLS_VERIFY=1

Verwenden des folgenden Makefiles zum Erstellen der SSL-Zertifikate:

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

Hier ist das (zugegebenermaßen weniger als ideale) Benutzerdatenskript zur Bereitstellung dieser Maschine:

#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

Mit dem docker -Client habe ich guten Erfolg beim Zugriff auf den Remote-Docker-Server. Wir rufen den Remote-Server bis zu hunderttausend Mal am Tag mit gutem Erfolg an.

Beim Versuch, docker-compose , das entweder über Curl oder pip install --upgrade mit Python 2.7 installiert wurde, wird ein SSL-Fehler angezeigt:

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

Dies ist der Fall, nachdem manuell DOCKER_CERT_PATH=/home/user/.docker/ sowie REQUESTS_CA_BUNDLE=/home/user/.docker/ca.pem einzeln und zusammen angegeben wurden.

Um es klar auszudrücken: Dieses Setup funktioniert hervorragend nur mit dem Docker-Daemon, aber etwas über -compose stimmt nicht.

Einige Notizen:

1. Die Compose 1.3.0 RC1-Binärdatei für OSX weist diesen Fehler auf. Wahrscheinlich nicht zufällig ist dies das erste Mal, dass es gegen Python 2.7.9 erstellt wurde - zuvor war es 2.7.6.
2. Seltsamerweise kann ich gegen eine boot2docker-VM reproduzieren, aber nicht gegen eine von Machine bereitgestellte Virtualbox-VM. @ehazlett , @nathanleclaire , @tianon - irgendwelche Einblicke dort?
3. Wenn dies bei der Installation von Compose mit Pip auftritt, melden Sie bitte die Ausgabe der folgenden Befehle:

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

Auf meinem lokalen Computer, auf dem ich den Fehler reproduzieren kann, habe ich Python 2.7.10 und OpenSSL 1.0.2a 19 Mar 2015 .

1. Dies wurde Homebrew gemeldet, und einige Leute sagen, dass sie erfolgreich Python und OpenSSL neu installiert haben, aber es hat bei mir nicht funktioniert. https://github.com/Homebrew/homebrew/issues/38226

Hmm das ist wirklich komisch. Welche Version von b2d verwenden Sie im Vergleich zur Version?
der Maschine? Wir verwenden beide b2d, daher bin ich mir nicht sicher, was anders wäre
neben der Version.

Ich werde via pip auf meinem OS X-Computer installieren und sehen, was ich bekomme.

Am Donnerstag, 28. Mai 2015, um 9:19 Uhr, Aanand Prasad [email protected]
schrieb:

Einige Notizen:

1.

Die Compose 1.3.0 RC1-Binärdatei für OSX weist diesen Fehler auf. Wahrscheinlich nicht
Zufälligerweise ist dies das erste Mal, dass es gegen Python 2.7.9 erstellt wurde

• vorher war es 2.7.6.
  2.

Seltsamerweise kann ich gegen eine boot2docker-VM reproduzieren, aber nicht gegen eine
Von Machine bereitgestellte Virtualbox-VM. @ehazlett
https://github.com/ehazlett , @nathanleclaire
https://github.com/nathanleclaire , @tianon
https://github.com/tianon - irgendwelche Einblicke dort?
3.

Für alle, die dies bemerken, wenn Compose mit Pip installiert wird, bitte
Melden Sie die Ausgabe der folgenden Befehle:

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

Auf meinem lokalen Computer, auf dem ich den Fehler reproduzieren kann, habe ich Python
2.7.10 und OpenSSL 1.0.2a 19. März 2015.
4.

Dies wurde Homebrew gemeldet, und einige Leute sagen, sie hätten es getan
Erfolg bei der Neuinstallation von Python und OpenSSL, aber es hat bei mir nicht funktioniert.
Homebrew / Homebrew # 38226
https://github.com/Homebrew/homebrew/issues/38226

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
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)

Ist etwas anderes an der Zertifikatserstellung vielleicht? Ich habe anscheinend mehr Dateien in meinem Maschinenzertifikat als in meinem 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

Das ist gut. Der Client verwendet nur ca.pem, cert.pem und key.pem
(Server ist nur eine lokale Kopie für den Host auf dem Computer). Ich werde als erstellen
gut und überprüfen Sie die Zertifikate, um zu sehen, was der Unterschied sein könnte.

Am Do, 28. Mai 2015 um 9:30 Uhr, Aanand Prasad [email protected]
schrieb:

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

$ docker-machine --version
Docker-Maschine Version 0.2.0 (8b9eaf2)

Ist etwas anderes an der Zertifikatserstellung vielleicht? Ich scheine mehr zu haben
Dateien in meinem Maschinenzertifikat als in meinem 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-Maschine 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. 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

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
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

Siehe auch https://github.com/docker/docker-py/issues/465. Das dortige Testskript von @garethr gibt den Fehler auch für mich wieder, nachdem eine Änderung vorgenommen wurde, um die Überprüfung des Hostnamens zu deaktivieren:

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)

Es funktioniert jedoch weiterhin mit der von der Maschine bereitgestellten VM:

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

Wenn ich die Überprüfung des Hostnamens wieder aktiviere (indem ich die Zeile assert_hostname im Testskript auskommentiere), schlägt dies mit demselben Fehler für die VM boot2docker-cli fehl, jedoch mit einem anderen Fehler für die VM VM, der möglicherweise oder möglicherweise nicht relevant:

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

Zusätzlich habe ich versucht, v1.3.0-rc1 über curl (die binäre Version, nicht über pip) zu verwenden und habe den gleichen Fehler wie zuvor auf einem Docker 1.6.2-Daemon erhalten:

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

Ja - die RC1-Binärdatei wurde mit Python 2.7.9 und OpenSSL 1.0.2a erstellt, was eine der problematischen Kombinationen zu sein scheint.

Dies ist sinnvoll, da ich glaube, dass die Zertifikatsgenerierung in b2d auf der VM erfolgt
während Maschine sie in Maschine erzeugt. Wir konnten das erkennen und hinzufügen
Computername bei Bedarf an die SANs. Eigentlich wäre das wohl gut
speziell für b2d VMs. Der Grund, warum es jetzt funktioniert, denke ich, ist, dass Sie
Greifen Sie auf die Engine mit der IP zu, die der Computer als IP-SAN hinzufügt. Da ist ein
PR offen, um beliebige zusätzliche SANs zuzulassen, die ebenfalls funktionieren würden.

Am Donnerstag, den 28. Mai 2015, schrieb Aanand Prasad [email protected] :

Siehe auch Docker / Docker-Py # 465
https://github.com/docker/docker-py/issues/465. @garethr
Das dortige Testskript von https://github.com/garethr gibt den Fehler für wieder
Ich auch, nachdem ich eine Änderung vorgenommen habe, um die Überprüfung des Hostnamens zu deaktivieren:

aus docker.client importieren Client aus docker.utils importieren kwargs_from_env

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

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

$ eval "$ (boot2docker shellinit)" && python test.py
Schreiben von /Users/aanand/.boot2docker/certs/boot2docker-vm/ca.pem
Schreiben von /Users/aanand/.boot2docker/certs/boot2docker-vm/cert.pem
Schreiben von /Users/aanand/.boot2docker/certs/boot2docker-vm/key.pem
Traceback (letzter Anruf zuletzt):
Datei "test.py", Zeile 8, in
print client.version ()
Datei "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", Zeile 1108, in Version
return self._result (self._get (url), json = True)
Datei "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", Zeile 106, in _get
return self.get (url, * _self._set_request_timeout (kwargs))
Datei "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", Zeile 477, in get
return self.request ('GET', url, * _kwargs)
Datei "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", Zeile 465, auf Anfrage
resp = self.send (prep, * _send_kwargs)
Datei "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", Zeile 573, in send
r = adapter.send (Anfrage, * _kwargs)
Datei "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", Zeile 431, in send
SSLError auslösen (e, request = request)
request.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] Zertifikatüberprüfung fehlgeschlagen (_ssl.c: 590)

Es funktioniert jedoch weiterhin mit der von der Maschine bereitgestellten VM:

$ eval "$ (Docker-Maschine 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'}

Wenn ich die Überprüfung des Hostnamens wieder aktiviere (indem ich den assert_hostname auskommentiere
Zeile im Testskript), es schlägt mit dem gleichen Fehler gegen die fehl
boot2docker-cli VM, aber ein _differenter Fehler_ gegen die Machine VM, die
kann relevant sein oder nicht:

Traceback (letzter Anruf zuletzt):
Datei "test.py", Zeile 8, in
print client.version ()
Datei "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", Zeile 1108, in Version
return self._result (self._get (url), json = True)
Datei "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/docker/client.py", Zeile 106, in _get
return self.get (url, * _self._set_request_timeout (kwargs))
Datei "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", Zeile 477, in get
return self.request ('GET', url, * _kwargs)
Datei "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", Zeile 465, auf Anfrage
resp = self.send (prep, * _send_kwargs)
Datei "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/sessions.py", Zeile 573, in send
r = adapter.send (Anfrage, * _kwargs)
Datei "/Users/aanand/.virtualenvs/docker-compose/lib/python2.7/site-packages/requests/adapters.py", Zeile 431, in send
SSLError auslösen (e, request = request)
request.exceptions.SSLError: Es wurden keine geeigneten Felder commonName oder subjectAltName gefunden

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/docker/compose/issues/890#issuecomment -106363305.

OK, ich glaube, ich bin zu einem Fix für OS X gekommen: https://github.com/docker/compose/pull/1474

Um dies für Linux zu beheben, muss die Docker-Datei aktualisiert werden, um sie an Python 2.7.9 und OpenSSL 1.0.1 zu pinnen. Dies wird ein unterhaltsames Unterfangen sein, da sie bei debian:wheezy beginnt (um sicherzustellen, dass wir eine ausreichend verwenden altes glibc - siehe https://github.com/docker/compose/pull/505).

Der Wechsel zu 1.0.1k, wie in @kretz ' Kommentar beschrieben, und die Installation von 1.3.0 RC1 über pip haben mir geholfen .

Vor dem Umschalten von Python wurde 1.0.2a gemeldet:

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

Nach dem Umschalten wurde 1.0.1k gemeldet und Docker-Compose scheint wie erwartet zu funktionieren:

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

Eine Problemumgehung, mit der dieser Fehler behoben wurde, bestand darin, die folgenden Pakete in meiner virtuellen Umgebung zu installieren
pip install pyopenssl==0.14 ndg-httpsclient==0.4 pyasn1==0.1.7

In der unter https://github.com/docker/compose/issues/890#issuecomment -106289821 beschriebenen Umgebung, die Python 2.7.6 bereitstellt (über snap-ci.com, unter dem Sie ein kostenloses Konto erhalten können).

mit dem folgenden Skript, das die Problemumgehung von @ jsh2134 in einer Pip-Installation verwendet (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

Ich erhalte folgende Ausgabe:

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

Beachten Sie insbesondere den Fehler (der neu erscheint):

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

Erstellt https://github.com/docker/compose/issues/1484 , um meine bisherigen Ergebnisse zu analysieren.

Ich habe einige Binärdateien mit dem Fix in # 1474 erstellt. Bitte probieren Sie sie aus, wenn Sie SSL-Probleme haben:

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 warum genau fixierst du pyOpenSSL auf 0.14?

+1 für @kretz Antwort :)

+1 gleiches Problem :( scheint Docker auf osx komplett kaputt zu sein?

Die @ coderfi- Lösung hat bei mir funktioniert: Windows 7 Docker 1.7 Cygwin und Docker-Compose werden über Pip in Cygwin installiert

Umgang mit einem der Variantenfehler auf einer Centos7-VM, die als Client zum Starten von Containern auf einer Docker-Maschine fungiert:

[ root @ xxxx cm] # docker-compose ps
SSL-Fehler: Es wurden keine geeigneten Felder für commonName oder subjectAltName gefunden

Dies war früher vorübergehend; Ich konnte mich abmelden, mich wieder anmelden und den Fehler eine Weile nicht sehen. Jetzt sehe ich es immer.

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

[ root @ xxxx cm] # Docker-Version
Client-Version: 1.6.2
Client-API-Version: 1.18
Go-Version (Client): go1.4.2
Git Commit (Client): ba1f6c3 / 1.6.2
OS / Arch (Client): Linux / AMD64
Serverversion: swarm / 0.2.0
Go-Version (Server): go1.3.3
Git Commit (Server): 48fd993
OS / Arch (Server): Linux / AMD64

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

Ich bin nicht sicher, wie ich einige der oben genannten Korrekturen in meiner Umgebung anwenden soll. Ich benutze nicht boot2docker; Umgang mit Docker 1.6.2 direkt in der Bash-Befehlszeile.

Hallo. Ich habe tatsächlich ein Problem aus diesem Grund geöffnet, da ich es nicht beheben kann. Ich habe viele Dinge ausprobiert, z. B. Compose mit Pip / Brew / Newst-Versionen installieren. Gleich wie openssl versuchte 0.x 1.0.2x Versionen usw. und funktioniert immer noch nicht.

PS: Ich benutze keinen boot2docker. Ich habe meine eigene VM, die ich über Vagrant erstelle, die Zertifikate generiere und den Docker-Daemon mit ihnen starte. Anscheinend funktioniert es mit Docker, sodass das Problem nicht von meinen Zertifikaten herrührt.

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

habe diesen Fehler auch einmal bekommen:

/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

Nachdem Sie hier gelesen und mit der Installation der vorgeschlagenen Pakete herumgespielt haben:

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

Die Fehlermeldung von Docker-Compose hat sich geändert:

[ root @ xxx cm] # docker-compose up -d
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connection.py:251: Sicherheitswarnung: Das Zertifikat hat kein subjectAltName und greift zurück, um nach einem commonName für zu suchen jetzt. Diese Funktion wird von den wichtigsten Browsern entfernt und von RFC 2818 nicht mehr unterstützt. (Weitere Informationen finden Sie unter https://github.com/shazow/urllib3/issues/497.)
Sicherheitswarnung
SSL-Fehler: Hostname 'xx.xx.xx.xx' stimmt nicht mit None überein

(Das gepunktete Quad, das ich xx herausgeholt habe, ist vom Schwarmmaster / Docker-Host).

Könnte dieses Problem auch durch Bearbeiten oder Neuerstellen des Zertifikats behoben werden?

Nachtrag: Die Zertifikate wurden auf dieser VM von "Docker-Machine Create" erstellt.

Könnten wir uns mit einem Fehler in der Docker-Maschine befassen, der zu einem unzureichend detaillierten Zertifikat führt?

Ich sehe diesen Fehler nur bei Docker-Hosts, die von Docker-Maschinen erstellt wurden. Ich glaube, die SSL-Zertifikate werden nicht richtig erstellt.

Hat jemand eine Problemumgehung oder eine Lösung, um dies zu beheben? Dies ist momentan ein bisschen ein Blocker für mich: /

@prologic Erhalten Sie den Fehler mit der Binärdatei oder mit einem Pip-installierten Compose? In letzterem Fall versuchen Sie auch, requests[security] installieren.

@aanand Danke! Ich werde das versuchen und zurückmelden, ob das funktioniert oder nicht!

@prologic Wir möchten requests[security] verpacken, anstatt uns auf das

@aanand Danke! Das hat perfekt funktioniert :)

@coderfi Ihre Lösung hat bei mir funktioniert, danke

@aanand der Juni 2 Build funktioniert gut für mich. Viel Glück beim Quetschen dieses schmerzhaften Käfers.

@neilsarkar Ich habe zufällig Charles Proxy ausgeführt. Ihr Kommentar hat mich gerettet. : +1:

Ich verwende OS X 10.9.5. Hier ist meine Auswahl:

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

Meine Problemumgehung:

Kommentar Zeilen 246: 253 in
/usr/local/Cellar/fig/1.3.1/libexec/vendor/lib/python2.7/site-packages/requests/packages/urllib3/connection.py

Dies ist der Teil, der die Sicherheitsausnahme auslöst

Das Problem für mich war, dass selbst wenn ich Brew Link angegeben habe --force openssl, fig / docker-compose immer noch / usr / bin / openssl verwendet.

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

Das hat bei mir funktioniert. Jetzt verstehe ich die nervige Nachricht nicht mehr.

Zu Ihrer Information, Brew Fig / Docker-Compose-Rezept verwendet System-Python. Selbst wenn Sie Python über Pyenv oder Brew installieren, verwendet Brew Install Fig / Docker-Compose weiterhin das System openssl lib, falls verfügbar, andernfalls wird eine andere Version installiert.

Auf meinem MAC bei der Arbeit habe ich es mit pyenv install 2.7.8, dann easy_install pip und pip install docker-compose gelöst.

Aber auf meinem Mac zu Hause, "beide laufen Yosemite", habe ich das gleiche getan und bekomme immer noch die Warnung.

Wird weiter graben.

@dtunes - die Ursache (wie @aanand oben Bezug genommen) ist https://github.com/boot2docker/boot2docker/issues/808. Das System-Python / Homebrew-Python-Ding ist ein roter Hering, da es nur davon abhängt, ob Sie mit neuem oder altem OpenSSL verknüpft sind.

Ja, ich habe das Ticket gesehen. Was mich stört, ist, dass auf meinem Mac bei der Arbeit, nachdem ich die verschiedenen oben genannten Ansätze ausprobiert habe, keiner funktioniert hat.
Ich habe dann / usr / bin / openssl nach / usr / bin / openssl_old verschoben, das neueste openssl mit Home Brew installiert und zwangsweise verknüpft. erst dann habe ich folgendes gemacht:

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

Dies hat den Trick bei der Arbeit gemacht, auf meinem Mac zu Hause hat es jedoch nicht funktioniert. Aber ich werde es erneut versuchen, falls ich einen Fehler gemacht habe, und die Ergebnisse zurückmelden.

@dtunes - Um alle Ihre Abhängigkeiten neu zu erstellen, müssen Sie ~/Library/Caches/pip entfernen, damit das zwischengespeicherte Binärrad, das gegen die falsche OpenSSL erstellt wurde, nicht wiederverwendet wird.

@glyph schrieb :

Die Hauptursache (wie @aanand oben angegeben) ist boot2docker / boot2docker # 808. Das System-Python / Homebrew-Python-Ding ist ein roter Hering, da es nur davon abhängt, ob Sie mit neuem oder altem OpenSSL verknüpft sind.

@glyph oder @aanand , deutet das darauf hin, dass @aanands Fix ( @aanand , wenn boot2docker / boot2docker # 808 richtig angesprochen wird, sollte # 1474 zurückgesetzt werden? Ist es auch ein roter Hering, Hoffnung auf die nächste Kryptographie-Veröffentlichung zu setzen (siehe dies und das )?

@aanand schrieb :

Beachten Sie, dass ich diesen Fehler nicht für eine mit Docker-Computer bereitgestellte Boot2Docker-VM reproduzieren kann - er tritt nur für eine mit dem Befehl boot2docker bereitgestellte VM auf.

@ehazlett schrieb :

Dies ist sinnvoll, da ich glaube, dass die Zertifikatsgenerierung in b2d auf der VM erfolgt, während die Maschine sie in der Maschine generiert.

Ich habe es vielleicht falsch verstanden, aber es wird viel darüber geredet, dass verschiedene Host / SideSSLL-Kombinationen für dieses und verwandte Probleme verantwortlich gemacht werden. Wenn die Ursache des Problems eine defekte OpenSSL ist, die mit b2d verteilt wird, bin ich mir nicht sicher, ob der beste Ansatz darin besteht, sicherzustellen, dass die host-seitige OpenSSL von Compose ähnlich defekt ist? Für das, was es wert ist, ist es unwahrscheinlich, dass diese Arten von Host-seitigen Verrenkungen dieses Problem für diejenigen lösen, die b2d über (z. B.) Vagrant ausführen und außerhalb von Compose darauf zugreifen (siehe z. B. Docker / Docker-Py # 465 ).

Wenn dieser Kommentar in boot2docker / boot2docker # 808 besser geeignet ist, kann ich ihn dorthin verschieben.

Ich bin ein Homebrew-Betreuer und habe Glyphen dabei geholfen, dies herunterzufahren.

Die Betreff- und Aussteller-DNs des von boot2docker generierten Serverzertifikats sind identisch auf /O=Boot2Docker . Ich glaube, das Serverzertifikat ist tatsächlich vom CA-Zertifikat signiert, aber AFAICT OpenSSL 1.0.2 verwendet diese Informationen (dh identische Betreff- und Aussteller-DNs), um das Serverzertifikat als selbstsigniert abzulehnen, anstatt zu versuchen, das Serverzertifikat anhand des bereitgestellten Zertifikats zu überprüfen CA cert. OpenSSL-Versionen vor 1.0.2 validieren das Serverzertifikat anhand des bereitgestellten CA-Zertifikats, was erfolgreich ist.

Ich glaube, habe aber nicht getestet, dass die Zertifikate unter allen OpenSSL-Versionen validiert werden können, wenn dem Server- und dem CA-Zertifikat unterschiedliche Betreff-DNs zugewiesen werden (sodass das Serverzertifikat unterschiedliche Betreff- und Aussteller-DNs hat). Ich vermute (basierend auf meiner Lektüre dieses X.509-Überlebensleitfadens, aber ohne verwandte Spezifikationen), bin aber nicht sicher, dass das Verhalten von OpenSSL 1.0.2 angemessen ist und keine Regression darstellt, die von den OpenSSL-Entwicklern gelöst werden sollte.

1474 macht zwei verschiedene Dinge:

• Festlegen einer Mindestversion von Python auf 2.7.9: Auf diese Weise kann urllib3 Anforderungen abschließen, ohne eine InsecurePlatformWarning auszugeben, die beim Herstellen von HTTPS-Verbindungen ausgegeben wird, wenn beide der beiden Bedingungen erfüllt sind: Die Python-Version liegt vor 2.7.9 und das PyOpenSSL-Modul ist nicht hier. Das Bündeln von PyOpenSSL wäre ebenso effektiv, aber ich verstehe aus der Diskussion, dass es nicht mit PyInstaller kompatibel ist. In beiden Fällen hängt die InsecurePlatformWarning von urllib3 nicht mit dem Problem mit dem boot2docker-Zertifikat zusammen, und das Beheben der Zertifikate macht diese Problemumgehung nicht überflüssig.
• Festlegen einer maximalen OpenSSL-Version auf 1.0.1j. Ich glaube, dass dies unnötig sein sollte, sobald die boot2docker-Zertifikate repariert sind.

Wenn die Ursache des Problems eine defekte OpenSSL ist, die mit b2d verteilt wird

Es ist nicht; Die Boot2docker-Zertifikate (generiert durch diesen Code ) sind laut Clients, die OpenSSL ≥ 1.0.2 verwenden, ungültig. Die mit boot2docker verteilte OpenSSL-Bibliothek ist nicht betroffen.

@glyph oder @aanand , deutet das darauf hin, dass @aanands Fix ( @aanand , wenn boot2docker / boot2docker # 808 richtig angesprochen wird, sollte # 1474 zurückgesetzt werden? Ist es auch ein roter Hering, Hoffnung auf die nächste Kryptographie-Veröffentlichung zu setzen (siehe dies und das)?

Ja, ich denke schon. Ich glaube, die OpenSSL mit dem Problem ist 1.0.2, und wenn sie auf 1.0.1 beschränkt wird, wird vermieden, dass die Überprüfungslogik dazu führt, dass das Zertifikat fehlschlägt. Ich weiß immer noch nicht, was es mit dem Zertifikat auf sich hat, das es nicht mag, da die Fehlermeldungen so stumpf sind.

Außerdem denke ich, dass das, was # 1474 tut, viel zu spezifisch ist; Zumindest nach meiner Lektüre wird keine _minimale_ Python-Version festgelegt, sondern eine _genaue_ Version angegeben. Es scheint auch nicht zu bestehen, dass Sie eine andere Version 1.0.1 als j haben, was bedeutet, dass Sicherheitsupdates nicht einmal auf Version 1.0.1 angewendet werden, was definitiv ein Problem ist.

Ich glaube, habe aber nicht getestet, dass die Zertifikate unter allen OpenSSL-Versionen validiert werden können, wenn dem Server- und dem CA-Zertifikat unterschiedliche Betreff-DNs zugewiesen werden (sodass das Serverzertifikat unterschiedliche Betreff- und Aussteller-DNs hat). Ich vermute (basierend auf meiner Lektüre dieses X.509-Überlebensleitfadens, aber keinen verwandten Spezifikationen), bin aber nicht sicher, dass das Verhalten von OpenSSL 1.0.2 angemessen ist und keine Regression darstellt, die von den OpenSSL-Entwicklern gelöst werden sollte.

Ich werde das von docker-machine generierte Zertifikat untersuchen und prüfen, ob es diese Eigenschaft hat. Warum ist dieses Verhalten Ihrer Meinung nach akzeptabel / keine Regression in OpenSSL? Das Vertrauen in ein selbstsigniertes Zertifikat ist vollkommen in Ordnung, und es gibt keine besonderen Einschränkungen hinsichtlich des Inhalts oder des Ausstellers, die mir bekannt sind. Ich habe ein wenig von diesem Handbuch überflogen und es scheint nur darauf hinzuweisen, dass selbstsignierte Zertifikate kein CA-Kartell-Vertrauen haben, sodass Ihr Webbrowser ihnen ohne zusätzliche Konfiguration nicht vertraut.

Wenn ich mir das Zertifikat in meiner docker-machine VM ansehe, sehe ich:

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

Damit haben Sie vielleicht Recht ...

Ich werde das vom Docker-Computer generierte Zertifikat untersuchen und prüfen, ob es [übereinstimmende Betreff- und Aussteller-DNs] enthält.

Sie können sehen, dass die Docker-Machine-Zertifikate von aanand auch unterschiedliche DNs haben: https://gist.github.com/aanand/3d865623481ba8ae66ee#file -docker-machine-log-L30-L32

Das Vertrauen in ein selbstsigniertes Zertifikat ist vollkommen in Ordnung

Ein selbstsigniertes Zertifikat ist jedoch nur gültig, wenn Sie dem selbstsignierten Zertifikat vertrauen. Wir weisen OpenSSL nicht an, dem Serverzertifikat zu vertrauen. Wir weisen OpenSSL an, der Zertifizierungsstelle zu vertrauen, die das Serverzertifikat ausgestellt hat.

Warum ist dieses Verhalten Ihrer Meinung nach akzeptabel / keine Regression in OpenSSL?

IANAL, aber meine Argumentation leitet sich aus der Sprache ab. "Auf einer strengen Ebene bedeutet [Selbstsignierung], dass die Aussteller- und Betrefffelder im Zertifikat identisch sind." Dies ist beim boot2docker-Serverzertifikat der Fall. Wenn OpenSSL versucht, das boot2docker-Serverzertifikat zu validieren, kann eine vollständige Vertrauenskette ohne Berücksichtigung des CA-Zertifikats erstellt werden, da das Serverzertifikat von sich aus signiert zu sein scheint, jedoch nicht explizit vertrauenswürdig ist und daher nicht gültig sein kann. Ich bin nicht sicher, ob dies ein streng korrektes oder erforderliches Verhalten ist, und ich bin nicht qualifiziert zu entscheiden, aber ich denke, es scheint "vernünftig" zu sein.

Danke fürs Graben, Leute.

Außerdem denke ich, dass das, was # 1474 tut, viel zu spezifisch ist; Zumindest nach meiner Lektüre wird keine Mindestversion von Python festgelegt, sondern eine genaue Version angegeben. Es scheint auch nicht zu bestehen, dass Sie eine andere Version 1.0.1 als j haben, was bedeutet, dass Sicherheitsupdates nicht einmal auf Version 1.0.1 angewendet werden, was definitiv ein Problem ist.

Einverstanden. Angenommen, es ist OpenSSL 1.0.2, das nicht mit den Zertifikaten von boot2docker übereinstimmt, sollte dieser Teil zumindest reparierbar sein - ich werde versuchen, ein aktuelles OpenSSL 1.0.1 in zu bekommen.

@ tdsmith , danke für die Erklärung und entschuldige @glyph , danke für die Klarstellung.

FWIW, ich habe versucht, die Theorie von @tdsmith zu testen und generate_cert gehackt (es ist hässlich, vergib mir), um unterschiedliche Werte für Issuer und Subject zu erstellen. Es scheint Wasser zu halten (aber siehe Vorsichtsmaßnahmen unten). Folgendes bekomme ich, wenn ich b2d mit Zertifikaten ausführe, die aus dem aktuellen generate_cert im Vergleich zu meiner gehackten Version generiert wurden:

0.9.8zd funktioniert mit 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 (über MacPorts installiert) funktioniert nicht mit 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 funktioniert mit gehackten generate_cert (0.1.1; nicht überraschend)

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

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

1.0.2d _works (!) _: Tada :: see_no_evil :: listen_no_evil :: speak_no_evil: mit gehacktem 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

Vorsichtsmaßnahmen

Beachten Sie im Interesse des Versuchs, alle Änderungen zu kontrollieren, dass das ursprüngliche generate_cert (0.1) veröffentlicht wurde, als das zum Erstellen verwendete Docker-Image golang:1.3-cross Zugriff auf ein Paket hatte genannt ssh . Dieses Paket wurde inzwischen durch openssh-client . Die OpenSSL-Version, die beim Erstellen meiner gehackten generate_cert ist 1.0.1k . Dies scheint statisch verknüpft zu sein:

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

Es sieht also so aus, als ob eines von zwei Dingen passieren könnte:

• Beide späten Versionen von OpenSSL werden verwirrt, wenn Issuer == Subject , wie @tdsmith vorschlägt; oder
• Die Zertifikatgenerierung hat sich in OpenSSL noch etwas geändert, sodass spätere Versionen von OpenSSL Probleme haben, von früheren generierte Zertifikate zu validieren

Eine Möglichkeit, dies zu testen, besteht darin, generate_cert ohne meinen Hack neu zu erstellen, jedoch mit einer aktualisierten Version von OpenSSL. Ich werde das als nächstes tun.

Es sieht also so aus, als ob @tdsmith richtig ist. Nachdem ich meinen Hack zurückgezogen habe, um sicherzustellen, dass Issuer <> Subject , aber generate_cert mit der neueren Version von OpenSSL von golang:1.3-cross , schlägt er wieder fehl spätere OpenSSL-Versionen auf der Client-Seite:

0.9.8zd funktioniert mit generate_cert (0.1.2) mit aktualisiertem OpenSSL

% /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 (über MacPorts installiert) funktioniert _not_ mit generate_cert (0.1.2) mit aktualisiertem OpenSSL

% 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

Benötigt SvenDowideit / generate_cert # 10. Übrigens, wenn jemand b2d-Bilder erstellen möchte, die auf meine gehackten generate_cert s verweisen, können Sie diese ausprobieren, bis ein offizielles Update veröffentlicht wird.

Wenn ich das richtig verstehe, sollte dies die Notwendigkeit vermeiden, OpenSSL / Python-Versionsspiele auf der Clientseite zu spielen (zumindest in Bezug auf dieses Problem).

Tagging @SvenDowideit

Ich hatte ein bisschen hin und her mit den OpenSSL-Leuten. Hier ist eine Zusammenfassung von 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

Das Ändern der Art und Weise, wie b2d seine Zertifikate generiert, um fehlerhafte OpenSSL-Clients aufzunehmen, scheint dem Patchen und Installieren von OpenSSL auf der Clientseite weit überlegen zu sein. Ich bin mir jedoch nicht sicher, welcher spezifische Ansatz besser geeignet ist (Betreff! = Emittent vs. SKID / ADID in alle Zertifikate einbeziehen). Ich werde das Geld an @SvenDowideit weitergeben. :Grinsen:

Für Neugierige (ich denke auch hier nicht, dass wir diesen Weg einschlagen sollten), hier ist der OpenSSL-Patch von 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);

Vollständiger Verlauf: http://rt.openssl.org/Ticket/History.html?user=guest&pass=guest&id=3979.

Warten Sie ... _less_ streng? Ich bin verwirrt, wie eine _less_ strenge Prüfung fehlschlägt, wenn eine strengere besteht?

Warten Sie ... _less_ streng? Ich bin verwirrt, wie eine _less_ strenge Prüfung fehlschlägt, wenn eine strengere besteht?

Ja, ich hatte auch Probleme mit dieser Wahl der Sprache. Wenn ich mir den Unterschied anschaue, denke ich, dass er bedeutet, fälschlicherweise mehr Zertifikate als selbstsigniert einzutragen, indem nicht so viele Prüfungen durchgeführt werden (dh weniger streng bei der Bestimmung, was nicht als selbstsigniert qualifiziert ist). Aber du hast recht. Es ist eine seltsame Wendung.

Ich habe nicht so viel Zeit damit verbracht, mich mit OpenSSL-Quellen zu beschäftigen, aber ich finde sie an vielen Stellen ziemlich undurchdringlich. Vielleicht braucht es eine "besondere" Denkweise, um an diesem Projekt zu arbeiten. :Grinsen:

Ich habe nicht so viel Zeit damit verbracht, mich mit OpenSSL-Quellen zu beschäftigen, aber ich finde sie an vielen Stellen ziemlich undurchdringlich. Vielleicht braucht es eine "besondere" Denkweise, um an diesem Projekt zu arbeiten.

Eine Untertreibung, denke ich: zwinker :.

Auf jeden Fall danke, dass Sie sich an die OpenSSL-Leute gewandt haben. Ich bin froh, dass es hier gelöst wird. In der Zwischenzeit scheint es richtig, in b2d daran zu arbeiten. Ich glaube nicht, dass es hier etwas zu komponieren gibt, aber warte.

Wie hier erwähnt, behebt dies die Dinge für mich:

pip install requests[security]

@iffy Das ist ein roter Hering; Es behebt es wahrscheinlich für Sie, weil Sie ein zwischengespeichertes Binärrad hatten, das mit einer anderen OpenSSL verknüpft war.

Zu Ihrer Information, PR mit Fix als boot2docker / boot2docker # 1029 eingereicht.

Das Update dafür (danke @posita!) Ist in der neuesten Version von boot2docker verfügbar. Upgraden:

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

Das hat das Problem für mich behoben. Bitte versuchen Sie es und melden Sie sich zurück.

Alternativ können Sie zu Docker Machine wechseln, das jetzt standardmäßig in der neuen Docker Toolbox enthalten ist .

Ich habe immer noch dieses Problem ...

❯ 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 Ihr Docker-Compose-Aufruf ist erfolgreich. Die Warnung, die Sie sehen, ist harmlos. Sie sollten ein Upgrade auf OS X 10.10.5 durchführen, wenn Sie es nicht sehen möchten.

@tdsmith nicht harmlos für mich, macht meine OCD verrückt: Lächeln: Danke für den Tipp, wird jetzt upgraden.

Die Deinstallation der über Brew installierten Python-Version hat dieses Problem für mich gelöst. brew remove --force python

Ich habe die Brew-Version deinstalliert, habe aber immer noch Python 2.7.10 und habe immer noch die
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) Fehler.

Ich habe das nächste Setup:

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
Hast du dein Problem gelöst?

Weiß jemand, ob Docker-Compose-Leute daran arbeiten, das Problem zu lösen, oder ist es im Grunde nicht ihr Problem?

Grüße,

@ PavelPolyakov
Nein. Auf beiden Macs (10.9.x und 10.10.x) habe ich verschiedene Dinge ohne Änderung ausprobiert. Ich denke nicht, dass dies eine docker-compose Sache und mehr von Python Sache FWIW ist.

@chiefy
Ich stimme zu, aber ich habe keine Variante gefunden, wie es funktioniert :(

Scheint, als hätte jeder dieses Problem bereits gelöst, aber nicht ich :)

Ich habe Python einmal mit Brew installiert und ich glaube, ich habe das System entfernt, sodass ich keine Option habe, zum alten zurückzukehren.

Ich habe versucht, Docker mit verschiedenen Varianten zu installieren:

1. aus der Binärdatei (Herunterladen der Docker-Toolbox)
2. vom Gebräu selbst

aber ich habe noch:

Hat jemand eine umfassende Anleitung, wie man dieses Verhalten überwinden kann?

Grüße,

@PavelPolyakov - Der Fehler ist, dass boot2docker (und in einigen Fällen, glaube ich, Docker-Maschine) einige Zertifikate erstellt hat, die für die SSL-Unterstützung von Python unbrauchbar waren. Wenn Sie Ihre gesamte Software aktualisiert haben, aber immer noch die schlechten alten Zertifikate haben, sind die Dinge immer noch kaputt. An dieser Stelle würde ich empfehlen, die vorhandenen Entwickler-VMs mit einer aktuellen Version der Docker-Maschine erneut bereitzustellen, damit neue SSL-Zertifikate bereitgestellt werden. Dies kann bedeuten, dass Sie ~/.docker auf Ihrem Host beiseite schieben.

@PavelPolyakov und @chiefy können Sie zusätzlich zu @glyphs Ratschlägen auch boot2docker -Umgebung nicht vollständig neu bereitstellen möchten):

% 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] ist spezifisch für Ihre VM-Umgebung. Möglicherweise gibt es einfachere Methoden (z. B. vagrant ssh , wenn Sie Vagrant verwenden). Starten Sie dann Ihre boot2docker -Instanz neu und prüfen Sie, ob der SSL-Fehler weiterhin auftritt.

@glyph

Vielen Dank für den Rat, für mich ist es kein Problem, die Docker-Maschine erneut bereitzustellen. Es hilft jedoch nicht.

Wenn ich Docker & Co installiere mit:
brew install docker docker-machine docker-compose

Dann wird keine default Maschine erstellt. Und ich habe keine Ahnung, wie ich es mit docker-machine create erstellen soll.

Wenn ich Docker-Toolbelt mit der * .pkg-Datei installiere, wird der Computer erstellt, aber ich habe einen SSL-Fehler.
Ich habe sogar versucht zu tun:

docker-machine regenerate-certs default

Aber es hilft nicht.

@posita
Danke auch für den Rat.
In Ihrem Reiseführer schlagen Sie mv ~/.docker ~/.docker-bak - aus welchem ​​Grund? Sobald wir dies tun, können wir den Computer nicht erneut starten, da die Dateien verschoben werden.
Ja, ich kann mich auf dem Computer anmelden und tls/* entfernen und dann herunterfahren. Aber wie kann ich ihn erneut starten?

Wie kann man es von Grund auf neu bereitstellen?

@alle
Wie installieren Sie Docker (mit funktionierendem Docker-Compose), über brew install oder über Toolbelt .pkg?
Wie kann ich sicher sein, dass die Zertifikate, die sich auf meinem Docker-Computer befinden, von Python gültig und nützlich sind? Wie kann ich Python und OpenSSL noch mehr aktualisieren als Brew kann usw.?

Danke fürs Helfen.

Grüße,

@PavelPolyakov - docker-machine hat keine Vorstellung von einer "Standard" -Maschine. Sie können docker-machine create --driver virtualbox my-docker-machine ausführen.

@PavelPolyakov Sobald Sie dies getan haben, müssen Sie eval "$(docker-machine env my-docker-machine)" oder was auch immer Sie gewählt haben, um Ihren lokalen Entwicklungscomputer aufzurufen.

@glyph
Richtig, das war der fehlende Teil, um alles von brew . Ich habe erfolgreich einen Computer mit dem Namen default bereitgestellt (der gleiche wie bei der Installation von * .pkg).

Wie immer beende ich jedoch mit:

:(

In Ihrem Reiseführer schlagen Sie mv ~ / .docker ~ / .docker-bak vor - aus welchem ​​Grund? Sobald wir dies tun, können wir den Computer nicht erneut starten, da die Dateien verschoben werden.

@ PavelPolyakov , ich bin nicht sicher. Ich benutze nicht docker-machine . Ich habe basierend auf anderen Umgebungen geraten. Bitte ignorieren Sie, wenn dies nicht funktioniert.

Ja, ich kann mich auf dem Computer anmelden und tls/* entfernen und dann herunterfahren. Aber wie kann ich ihn erneut starten?

Funktioniert docker-machine restart nicht?

Mein Kommentar basierte auf meiner eigenen Erfahrung mit dem Ausführen von boot2docker mit Vagrant. Es kann sein, dass es für docker-machine nicht sehr gut gilt. Es klingt so, als hätte @glyph mehr Erfahrung mit dieser Umgebung. Ich würde seine Vorschläge versuchen.

Wie installieren Sie Docker (mit funktionierendem Docker-Compose), über brew install oder über Toolbelt .pkg?

Dies liegt etwas außerhalb des Rahmens dieses Problems (das sich speziell mit einem Zertifikatsproblem mit boot2docker das sich in docker-compose manifestiert), aber unter OS X verwende ich die binären Builds .

@PavelPolyakov , was passiert, wenn Sie Folgendes tun?

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

Welche Version für boot2docker wird angezeigt, wenn Sie Folgendes tun?

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

Sie können shiny-new-machine-74d5a19e durch das ersetzen, was Sie möchten, solange es nicht auf eine vorhandene Instanz verweist (dh der Name sollte nicht bereits angezeigt werden, wenn Sie docker-machine ls ausführen, bevor Sie die obigen Befehle ausführen .).

@posita

Hmmm ....: verwirrt: @PavelPolyakov , was gibt dir das?

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
Vielen Dank, dass Sie weiterhin helfen.

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

Habe versucht, dasselbe auf den verschiedenen OSX-Rechnern zu tun.
Mit den neuesten Updates (Betriebssystemen und Brühpaketen) und dem gleichen Problem mit SSL.

@PavelPolyakov , ich betrachte dies von Ihrem openssl s_client ... Dump:

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

Dies sind nicht die boot2docker -Standards, die (jetzt) ​​lauten sollten:

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

Ohne mehr zu wissen, schätze ich, dass docker-machine die Standardeinstellungen (irgendwie) überschreibt, wenn es die virtuelle Maschine bereitstellt. Aber der Aufruf von openssl scheint funktioniert zu haben, daher bin ich mir nicht sicher, ob dies ein Problem ist, und ich verstehe nicht, warum docker-compose fehlschlagen würde. : verwirrt:

Was ist Ihre Ausgabe für das Folgende?

(
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

Dies sollte eine Datei wie ~/Desktop/docker-compose-890-outerr-2015-09-18T14:45:29Z.txt erstellen, die zum Einfügen / Hochladen geeignet ist.

@posita
Hier ist es:
http://pastebin.com/vWqZgVKi

Ich bin mir ziemlich sicher, dass dies nichts mit Ihrem Problem zu tun hat, aber Ihre Versionen docker-compose und docker-py sind im Rückstand. Dies sind die neuesten Versionen:

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

Außerdem (und ich könnte dies falsch verstehen) sieht es so aus, als ob Ihre ca.pem und cert.pem die gleichen Subject teilen (was die Ursache für die ursprünglichen boot2docker Problem, aber aus der anderen Richtung kommen). Da diese Zertifikate anscheinend von docker-machine erstellt / verwaltet werden, vermute ich, dass das Problem vorliegt? Ich fand Docker / Maschine # 1335 und Docker / Maschine # 1767, die verwandt sein können, aber keine scheinen direkt auf den Punkt zu sein.

FWIW, ich verwende docker-compose (installiert über pip in einem virtualenv ) mit OpenSSL und Python 2.7, die von MacPorts installiert wurden. Diese Version von OpenSSL unterliegt dem in dieser Ausgabe identifizierten Problem (und wurde durch das Update auf boot2docker ). Für mich funktioniert diese Kombination problemlos mit boot2docker 1.8.1+ und Vagrant (meine Vagrantfile übernimmt das Zurückkopieren der boot2docker -Zertifikate zurück auf den Host durch einige Bereitstellungsmagie):

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

Mir ist klar, dass Sie diese Option möglicherweise nicht haben. Ich poste es nur, um die Unterschiede zu beleuchten, die bei der Diagnose Ihres Problems hilfreich sein können. Vergleichen Sie das Obige mit Ihren von docker-machine erstellten Zertifikaten:

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

Beachten Sie, dass Subject von ca.pem dasselbe ist wie Subject von cert.pem .

Ich glaube nicht, dass Ihr Problem ein Problem mit docker-compose . ( @aanand , vielleicht können Sie einen Kommentar Tatsache , dass dieses Problem ziemlich unübersichtlich ist, sollten Sie ein neues Problem für Docker / Maschine einreichen. Ich würde auf diesen verweisen, beginnend mit Ihrem ersten Kommentar .

Wenn Sie ein neues Problem für Docker / Computer einreichen /var/log/docker.log oder /var/log/boot2docker.log interessant ist. Versuchen Sie zum Beispiel Folgendes:

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

Oder:

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

Dies auf OSX el capitain bekommen,

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

Hallo @ DaveBlooman ,

Nur neugierig, haben Sie auch Python und andere Dinge, die mit Brew installiert wurden? Oder andersherum.
Und haben Sie den genauen Fehler, wenn Sie docker-compose build ?

Über Homebrew Python 2.7.10

Es findet also definitiv etwas statt, weil brew :(

@ DaveBlooman , siehe auch Docker / Maschine # 1910. Wenn Sie das Problem von @PavelPolyakov reproduzieren

Ich hatte das gleiche Problem und es lag an der Tatsache, dass ich eine offene VPN-Verbindung hatte, die von einer anderen Anwendung (in meinem Fall Astrill) geöffnet wurde, was wahrscheinlich etwas mit der Netzwerkkonfiguration zu tun hatte. Hoffe, dies kann jemand anderem helfen, der das gleiche Problem bekommt.

Ich erhalte Fehler unter 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-Maschine Version 0.5.0
Docker-Compose-Version: 1.5.0

alles über Homebrew installiert

@anthonygreen , das sieht nach einem wesentlich anderen Problem aus. Ich sehe nicht die gleiche Fehlermeldung wie hier. Es scheint, dass Homebrew-Benutzer eine erhebliche Anzahl von Problemen haben, die nichts mit diesem zu tun haben. Bitte erwägen Sie, eine neue Ausgabe einzureichen.

Ich habe diesen gesamten Beitrag nicht gelesen, aber bei einem kürzlich unter OS X Yosemite verwendeten Setup mit Docker Toolbox 1.9.1a wurde derselbe Fehler festgestellt.

$ 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

Es stellte sich heraus, dass ich eine benutzerdefinierte CURL_CA_BUNDLE -Umgebungsvariable festgelegt hatte (mit einigen benutzerdefinierten internen Zertifikaten), und das Deaktivieren dieser env-Variable vor dem Ausführen von docker-compose ermöglichte es, den Fehler [SSL: CERTIFICATE_VERIFY_FAILED] überwinden.

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

edit: oops, soll hier kommentieren https://github.com/docker/machine/issues/1880

@pmahoney , danke, dass du den Rest von uns informiert

$ CURL_CA_BUNDLE= docker-compose up

@posita Das Setzen der env var auf die leere Zeichenfolge führt zu Warnungen:

$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

Obwohl ich den SSL-Fehler nicht bekomme.

@pmahoney , interessant. Es sieht also so aus, als hätte ein Set-but-Empty CURL_CA_BUNDLE eine andere Semantik (dh eine Null-Überschreibung) als das Nicht-Setzen überhaupt (was wahrscheinlich auf einen Standardspeicherort zurückzuführen ist). Ich habe versucht, dies im Verhalten in den Dokumenten zu finden, war aber nicht erfolgreich. Das nächste, was ich fand, war das hier .

@neilsarkar mein Problem war auch Charles Proxy läuft! Vielen Dank!

Oh Gott, ich habe auch benutzerdefinierte CURL_CA_BUNDLE auf beiden Maschinen, auf denen ich getestet habe.

Vielen Dank

erf nichts für mich, keine CURL_CA_BUNDLE Variable :(
Also habe ich versucht, einen Wert ohne Erfolg auf einen Wert zu setzen, aber wenn ich CURL_CA_BUNDLE auf nichts setze (CURL_CA_BUNDLE =), habe ich eine Warnung, wie @pmahoney sagte, und es funktioniert, aber mein Terminal ist völlig durch Warnmeldungen überflutet.
Ich hoffe es gibt eine bessere Lösung für mich :)

Wenn Sie wissen, was der gute Wert für die Variable CURL_CA_BUNDLE ist, nehme ich es :)

Danke

Ich hatte das gleiche Problem mit dem Webkit-Patch. Anhand der Python-Dokumente im SSL / TLS-Modul zeigt uns ssl.get_default_verify_paths() , wo Python / OpenSSL eine CA-Zertifikatdatei erwartet. Wenn Sie dies in Ihrem Terminal ausführen:

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

Wir sollten sehen, dass das SSL-Modul von Python ohne SSL_CERT_FILE eine CA-Zertifikatdatei mit /usr/local/ssl/cert.pem erwartet (für diejenigen, die OpenSSL auf /usr/local/ssl installiert haben). Entweder setzen Sie SSL_CERT_FILE auf eine Zertifikatdatei mit Stammzertifizierungsstellenzertifikaten, oder Sie platzieren eine Datei mit Stammzertifizierungsstellenzertifikaten bei /usr/local/ssl/cert.pem . Wenn Sie die Stammzertifizierungsstellenzertifikate benötigen, laden Sie curl herunter und führen Sie im Quellbaum lib/mk-ca-bundle.pl Eine Datei ca-bundle.crt wird generiert. Ich kann bestätigen, dass die Einstellung SSL_CERT_FILE mit OpenSSL 1.0.2d mit Python 2.7.11 und Python 3.5.0 funktioniert.

@grahamc Hast du das Problem zufällig gelöst? Ich habe eine ähnliche Einrichtung wie Ihre, die mit dem Remote-Docker-Daemon hervorragend funktioniert, aber mit docker-compose fehlschlägt

Der Fehler, den ich bekomme, ist ERROR: SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

Nein, ich musste leider nur Remote-Docker-Hosts aufgeben :(

Ich hatte gerade dieses Problem, bei dem CURL_CA_BUNDLE dass docker-compose fehlschlug mit:

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

während docker funktionierte. Es wäre gut, wenn docker-compose die Umgebungsvariable ignorieren oder zumindest eine Warnung protokollieren würde, dass die erwarteten Zertifikate nicht verwendet werden.

@buckett , erwägen Sie, ein neues Problem docker-py und lassen Sie sie sich gegenseitig referenzieren. Ich bin mir nicht sicher, welche Schicht am besten geeignet wäre.

Bearbeiten: Neue Ausgabe Nr. 3114 erstellt

Hat das schon jeder behoben? Ich bekomme immer noch den gleichen Fehler. Mein docker-compose version ist:

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

Das habe ich von 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)

Ich habe Docker, Docker-Mahine und Docker-Compose über Dockers Toolbox installiert.

Ich habe alle oben genannten Vorschläge ausprobiert, aber kein Glück. Ich habe keine Erfahrung mit docker daher konnte ich es selbst nicht herausfinden.

Hat jemand eine Grundursache oder eine Problemumgehung? Ich sehe es in Compose 1.7.0 mit einer neueren OpenSL-Version.
Dies alles wird von alpinen gebaut und betrieben, daher sollte die Umwelt rein sein:

/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
In meinem Fall wurde dies durch die neu definierte Variable CURL_CA_BUNDLE env verursacht. Sie sollten prüfen, ob Sie auch einen solchen Fall haben.

@PavelPolyakov überprüfe meinen

@PavelPolyakov Okay, das ist seltsam. Ich habe diese env-Variable explizit

@jmmills huh ... das gleiche hier. Vielleicht behandelt Python als leer gesetzt anders als nicht gesetzt?

Mac OS, Homebrew Docker-Compose und Docker-Maschine mit System Python. Neu erstellte Maschine mit: docker-machine create --driver=vmwarefusion --vmwarefusion-memory-size 1536 dev

env | grep CURL gibt nichts zurück
docker-compose ps kehrt zurück

FEHLER: SSL-Fehler: Hostname '172.16.129.133' stimmt nicht mit 'localhost' überein.

CURL_CA_BUNDLE='' docker-compose ps zurück:

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

Ich hatte genau das gleiche - CURL_CA_BUNDLE wurde in meiner Umgebung nicht festgelegt, und das Setzen auf eine leere Zeichenfolge gab mir die gleiche Ausgabe wie @inanimatt.

Es riecht definitiv nach einem Upstream-Fehler. Ich vermute, es handelt sich um einen Umgebungskompatibilitätscode für Curl, in dem "definiert" und "leer" unterschiedlich behandelt werden.

Vielen Dank,
Jason Mills

• vom Handy geschickt.

Am 24. April 2016, um 6:14 Uhr, schrieb Alex Wilson [email protected] :

Ich hatte genau das gleiche - CURL_CA_BUNDLE wurde in meiner Umgebung nicht festgelegt, und das Setzen auf eine leere Zeichenfolge gab mir die gleiche Ausgabe wie @inanimatt.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an

Scheint nur die Homebrew-Version zu beeinflussen - die Installation von Homebrew Python und die Installation von Docker-Compose über Pip behebt alle Fehler.

Am 24. April 2016, um 14:14 Uhr, schrieb Alex Wilson [email protected] :

Ich hatte genau das gleiche - CURL_CA_BUNDLE wurde in meiner Umgebung nicht festgelegt, und das Setzen auf eine leere Zeichenfolge gab mir die gleiche Ausgabe wie @inanimatt.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an

Ich glaube, ich habe die Replikation des Problems unter Linux früher eingefügt. Ich kann morgen an einem Arbeitsplatz noch einmal nachsehen

Vielen Dank,
Jason Mills

• vom Handy geschickt.

Am 24. April 2016, um 12:22 Uhr, schrieb Matt Robinson [email protected] :

Scheint nur die Homebrew-Version zu beeinflussen - die Installation von Homebrew Python und die Installation von Docker-Compose über Pip behebt alle Fehler.

Am 24. April 2016, um 14:14 Uhr, schrieb Alex Wilson [email protected] :

Ich hatte genau das gleiche - CURL_CA_BUNDLE wurde in meiner Umgebung nicht festgelegt, und das Setzen auf eine leere Zeichenfolge gab mir die gleiche Ausgabe wie @inanimatt.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an

Das gleiche Problem hier, da ich Docker-Compose mit Brew auf Version 1.7 aktualisiert habe.

$ 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

Das Leeren der Umgebung CURL_CA_BUNDLE env var löst das Problem:

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

Ein Downgrade auf 1.6.2 löst ebenfalls das Problem.

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

Anstatt CURL_CA_BUNDLE zu deaktivieren, können Sie Folgendes ausführen:
CURL_CA_BUNDLE = ~ / .docker / machine / machine / default / ca.pem Docker-Compose ps

Ich bin wahrscheinlich nicht der erste, der dies angesprochen hat, aber ist es nicht kontraintuitiv, dass eine Curl-Umgebungsvariable irgendeine Auswirkung auf eine nicht verwandte Python-Anwendung hat?

Vielen Dank,
Jason Mills

• vom Handy geschickt.

Am 7. Mai 2016, um 15:22 Uhr, schrieb Lorenzo Sicilia [email protected] :

Anstatt CURL_CA_BUNDLE zu deaktivieren, können Sie Folgendes ausführen:
CURL_CA_BUNDLE = ~ / .docker / machine / machine / default / ca.pem Docker-Compose ps

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an

Ich bin auf dieses Problem gestoßen, und das Problem bestand darin, dass die Umgebungsvariable REQUESTS_CA_BUNDLE auf einen benutzerdefinierten Speicherort für selbstsignierte Zertifikate zeigte. Encase dies hilft jedem.

• Michael Housh

@aboutlo Das funktioniert - es hat nicht mit anderen ca.pem -Dateien funktioniert, nur mit dieser. Ich bin auch unter Windows, also habe ich eine Voodoo-Konfiguration, danke!

Die Deinstallation von ndg-httpsclient (mit pip - war Version 0.4.0) löste das Problem für mich. Siehe meinen Beitrag hier: https://github.com/docker/compose/issues/3365

Ich habe Docker-Compose und Docker-Py getestet und herausgefunden, dass Sie entweder Umgebungsvariablen oder Optionen im Befehl verwenden sollten. Sie sollten diese nicht mischen. Wenn Sie im Befehl sogar --tls angeben, müssen Sie alle Optionen als TLSConfig-Objekt angeben, da das TLSConfig-Objekt jetzt vollständig aus den Befehlsoptionen erstellt wird und das aus der Umgebungsvariablen erstellte TFSConfig-Objekt ausgeführt wird.

@ m-Housh OMG danke für diesen Tipp! Genau das gleiche ist mir passiert! REQUESTS_CA_BUNDLE aus meiner Umgebung entfernt und dieses Problem wurde für mich behoben.

Ich bin auf das gleiche Problem gestoßen. Zuerst dachte ich, es liegt daran, dass die OpenSSL-Versionsunterschiede (Pyhton hatte 1.0.2, aber das Betriebssystem hatte 0.9.8) beide 1.0.2 gemacht haben, aber es hat immer noch nicht funktioniert.
Ich habe mein Problem gelöst, indem ich einfach ssh an docker gesendet und dann mein Zertifikat in autorisierten Schlüsseln überprüft und aktualisiert habe. Interessanterweise war es dort irgendwie ein falsches Zertifikat.

Befolgen Sie bitte diese Schritte:

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

Überprüfen Sie, ob dieses Zertifikat wirklich das Zertifikat Ihres Computers ist. Wenn nicht, kopieren Sie einfach Ihre in diese Datei und speichern Sie sie. Dann laufen Sie einfach:

docker-compose up

Das hat bei mir funktioniert und ich hoffe, dass es hilft.

Problembehandlung: Es scheint eine Vielzahl verschiedener Fehlermodi und Benutzerfehler- / Fehlkonfigurationsszenarien (alle weitgehend historisch) zu geben, die hier beschrieben werden.

Ich sehe nichts, was auf ein aktives aktuelles Problem beim Verfassen hindeutet, also schließe ich das Problem. Wenn bei modernen Versionen immer noch ein Fehler auftritt, öffnen Sie bitte ein neues Problem mit allen Details Ihres Szenarios usw.